portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: Per-page parameters in J2.
Date Mon, 16 May 2005 14:10:27 GMT
Raphaƫl Luta wrote:
> Context:
> --------
> I'm trying to implement a feature in J2 that is trivially available in 
> Jetspeed 1: per-page portal parameters.
> For example:
> I have in a portal project a PSML page that presents information on
> a city, aggregating many portlets on a page, from different 
> applications. Each portlet needs to know which city is being displayed 
> to adjust content.
> 
> Currently, as far as I can see, I only have 2 ways to do it in J2:
> #1 pass a "site" render parameter for each portlet window defined on the
>    page
> #2 define a "site" preference for each portlet and configure it either
>    through interactive "edit" mode or through batch update in the DB
>    backend.
> 
> Now, imagine that I want to present 1000 city information on 1000 
> pages... neither solution above is really satisfactory for (I hope)
> obvious reasons.
> 
> Since it looks to me as a common enough requirement, I'd like to
> implement something better unless I missed an already existing
> feature.
> 
> I can see different ways to implement such a feature with different
> advantages/drawbacks, so I'm looking for design feedback before
> starting to work.
> 
> Goal:
> -----
> Provide a mechanism in J2 to easily share a common parameter between
> all portlet windows displayed on a page.
> This mechanism must support portlets from multiple applications and
> scale both with the number of portlets par page and number of pages.
> 
> Option 1: PortletContext
> ------------------------
> First option to implement such a feature is to use the PortletContext
> to provide the portlet with those parameters.
> It can be implmented by a pipeline valve looking for global prefixed
> variables in the query string and putting this value in every
> portlet context for the current page.
> 
> Drawbacks:
> - portlet needs to actively look for a parameter in PortletContext
   - PortletContext attributes are not shared in a distributed container
     which may, or may not what you need or want
   - PortletContext is shared by all PortletEntities of the same Portlet,
     meaning your parameter will also be visible to other entities which
     may be displayed on another page.
     You can try to remove the parameter after the invocation but this
     is still no guarantee another user looking at that "other" page at
     the same time won't see this value.
     Furthermore, if this "other" page is similar in functionality, you
     might need another value for this parameter on that page.

In short, I don't think this will result is a solid solution.
> 
> Option 2: Extending namespace parameters
> -----------------------------------------
> Modify the Pluto PortletRequest implementation to allow parameters
> from a different namespace that the single portlet namespace to be
> seen by a PortletWindow.
> 
> Drawbacks:
> - Is it still JSR-168 compliant ? (I think so)
     Interesting.
     A JSR-168 compliant solution should always be considered very seriously.
     Can you explain why you think its might be compliant?
     I don't think JSR-168 says much about this but I might be missing something.

> - How can we restrict the parameters so that portlets are not exposed
>   to everything that jetspeed may want in its URL ?

I can't really comment on this option as you don't provide enough input
for me to see how this would be implemented.

> 
> 
> Option 3: Creating Page parameters in PSML
> ------------------------------------------
> Extend PSML to allow default preferences for all portlet on a page to
> be stored in a PSML definition.
> Such preference would be used as default values for any portlet on
> the page (if it doesn't have a speciifc value set in its own prefs).
> 
> exemple:
> 
> <page>
>   <page-preferences>
>     <preference>
>     <name>country</name>
>     <value>France</value>
>     </preference>
>     <preference>
>     <name>city</name>
>     <value>Paris</value>
>     <modifiable>1</modifiable>
>     </preference>
>   </page-preferences>
>   <fragment/>
> </page>
> 
> The preference hierarchy would then become:
> - Default-preferences (from Portlet.xml) (read only for a portlet)
>   -> Page-preferences (from PSML) (read only for a portlet)
>      -> Portlet Window prefs (from Prefs API) (read/write for a portlet)
           Isn't this just Portlet prefs? I don't think we have
           preferences on Window level, only Portlet instance level.
> 
> Optionally, a new valve component (or possibly the navigation 
> components) can update the PMSL preference values based on request or
> session URL.
> 
> Drawbacks:
> - New PSML syntax may have big impact.
> 
> Global drawbacks:
> ------------------
> Any portlet that need to set global parameters (to allow portal
> navigation links from the portlet itself need to be tied to Jetspeed
> since there's no JSR168 compliant way to achieve it.
> 
> My preferred option:
> --------------------
> My personal preference goes for option #3 as it allows to define
> a declarative explicit list of parameters/preferences passed to
> the portlets at config time whereas the first 2 methods are
> blanket pass-through (which may cause security concerns down the
> road).
> 
> Thoughts ?
> 
I fully agree (of course) that Page level parameters is a bit omission right now.
Especially the declarative nature of your option 3 makes me prefer that one as well.

And, may I suggest we could take this even further?
What about PortletEntity/Window prefs? (see my comment above). There already have
been numerous questions on the lists about configuring Portlets on a window basis.
A workaround used right now is to define different Portlet instances with different
init parameters/preferences in portlet.xml but that really is an ugly solution I think.
In my view the ultimate solution would be the following preference hierarchy:
   Default-preferences (from portlet.xml) (read only for a portlet)
   -> Portlet prefs (from Prefs API) (read/write for a portlet)
      -> Page-preferences (from PSML) (read only for a portlet)
         -> Portlet Window prefs (from Prefs API) (read/write for a portlet)

Note: in the above hierarchy I think the Page-preferences should override the Portlet prefs
as they are more specific. But, I haven't thought that through thoroughly yet so I might be
wrong here.

Using true PortletWindow prefs would also provide a finer grained solution that Page preferences
alone as you might have some more generic portlets on the page which don't need these global

parameters (like the layout portlets) and thus can result in parameter naming conflicts.

What the current JSR-168 really misses is a notion (model) for Page and Window and
the ability to attach preferences to them. I have no idea if/when we will see some
new activity for a newer JSR-168 version (I think it is overdue a long time already),
but when that starts I would be very surprised if nothing is thought out for this
(together with Portlet filters, Portlet services and inter portlet communication).

So, I'd give a +1 to option 3, and suggest to look at Portlet Window prefs support as well.

Regards, Ate


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message