Sorting and Localization for Navigation Portlet

[gruenewa]

Hi Community,

Doug Schnelzers JIRA entry (http://jira.jboss.com/jira/browse/JBPORTAL-585) on localization and sorting of the navigation tab is very interesting. But possibly it should be considered to make the navigation tab labels editable through the preferences of the navigation portlet. This way the navigation tab could be configured using the management portlet by some portal administrator. Just my two cents on this topic ;-)

[keletappi]

I agree that tab labels and sorting should be editable online. But putting this into preferences of navigation portlet, makes it impossible to have this configuration shared in case you want to have different implementation of navigational portlet on different pages.

BTW this navigation portlet is very nice feature in JBoss Portal compared how things are done in jetspeed2 side. There navigation is done in layout velocity template - and each layout have own implementation of navigation. It is not as flexible as in JBoss because you can't change navigation fragment freely independently.

I don't like the idea of having 'resource bundle ref' in page definition either, because it makes it requirement to have separate file for language resources and makes it harder to get started. I can live with that, but there I would like to use jetspeed2 system.

In jetspeed2 this is solved by adding initial language resources of page names in psml files (one psml file defines one page in jetspeed2). Also ordering of pages is in psml file. This makes it fast and easy to add language resources. In jetspeed2 they also lack ability to modify page names and language resources online but it is coming soon I hope.

[gruenewa]

I agree that tab labels and sorting should be editable online. But putting this into preferences of navigation portlet, makes it impossible to have this configuration shared in case you want to have different implementation of navigational portlet on different pages.

Yes, you are right. I didn't consider this important point. The page names must be shared between different portlets like catalogue portlet and navigation portlet.

[ivanlatysh]

I am always wonder why people suffer but still taking the wrong tools for the job.
Navigation portlet should provide navigation data and _must_ have separated presentation. And for presentation there is a perfect candidate - language that designed to transform data into whatever you want - xsl. (not Velocity that is a perfect for templating but ugly for transforming)

So a simple scenario:

Navigation portlet produce XML with navigation components, preferences, etc. watever you want.
After it wrapped up with renderer (xslt transformation) that will produce an output. Here it can accomodate even Velocity renderer.

But the point is :
Since this scenario has a well defined separation of business logic (obtaining portal navigation data) from presentation (construction of html havigation fragment) you can acheve almost any look and feel that you might want.

A simple example of right approach:
I want to have my navigation in flash. How can I achieve it ?
With separated presentation layer - easy.
With current implementation - it's scare me.

Anyway I have to write proper navigation portlet for my portal ...

[mholzner]

agreed that the current implemetation is simplistic.

BUT: stay away from xsl !!!!
It's nice on the surface, but it is a HUUUUUUGE performance bottle neck , even if you cache the templates / transformer (watch for thread safety!!)

and speaking of : at least xalan is not thread safe ! So you'll get flexibility at the cost of performance and thread safety. I'd rather write one logic service and several UI adaptors (i.e. portlet; i.e. JSPs, one per style). And don't forget that a lot can be achieve with CSS without any change to the java code....

I was in xsl land for several years, and don't miss it ! (well, ok , sometimes ;)

[mholzner]

"keletappi" wrote:

In jetspeed2 this is solved by adding initial language resources of page names in psml files (one psml file defines one page in jetspeed2). Also ordering of pages is in psml file. This makes it fast and easy to add language resources. In jetspeed2 they also lack ability to modify page names and language resources online but it is coming soon I hope.

Once you have to support multiple languages and have a good set of pages and portlets, you'll rethink that. Now think you get big enough to send your localization needs to a 3rd party, and now you have to mix and merge what you get back into a mix of resource bundles and slew of xml files. I'd stay away, and rather do one thing, and that is resource bundles! A bit heavier in the beginning , but you'll be thankful later on.

[keletappi]

Yes resource bundles are handy what comes to 3rd party translation I have to agree on that.

I am not just sure how you are going to make deployment of resource files easy. I mean that I have ear that contains my portlets, portal pages, custom layouts and themes and all the stuff in nice package.

If I put resource bundles in my ear, are those visible to navigational portlet in that is in portal core project without some kind of special deployment ?

[ivanlatysh]

Multi language support is another `vote` for separation logic from presentation.

Deployment of resources is easy. The trick is to package them separately from your application, have a look at Tomcat (apache-tomcat-5.5.15\common\i18n\).

The idea is that you add your resources to classpath and use ResourceBundle at runtime to look for required resource bundle. As a result of such approach when you need to localize your application you make a new resource bundle, put it into your classpath and restart an application, no logic need to be changed.

You may check http://java.sun.com/developer/TechTips/1998/tt0521.html#tip2 for reference.
There is some performance consideration with resource bundles, but there is a few solutions for it.

2 mholzner:
I am sorry that you had such a bad experience with xslt processors, but in numerous system that I designed and develop I haven't seen a single case of bottle-neck caused by xslt processor. I can't say anything about xalan, I am using saxon and newer had problem with it. I am using WebModels framework with xslt based view, and it perform quite well even on junk hardware.

[keletappi]

So I need to put my resource files available into classpath so, that it is visible to navigational portlet (ie one in core portal project). Does this mean that i need to copy it into ie. server/default/lib ?

I don't have much experience in jboss yet but for me it seems that i need to restart jboss server to make changes applied. Or is there some other way to put them in classpath ?

[mholzner]

This thread is getting confusing for me:

You should be perfectly fine packaging your portlet(s) in a separate WAR and deploying that to the appserver that hosts the portal. As long as all your resources that the portlet uses are in the same context (WAR) you should be fine; there are no class loading issues I can think of

The execution of the portlet happens in the context the portlet was deployed in, not in the portals context, i.e. there is a RequestDispatcher involved.

[keletappi]

Problem is that navigation portlet is in one context and *-object.xml that defines the page and what resource bundle to use is in another.

In my opinion resource files involved with pages defined in *-object.xml should be as close as possible to war that actually defines it. So resource files should be prereffably in same ear/war making is possible to make easy single file deployment of entire portal. But resource files are then not visible to navigational portlet this way.

Putting files into servers classpath could be one solution. I tried this one but it seems that i need to restart server to make changes in resources effective. I don't know is there way to make it reloadable. But generally this would force me to do at least 2 files and maybe some additional configuration to jboss to make it possible to hot-deploy new resources.

I still think that following something like jetspeed2 is doing is better solution so that language resources are deployed where page is defined. I don't see how this is harder for 3rd party translator to do than fiddling with resource files. It is as easy to add translation to *-object.xml file.

And I don't see it as issue because in my experience it is quite rare to even use 3rd party translations in small to medium scale projects. I see that making deployment easy is more important because everybody must do it to make portlets available in the first place.

BTW there are more pressing issues than this what comes to localization of page names - it seems that at least scandinavian characters in page name causes all links on page to fail with 404. So even single language pages in finnish language are not working yet ;)