Extend local use-class in Sightly

Hi Peter,

does AbstractComponent extend WCMUse? Have you tried to deploy AbstractComponent in a bundle? A bundle seems the way to go given it will be a base class for multiple components.

I'm not sure it's even possible to call another class this way, but given your class name, shouldn't AbstractComopnent be in a folder called "/apps/myproject/components/abstractcomponent" ? 

Regards

I have a question on the same topic. Was thinking of logging a new question but since this is an active thread i am hoping the watchers can help me. I am starting a new project on AEM6.1 and we are using sightly for rendering scripts.

As per the adobe documentation (http://docs.adobe.com/docs/en/aem/6-1/develop/sightly/use-api-in-java.html#Alternatives%20to%20WCMUse), the most common way of java use api is extending the com.adobe.cq.sightly.WCMUse class. However when i extend it my eclipse cant find this in the classpath.The OSGI depfinder shows the below for the maven dependency.

<dependency> <groupId>com.adobe.cq.sightly</groupId> <artifactId>cq-wcm-sightly-extension</artifactId> <version>1.2.30</version> <scope>provided</scope> </dependency>

But i can't find this dependency in the adobe public repository.

Another adobe documentation (https://helpx.adobe.com/experience-manager/using/creating-sightly-component.html) says that the below dependency should be added.

<dependency> <groupId>com.adobe.aem</groupId> <artifactId>aem-api</artifactId> <version>6.0.0.1</version> <scope>provided</scope> </dependency>

However there is no 6.1 api available for aem in the repository.

Based on the above i am seeking answers to :

1. Does anyone have a pom for aem6.1 project for sightly i can use for reference?

2. Is using aem-api recommended for development?

thanks,

Himanshu

Hi Opkar,

thank you for your reply.

AbstractComponent extends WCMUse. For it is just an java class and no complete component with a html file, there should be no reason to place it at "/apps/myproject/components/abstractcomponent".

I think the problem is that the compiler mechanism does not compile all java classes placed under /apps/, but only the ones that are referenced as Sightly use-class. I've mentioned that even other helper classes used by a use-class are not compiled when they are in the same folder (and java package) as the class called by Sightly.

Does anybody know if there is a way to tell the compiler that it has to compile all java classes within a given path in CRX?

Hi Peter,

your use case seems more inline with the bundle option. The sightly documentation does say that class is compiled on demand when placed in the same folder as the sightly file. I can't find any reference to having multiple classes in the same folder.

Regards,

Opkar

Hi Opkar,

may be this is not directly a Sighly problem.

There are several other java source files in the /libs/ path, /libs/foundation/components/form/captcha/captcha.png.java for instance.
This files can be overwriten in the /apps/ path. I don't know the exact machanism, but under some special circumstances java classes where compiled and used.

Hi Peter,

the png.java file is a servlet [0]

Is there a reason you want to do your development with local classes rather than a bundle? 

Regards,

Opkar

[0]https://docs.adobe.com/docs/en/cq/5-6-1/howto/website.html "search for png.java"

Hi Opkar,

you're right. Most of the java files in CRX are servlets. Others are part of a .../src/ folder and seems to be there just for illustration.

Sling accepts java servlets as script to implement a component, just like a JSP and it compiles this classes just when this resource is requested.

To use local classes to implement components has the advantage that hotfixes can be installed easier and more securely, for it's sure that no other files are affected. If java class files are in a bundle the whole bundle has to be replaced.

Sadly this does not work as expected.

Hi Peter,

that's an interesting view on hotfixes. The bundle approach is the best way to manage, test and maintain your code, especially for teams. I think local classes are a very simple and limited use case and not intended to be used in the way you describe. Also, I have not seen anyone trying the approach you describe.

Regards,

Opkar

Hi Florian,

Sightly compiles POJO classes from the repo on demand if the requested Use-API object cannot be instantiated from a bundle. Since Sightly only checks the file is in the repo and sends it to the compiler, extending abstract classes located in the repo will not work (as they were not compiled and are not available in the class loader).

The repo-based Use-API POJOs are only meant for very simple processing, the recommendation is to use bundles for increased complexity/inheritance.

Hi Bailescu,

thank you for clarify this. We've used OSGi bundles before, but wanted to test this new approach by introducing Sightly.

Our experiment seems to be failed. We will fall back to OSGi bundles.

If anybody has a way to compile java files on time the are accessed, he's welcome.

One approach to achieve this is to extend the class loader mechanism. But for AEM does not provide this feature out of the box we'll leave our fingues from

For AEM does not provide this feature out of the box

Thank all of you.