Monday 1 December 2008

JSR 168 Portal Tech.

Portal technology, as in Java... is just not great.
Its like the guys who thought up the spec, never actually built something in anger before it was all approved and released and that sort of thing. It is just hard to do stuff in it that is really quite simple using normal Servlet style stuff. I.e. links to other portlets. The generated url is different on a per portal basis... so you can't hardcode it if you want to be portable... and each portal vendor seems to provide their own odd way of doing things. Argh.

And Portlets.... I spent the best part of last week trying to find a Wiki Portlet for JBoss Portal. A tricky task.
The only one that seemed to work is JBoss' own version and even then it doesn't seem to render the styles in the right place. We tried to get Xwiki working on JBoss and got so far with this list of changes:
  • changed XWikiPortletRequest to enable a conversion to a HttpServletRequest
  • modified components.xml to wire up core portlet components properly
  • change to stylesheets2.vm for IE directive
  • change to XWikiPortletResponse to enable conversion to a HttpServletResponse
  • added jboss-portlet.xml
  • added jboss-web.xml
  • changed the authorization to use container based stuff

It still didn't work. And when code was changed to make certain areas of the screen render, it was all over the show. Never mind the fact that it wasn't consistent in what it rendered and when.

Ah well. Its not that Xwiki isn't good... it looks great. The portlet support just isn't there at all yet.

Lets go back to Liferay....

3 comments:

Thomas Heute said...

I can understand your frustration, but I don't understand what you are really complaining about. Generated URL is much better than handling URLs by manipulating strings I think and a must if you want different applications to share a single page.
Also most web framework you will use won't even ask you to build a URL (such as JSF or Struts).

Many large portal applications are at the end using the portlet spec (directly or through a bridge), so it's not really fair to say that "the guys who thought the spec" did it wrong.

Now in your second part you mix applications and framework. Companies build their own applications (portlets) yes unfortunately I also wish they would share them more often.

That said you criticize the portlet spec and finish your entry with "Lets go back to Liferay...." which is using the spec you are flaming...

Although, I fully agree with you that too many applications make noise about their portlet support when it's very basic and far from being usable. It just gives a bitter taste to the portlet world unfortunately...

Marty said...

Hi Thomas,
Sorry if I appear to be flaming portal spec.... i didn't really mean it to come across like that. Perhaps my thinking has not fully moved over to working in Portal. Sometimes I feel a bit frustrated with it when certain things just seem to work better in basic web apps. I guess then the question is, do we really need a portal for the work we are doing? The answer to this is 'yes', because its mandated from above.

The main reason for suggesting 'back to liferay' is because it has its own integrated wiki, forums, blog etc that work out of the box which would have saved us some time fiddling with Of course there's issues with it too though! Its far from perfect too.

If you've any thoughts on how we should be generating links to other portlets not on the page, from a navigation portlet without using vendor specifics, I'd be glad to hear them.

Thanks for the comments.

Marty

Thomas Heute said...

Portlet specification is all about the portlet container, it doesn't deal with portal concepts. Portal concepts are left to the vendors.

You can't link to a portlet only to a page (where a portlet is diplayed), and a page is not a notion for the portlet container but for the portal, so there is no standard way to create a navigation portlet as you mention unfortunately.

Note that if you were to use a navigation webapp, you would also need a way to discover pages to display, probably using your own mechanism. One step after the other you might end up building a portal framework. I guess that's what "above" wanted to avoid :)

Of course I know nothing about what you are doing, it's also very possible that a portal is not a solution in your case.