Each of the platforms will have its own architecture and Adobe AEM is not built on portlets model as primary like Liferay or WebSphere portals.
All these portals come with the capabilities of portlets as primary and have the CMS capabilities to it while AEM has CMS as the primary capabilities but can support the architecture of portlets. The link provided by @Scott talks about the same. Not sure if there are many implementations of that as a case study. https://helpx.adobe.com/experience-manager/6-3/sites/administering/using/aem-as-portal.htm l
Thank you for the link. I see that AEM *can* run portlets but that is not a primary function of the overall ecosystem.
It seems like AEM has a rich and graphical web environment which will allow my team to deliver CMS-related web sites very quickly. The team is developing a horizontal portal for franchises, and it will be used by back-office staff. One of the key requirements is that the users be able to customize their landing pages. With something like Liferay, we can have a region of the screen where users can specify "portlets" to run there from a portlet pallet. But Adobe does other things we would like to do like PDFs, digital signatures, and so on.
So I'm curious about the amount of custom coding would be required to implement this concept and/or live tiles. None of these portlets have actually been written yet, so the approach is flexible. FWIW we have a lot of .NET code around here and hopefully the resulting solution would allow us to harvest that code somehow rather than ground-up rewrites.
1 person found this helpful
If your code is .NET and you want to get that logic into AEM, this will require a re-write to get that logic into the AEM OSGi service container. AEM cannot run .NET libs as its a Java platform.
Also - its true that Adobe stack can do tasks like PDF generation, etc. This is a module that works with AEM named Document Services - here is a webinar about Document Services so you better understand them --
Please allow me to clarify the question; the responses so far have been valuable and I appreciate the collaboration.
I have a requirement for end-user customization -- the end user must be able to select content feeds from a content store and determine where they will display on the screen. With something like Liferay, I can put together each content item as a portlet and then users would be able to drag the portlets from a pallet into pre-defined locations on the screen and re-arrange them at will.
How would you approach something like this with AEM/CQ? Standard Java portlets aren't an absolute requirement, but the concept of user-selected content from a widget store is a requirement. Some of the widgets are little inquiry applications, it's not all about static content.
I guess one way to do this would be to develop my own display layer, and then it would read through a list of user selections and format the content accordingly; I think implementing drag and drop would need tricky custom code. However, it seems to me that this is foundational code that should be built into the platform. If AEM can implement this cleanly then it has a decent chance of being used for this project. It's not a small project -- maybe 100,000 users.
Please share your ideas.
You are building a portal with a strong focus on personalization of the login page. I think you can do that. But in my opinion that is not a usecase where AEM is especially strong at. Your usecase rather looks like a standard case for a (traditional) portal software.
I would hesitate to implement this in AEM only.
Thank you, Jörg. I agree that personalization can be achieved with AEM using rules and code. I am wondering about something slightly different, the idea of an internal portlet pallet or "widget store" that the users can access to customize their own experience. This is exactly what Liferay does, but Adobe has lots of other interesting features so I was wondering what an expert in AEM would think about the complexities of implementing that type of drag and drop portlet approach. Even if they are not actual portlets, but the UX makes it seem to the user like an app store. There would a max of 40 widgets, and we would start with just 10.
Though it's not AEM's strength, I think we can use some of the UI frameworks which enables the drag and drop features to create a template in AEM. Now list all the widgets(AEM Components) which users can organize within the layout.
Oh, that is getting close to what we are after - with the end user doing customization, the drag and drop all by themselves, and each user may do it differently, up to a few hundred thousand users. Most users, won't change a thing.
So do these components have that level of dynamic placement? This is very interesting and I hope someone can point me to an example or some documentation showing where this was actually done. I wan't to stay solidly in supported, mainstream, capabilities of AEM/CQ.