Thanks,
Anil

I’m not sure how much PHP is exposed in Liferay but it’s based on Quercus PHP which is a full PHP 5 implementation written in Java. Quercus PHP is awesome if you ask me. It doesn’t support every last feature — but most are supported.

Not sure about any other languages, but with support of PHP? it really SUCKS!.

All thru out the day I was in
the community forum, and trying to figure out, what? how? and why?

Many PHP questions were given answers that of which can’t be exactly called an “answer”, others were never answered at all.

Saying that it supports was just for marketing, I guess… other non-java web developers won’t appreciate something like this from an open-source view.

I spend around 2 days figuring out how theming works and layout templating and seriously, creating two war files to make theme is just way off. ANY non technical person should beable to create a theme in there favorite CMS. TYPO3 provides the excellent Templavoila system as an example. You just get a template, map it in TYPO3 and off you go. you don’t need to put ANY markers, engines or what not in it. If you get a new template from teh designer (given that the ID’s are the same) you just drop it in a folder and your website will use that! Also the fact that a template is full with portal rubbish like application.css, portlet.css, wiki images , progress bar images etc etc…

When I try to look at it from a users perspective the screens in liferay looks messy and un-organized.

Form and presentation is quite nice for people that don’t know, it allows you to define a custom way to present specific content.

When looking for a scripting language, I don’t see anything in there, at least not by default, items like menu rendering is not in Liferay. It has some items like ‘Navigation’ But doesn’t allow you to decide WHAT should be in the navigation.

What I really don’t like is how content is edited IN the web-page currently for a designer this means you need to make much more CSS so it looks presentable. By default it looks horrible.

Currently I give Liferay still a change, but if you say TYPO3 has a steep learning curve, then better get double ready for Liferay!

Ries

Thanks !

Warm Regards,
Ruben.

First I think the point of the post was that Liferay is much more than a portal. It’s a soup-to-nuts framework. It comes with scaffolding capability for creating database-driven applications, UI capabilities and many out of the box services. Some of these capabilities are stronger than others. I think there is little question that if you need to build an application that requires the kind of social frameworks and other services as well as the application aggregation that a portal provides, the Liferay framework is going to give you a very big boost in productivity.

On the subject of built-in portlets and the use of scriptlets: over time Liferay has built up its tag libraries and most recently, its use of client side UI based on JQuery. JSP based applications seems to be a preferred approach at Liferay but use of tag libs is definitely a best practice. There are portlets that have a lot of scriplets in them and I agree with you that it’s not ideal. My sense is that this is not the approach going forward.
With respect to the Dependency Injection concern, I’m note sure I follow how the static methods making debugging harder. The class loader proxies is not something I am a huge fan of and I would agree that they can make debugging more difficult — that is however a separate issue from the static method approach. Although Liferay uses Spring under the hood (which supports setter and constructor injection,) the IoC (inversion of control) pattern Liferay uses in their framework is more akin to a Service Registry (but without the lookup step.)
If I had to point to an issue here, it would be that the static method based services sort of imply that there is one service implementation that meets the service interface. Some might think that in practical terms this is generally the case anyway but I disagree. I think you want to either use setter injection or a registry that allows you to get after more than one implementation. Long story short. I don’t think what Liferay is doing is “Wrong.” It doesn’t use Spring the way many projects do but this is mainly due to the fact that Liferay pre-dates Spring’s dominance. Also, it’s important to note that there is a lot of re-factoring in this area of Liferay still in play.
On documentation, I think the Service Builder methods should have more. Service Builder does allow you to add comments to many of the files it creates - and that capability should be used.

I hope to convey the sense here that we’re not just blogging for marketing effect. We’re not going to say that every last thing about Liferay is perfect. But let’s face it… no project is perfect. The best you can hope for is that the project is a) useful and, b) actively making progress. Brian Chan and Co. at Liferay work as hard as anyone I know at making their platform better with each release. IMO there is no doubt that Liferay can deliver value and that it can save you time and money. I’ve had both good and bad experiences with Liferay. It’s not the right framework for every need — and that’s the key. Liferay has a lot of features that tend to draw folks in. You need to ask hard questions about what you’re trying to do and what you actually need — and then go with the framework that gets you there with the right balance of time, cost, and runway.

-R

The built-in portlets are extremely messy, with java scriptlets scattered all over the JSP pages, the architecture doesn’t use dependency injection properly, instead relying on calls to static util classes which makes it very difficult to debug and fix anything. If you use the service builder it creates method signatures that are longer than I would like an entire class to be. There are no comments in the code (and I mean none) and the code is not self documenting in the slightest. There’s also no decent technical documentation for the code/architecture.

If you’re just deploying your own portlets to it as a container then it’s ok, but if you have to change anything that is built-in, or delve into the actual code then it quickly becomes a very painful way to go.

You are right SURF is not a JSR-168/268 compliant portal. If you need the kind of plugability of application frameworks that the standard provides — then you need a portal. That is to say, if you want to run a Struts application next to a Spring MVC application then a Portlet spec compliant container is going to give you a lot right out of the box.

SURF does not mandate a remote invocation from a framework perspective. It’s easy to conclude from what is provided out of the box that this is the case given the bias on webscripts but it is also very possible to implement other types of renders and from there consume local resources, spring bean based resources.