True. I have worked on Portal application and the Java's Portal API was unnecessary complex. Just the reason that it did not use Servlet API kills it.
I think just by using "jsp:inlcude"'s is all we need to create Portal like apps.

JSR286, the new Portal API (why couldn't they have numbered it 268, since the old JSR was 168), is much more in line with the Servlet and JSP API, with the requisite listeners and PortletFilters. But JSR286 support has only happened within the last year or so, so they do seem to be coming a little late to the ball.

I question the value of a portal server in a world with decent component frameworks like JSF, Wicket and .NET, at least on the server side.

I think folks just work at too low of a level (buttons and fields), but really there's no reason you can't write sophisticated portlets using component technologies today. Why not have a Forum component, Chat component, RSS Feed component.

Now, all of the corporate uses of portal tech I have seen have forgone the "lets move all this stuff around" ala yahoo etc. But even that technology is a pretty thin layer on top of the existing component frameworks.

Haven't Portals been out flanked by Open Social and Gadgets?

Tell that to the people who are about to release WebSphere Portal 7.

Hi,

Portals(both JSR) in my experience are not very efficient and too complex for development teams. It had never been successful amidst all hard work by the JSR teams. However the recent developments on the Flex side looks promising like AMF/Web services support, cairngorm, blazeds/spring etc and easier for java folks. This will certainly fulfill the rich internet experience using the Java platform

The question if and how to use a Portal Environment is just a question about what you want to integrate and who will use the Portal/Applications. The point that Portal is more complex than other frameworks or technologies is just a point of view. You are targeting a completely different solution when you integrate Business applications in an Enterprise than developing a customer website with a few applications.
A Portal server is no perfect solution for all situations, but I dont think it is going to be useless.

If you want to have Portal Solution with a bunch of applications that have a cool UI and a lot of Web 2.0 features than just integrate Google Web Toolkit (GWT) with the Portlets. So we did in the last nearly two years and our customers were surprised how fast the development cycle and how many UI features we could use with it.

See a few demos of what I'm talking here (german)
or at Google Apps Marketplace (german)

Well, I have published myself different posts about portlets:

Portlets in the light of OSGi and other technologies

The term "portal" is, at least, rather confusing!

Portlet life looks like EJB, but future sounds like GWT

The portlet/GWT comparison is in favor of GWT

My conclusion is that :
(1) portlets are very over-hyped and expensive to deal with
(2) portlets are a standardization of the portal concept at the wrong level.
Well, portal is a architecture concept, just like REST. Portlets are a standardization of this concept into the API level, and introducing too much contraints.
IMHO, portal concept should have been better defined, just like REST, at the architecture level.
(3) GWT, for example, enables to define faster better portals than portlet technology.

Dominique
http://www.jroller.com/dmdevito

Hi Manickadas,

I totaly agree with you. I found out  jAPS project (www.japsportal.org) which is a new kind of lightweight and flexible platform.

jAPS Team doesn't use portlet standards because they introduce many constraints and high costs in a project. 

Take a lokk at this jAPS Team article "What we think about Portlets Standards"

 

 

I completely agree with all of you! From a programmer point of view things are even worse. I have discovered that portlets are only a nice concept since they are _not_ portable! The classic "hallo word" portlet can be freely imported everywhere but a complex portlet, for what I have seen, always invokes core elements of the underlying framework that makes it not portable, at least in the implementation  I've seen to date.

Just my two cents!

Aukcell is a seasoned and recognized expert in all aspects of Liferay deployment ,which is based in China.It has successfully implemented sound Liferay portal custom solutions, including the solutions of e- Learning ,video portal ,education portal, government portal ,multi-systems integrate into Liferay, facebook and myspace integrate into Liferay portal and so many more.

At Aukcell you’ll find one-stop solutions for all your Liferay projects: From support, consulting and training we offer services to help you implement and develop Liferay based solutions.

Aukcell has great trainings that will teach you hands on to use Liferay the way it was intended,the onsite and online 5-day Liferay Portal Training which covers both portal administration and development as well as the custom online training package at a very cost effective price,the training language will be in English and Japanese.

If you are looking for the right-partner and cost effective solutions for Liferay Training ,Liferay consulting ,custom solutions and more ,then you have got the right place at the right time.

Contacts

General: support at aukcell dot com
Business: cherry at aukcell dot com
Skype : aukcell
AIM: eonpeter

Tel: +86-411- 84898263
Fax: +86-411- 84898263

www.aukcell.com