Expand my Community achievements bar.

SOLVED

Development on new 6.0 projects whats now best practice in 6.0?

Avatar

Level 1

Apologies for the long post, having worked on a few 6.0 projects, I had some general questions about the best practice way to work with AEM 6.0. It seems now we have many different ways to create templates and components, but what is the right way?

Basic 5.x Development model:

Create JSP’s that use JSLT or custom taglibs to interact with OSGi code, and then ExJs framework to create UI’s for the components.

Now with the introduction of AEM 6.0 I am not sure any more. It seems the approach above will work ok, but here is my thought, is this future proof? Should we as AEM implementers be still doing this now in 6.0?

I am about to start our 3rd AEM 6.0 project, and I want to be sure that we are doing it right.  Here are some of my unanswered questions:

Should we be creating components using the new Granite UI interface? On the face of it I though that we would only need to worry about doing this to extend the new touch UI, but yet we have things like: Text and Breadcrumb and Heading in the documentation for granite? These are clearly authoring components, so what’s the story?  Here is the list FYI:

http://docs.adobe.com/docs/en/cq/current/touch-ui/granite-reference.html 

Should we be trying to create all components like this now?

If I spend the next 4 months creating ExJs components that work in the new UI, do I in the future have to turn around to our customers and say, 'oh by the way if you are moving to 6.2 or 6.3 or 6.x…. the ExJs framework has been retired and all those cool components we made for you have to be re-implemented in granite or your upgrade wont work' ? There is a reason why they are calling the old ExJs dialogs "classic" as mentioned here:

http://docs.adobe.com/docs/en/aem/6-0/develop/ref.html - "Widgets API (Classic UI) Documentation"

So lets say that we should be trying to adopt granite as our default development approach for new 6.0 projects, how do these dialogs work with the old interface?

According to this:

http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage...

I have no access to the design mode from the new UI? How can I create an entire AEM project using Granite UI with out using one of the best features of AEM? Those global design dialogs are very much needed, so I am a little confused about that, and how the JSP inheritance works with the new granite stuff, I am still ramping up on it. 

When I go to look at some of these sample granite UI components, I was really sad to see scriptlets? I though that’s why Slightly was introduced?

Why would this version of AEM be released at this stage with view and logic mixed? This seems a little crazy to me, I know AEM supports it but a lot of customers rightly don't want this kind thing in their code bases. 

Right now, it seems that no matter what approach you take for a new AEM 6.0 project you are going to have potential issues:

JSP / JSTL / ExJs / OSGi – not using the new layers of technology in 6.0 and creating a situation down the road that could be a major upgrade issue if ExJs is completely removed from AEM, as well as delaying the inevitable ramping up on granite for developers.

JSP / Granite / OSGi - Very few examples, use of scriptles which we cannot put in customer code. We also lose access to design dialogs here maybe? Not clear on that so far. Why is there not better JSP support for granite in the sample JSP’s ? How do I find more examples of how this new mechanism works? An entire new UI platform is being introduced in AEM, are we expected to have to create our own custom taglibs to support it so that we can exclude scriptles from our JSP's?

JSP / Slightly / Granite / OSGi – From what I have been told so far, I though this was the way we were suppose to move, at least for new 6.0 projects yet there does not seem to be a whole lot of examples of this in the product, and again all the examples I have looked at below:

/libs/granite/ui/components/foundation/*

Are packed with a Java code? Surely the engineering teams at Adobe must realize we cant implement JSP’s like this?? This was the reason there was an attempt to bring in a new templating language ("slightly") in the first place right?

Can anyone post their feed back on 6.0 projects so far? The new features in 6.0 are fantastic, and some of the new technologies are great in there, but from a development perspective I am really frustrated with the mix of everything going on in AEM 6.0 and really don’t know what we are suppose to be doing to deliver the best projects to our new AEM 6.0 customers, as well as communicating this to all of our project teams. 

I would like to get a conversation going about how Adobe would like us to implement our 6.0 projects.  

Thanks! 

1 Accepted Solution

Avatar

Correct answer by
Employee

Hi,

I think there's some confusion here about Granite UI. Granite UI is purely for authoring in the Touch UI. You should not be using Granite UI to build your components other than to build their dialogs. And even in that case, it would only be if you wanted/needed to create a separate Touch UI dialog from the Classic UI dialog. You would also use Granite UI if you were building custom consoles.

The Granite UI components are not sample components and shouldn't be used as such. While I agree that it would be nice if Granite UI was built on Sightly, this just didn't come together in time for the AEM 6 release.

Regards,

Justin

View solution in original post

2 Replies

Avatar

Correct answer by
Employee

Hi,

I think there's some confusion here about Granite UI. Granite UI is purely for authoring in the Touch UI. You should not be using Granite UI to build your components other than to build their dialogs. And even in that case, it would only be if you wanted/needed to create a separate Touch UI dialog from the Classic UI dialog. You would also use Granite UI if you were building custom consoles.

The Granite UI components are not sample components and shouldn't be used as such. While I agree that it would be nice if Granite UI was built on Sightly, this just didn't come together in time for the AEM 6 release.

Regards,

Justin

Avatar

Level 1

Thanks Justin, This makes some sense, I am still a little worried by the use of the work "classic" in the ExJs based framework so I guess we probably need to reach out though our partner program to get more of an idea about the AEM product road map, I would not want to keep developing on a UI framework that eventually gets pulled from AEM, thats my biggest concern. I think we will just have to keep creating our authoring components as we have been up till now in 5.x.