Liferay - Train of thoughts

It is ca 2 years ago when I was playing with sample portlets wondering what is the difference between Ext and Hook. I wanted to make a summary of the most important facts that it is good to be aware of.

Newcomers usually expect that they will be able to deliver an Intranet solution or at least a nice website with a few handy plugins very shortly. But suddenly they realize that even though Liferay has so much to offer, they really need at least a few weeks of LR experience to be able to customize or even use them. Just setting everything up and configure plugins and portal requires decent knowledge of Liferay.

You can easily add Wiki, Message Board or Blog into your site and set up roles and permissions for its users. Add some web content, social portlet, calendar or even Document Library (there are more of them). What I just named is great, I appreciate it a lot, but the problem is, that these portlets itself don't constitute a production ready solution most of the time. Make a list of those plugins and imagine what market product you would be able to put together using them.

• Full-fledged website for 
•  a common interest that connects some social group together
•  a product that needs a proper representation and that has its user / social group  
•  a corporate extranet and basic intranet with Document Library that is capable of document workflow and connection to other repositories or accessible from your desktop
•  etc.

Beware, that there is not much you can do if you just going to create some web content and install Liferay's plugins. And even if you become a good administrator and you make a good looking social website via Control Panel and other configurations, you will most probably see many requirements that need to be done and many unused plugins, because there wasn't reasonable usage for them or it would be redundant. At that time you need a Liferay developer and UI designer.

As Liferay has many features and plugins, rather than framework it is a collection of applications, running on a robust software infrastructure (permissioning, roles, grouping, portlets lifecycle management, unified UI framework, event system, scheduling, very solid abstraction over data persistence, etc.). The features are there, they work, but they are made for universal use and as a developer you can either use them, improve them or use them as a model to create your own, which is mostly not an option. The architecture is very maintainable and you are mostly able to use services that the plugins are built on, to do what you need. There is a difference between portlets, for instance Message Board is most probably not going to be modified whereas Document Library is something that might be accessed more programmatically than via GUI, because if you are building an intranet for instance, custom document workflow and processing could be necessary and you're gonna have to make a good plan how to integrate with Document Library and benefit from the advantages that results from using. And this is something why you need to know Liferay a little longer. An important skill of a developer is the ability to learn from past mistakes and the ability to perceive what makes sense or not.

In Liferay you just has to accept the fact, that they try to satisfy existing customers, have as many features, that they can present to business world, as possible and that Liferay supports wide technology stack and vendors. This is kinda good for business and community growth, but it is not so beneficial for the software itself. It leads to defensive programming and not so much of refactoring or radical changes. There are quite a lot of programmers working on new features, producing bugs and skilled developers that are able to do radical infrastructure changes often end up fixing them and wasting a lot of precious time.
      Document library is a good example of this (notice that I don't criticize that, I mentioned before that it has valid reasons). DL came through a lot of changes recently, a lot of new features actually (CMIS, Document types and their processing, metadata, workflows, etc.). It's design is quite alright, but it doesn't adhere to any specification because LR needs it to be scalable (filesystem sore, JCR store, Amazon S3) and it utilizes the same permissioning system for it that is used for every other resource in the portal. Documents are also part of Asset management and it has it's own way of indexing and versioning. That's why it is built on repository data model (repository, file, folder, metadata, type, version, etc.). All this is quite complex and it is very hard to use a variety of interfaces where you all the time have to think of "and what if this..., wtf if that..." and you have to dive down into the implementation to answer many questions and you are infinitely not sure of consequences of what you're doing, then you finally become Document Library proficient to be able to work with it. This doesn't happen so much with software based on specification, like JCR spec. Wouldn't it be better if instead of all those new features a major refactoring was performed and all those necessary attributes of common document store were handled by JCR repository like Modeshape ? (ACLs - authentication/authorization, scalability (Modeshape datasources/connectors), versioning, indexing, CMIS ... I know that it is almost impossible at this stage, because files in Document Library are common resources and assets as well as blog post, wiki entry etc. It's part of the asset management that other portlets work with. Similarly the indexing and searching through the entire portal. On the other hand, standardization and specification is here because it doesn't change and once a developer learns it, nobody can take it from him and when a newcomer comes to a software based on specification, he knows how it works instantly.

Developing Liferay portlets is very straightforward, but only after you learn from all what you have done wrong in past. Quick example : I was so out of luck that I built one of my most important portlets on Liferay Service Builder (code and spring infrastructure generator - service/dao/domain layer). Everything looks fantastic except for one thing. Unit testing. You can easily load up portal spring context to use its services when testing, but you cannot load up your portlet Service Builder context (which depends on the portal one), because the bean IDs are the same in portlet context as of those in portal context. You just have to do heavy infrastructure coding to put such a basic thing like unit testing of a portlet together ... Actually I had 3 different variations of loading up SB portlet context together with Portal context ...

Anyway, I got really tired, gotta pack for a Nederland boat trip :-) I don't have enough energy to read it after myself so please excuse mistakes, my English or the exaggerated idea about Document Library refactoring :-)