Why we extends WCMUsepojo abstract class in our program while working with AEM?
What is the advantage of using this class?
Because in AEM’s component development mechanism, you likely need a way to provide back-end logic to components.
That's because Sightly (when used as a rendering script language instead of the JSP pages) is on purpose a limited template language that allows to do only small basic operations, and the heavy lifting logic should be done inside a Java class or a server-side JS (that you refer using the data-sly-use element inside the Sightly script).
This provide better decoupling of the business logic and so your code will be more easily maintainable and also easier to debug.
In order to abstract component Java class with page context or binding objects, previously Adobe’s WCMUse was used, or a custom implementation of Use class. If your working with AEM 6.1 or 6.2 WCMUsePojo class is used (or even Sling Models). With the release of AEM 6.3 and AEM Core WCM Components, we see that using Sling Models have been advocated by Adobe as the best practice.
While the previous answer gives a pretty good explanation, I will write my own - brief one:
You can use simple Pojo (do not extend any Adobe's class) with java-use-api. But in this case, you will not be able to easily access resources/services.
You can extend WCMUsePojo to get the ability to use resources/services.
Also, you can go with Sling Models way which will give you more flexibility.
Related
To call JSP's in AEM 6.2 I've been creating site pages then changing the resourceType to a JSP component. Without creating OSGi bundles, is it possible to call a JSP directly without having to go through the Page / Component reference method?
In short No. That is against Sling principles. Quoting the documentation
Sling Scripts cannot be called directly
Within Sling, scripts cannot be called directly as this would break
the strict concept of a REST server; you would mix resources and
representations.
If you call the representation (the script) directly you hide the
resource inside your script, so the framework (Sling) no longer knows
about it. Thus you lose certain features.
For more information, please refer The Basics
If given an option to use Sling Models or WCM use class which one should be preferred when and why?
Is either of them better performance wise?
Thanks in Advance
Sling models are saving you a lot of time for accessing simple objects as the current page/resource, injecting some properties or services, adapting from resource or sling http request to your model. Sure with the use the plain API your code will execute a little bit faster, because you initialize only the objects you really need, but you have to do all that things "manually". I think that this sightly introduction is giving a good overview of all possible implementation you can go with. You can also have a look at the sightly official documentation. Below you can find a quick overview of the what you can expect and hopefully make your decision easier (quoted from the offical sightly documentation).
Java Use Provider
Advantages
Use-objects provided through bundles:
faster to initialise and execute than Sling Models for similar code
easy to extend from other similar Use-objects
simple setup for unit testing
Use-objects backed by Resources:
faster to initialise and execute than Sling Models for similar code
easy to override from inheriting components through search path
overlay or by using the sling:resourceSuperType property, allowing
for greater flexibility
business logic for components sits next to the Sightly scripts where
the objects are used
Disadvantages
Use-objects provided through bundles:
lacks flexibility in terms of component overlaying
Use-objects backed by Resources:
cannot extend other Java objects
the Java project might need a different setup to allow running unit
tests, since the objects will be deployed like content
Sling Models Use Provider
Advantages
convenient injection annotations for data retrieval
easy to extend from other Sling Models
simple setup for unit testing
Disadvantages
lacks flexibility in terms of component overlaying, relying on
service.ranking configurations
If you ask me I would always take a framework as sling models or slice which makes the development easier and faster. At the end the performance impact by using a framework is not really a problem, would be not the only one third party framework in the project. But if your project is performance oriented probably you could make some tests with all possibilities you have and decide if such a framework suits your needs (or just mix both).
I am working on an E4 RCP application and, while our basic DI configuration is working, I have some reservations about our current implementation.
The IInjector interface and #ProcessAdditions annotation are tagged as being discouraged for external access. Currently, we are using a series of statements similar to
injector.addBinding(IInterface.class).implementedBy(Concrete.class);
from within a method marked as #ProcessAdditions. What method(s) can be used that don't violate access rules? I know I can bind classes/strings to instances via IEclipseContext, but using ContextInjectionFactory by hand seems to force order of construction to be known by configurer (as opposed to other DI frameworks).
I know Guice has the concept of child injectors, but in E4, ContextInjectionFactory is internally set to use only the default injector for manufacturing. What is the best method to manufacture a group of objects, using DI, and subsequently disposing of this group? I would like to create a fresh batch of processing objects for each processing operation.
ContextInjectionFactory is the only thing I have seen described for doing injection in e4 (in Lars Vogel's 'Eclipse 4 RCP' book for example). This is what I use in my e4 applications.
Some things, such as #ProcessAdditions are marked as discouraged because that part of the e4 API has not been finalized yet and might change, they can still be used. #ProcessAdditions is only used for the application Life Cycle class.
I am trying to write a Javascript client for a web application which provides a REST API to interact with the application. I want to do this in a very advanced way like with a proven stack of tools and methodologies available in Javascript.
Most of the guides about javascript client library development I found in the web are application oriented which have a view part( I mean HTML part ). What I needed is like a client library with some methods which can be used to develop web applications. So I don't want to depend this library with any other javascript library like JQuery, Backbone etc.
I have gone through lot of design patterns available in javascript, especially patterns mentioned in Learning JavaScript Design Patterns a book by Addy Osmani. And after all I got confused, I couldn't decide which one to follow.
What I have in mind is like following:
Initialize the library with some key and secret (This can be compared to declaring object for a class in php).
There will be a data persistence unit which will keep the authenticated user's identity over a predefined amount of time like sessions in php. User data will be stored in cookies or local-storage. Also there will be provisions to override the methods of this unit so that user can implement their own storage mechanism. A reference to this unit will also be passed during library initialization.
Keep a global request method which handles all the API requests associated with the library(This can be compared to a method of the main class in php)
Define all the API methods encapsulated into different units according to the area of application it dealing with. This each unit will have a constructor method which defines some default properties to the unit( This can be compared to defining models in php which will fetch or save data from the application with API ). Each of this unit can be inherited from a super unit which provides some default properties and methods.
After reading some blogs and articles I have decided to use yeoman for library development. May be I can use some yeoman community javascript library generators to start the development.
As I described above I think what I needed is like: a class which keeps a single instance throughout the application which can be used to refer all the models and functions in the models. For this may be I can go with the singleton module pattern, but I am not fully sure about how to make use of it to my requirement.
Any advice is greatly appreciated!
In some implementations, I've seen jsp's using java bean classes acting as an intermediate store/data access layer to get data from a jcr.
Why is this, since the jsp can access the jcr directly via the jcr api.
Separation of concerns? Memory cache for the data?
Just wondering why such a pattern exists when the jcr api was written in the first place.
Using scriptlet's might not be so problematic in smaller installations but is in large multi site projects.
Separating UI code and model/business logic eases maintainability and allows reusability of code upon projects. Also changing layout's gets much easier. Usually this seperation is done by using a component bean to access the JCR repo and to provide the data and by using the JSP just for the view.
Just imagine that your customer requires a large UI change propably in multiple sites. It's harder to change JSPs mixed up with scriptlets and UI code, especially if you have a lot of them.
From an OO perspective using JSPs and scriptlets prevents you from using inheritance and composition. Scriptlet's can not be made abstract.
I experienced that java beans are easier to debug then scriptlets, especially in case of an exception and java beans can be easier unit tested.