You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Raphaël Luta <ra...@apache.org> on 2005/05/16 11:22:39 UTC
Per-page parameters in J2.
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
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)
- How can we restrict the parameters so that portlets are not exposed
to everything that jetspeed may want in its URL ?
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)
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 ?
--
Raphaël Luta - raphael.luta@aptiwan.com
Aptiwan, l'intelligence du réseau - http://www.aptiwan.com/
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Per-page parameters in J2.
Posted by Raphaël Luta <ra...@apache.org>.
Ate Douma wrote:
> Raphaël Luta wrote:
>
>> Context:
>> --------
>> <snipping context>
>> 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.
>
You're right. let's stop considering this option. It's ugly and won't
work.
>>
>> 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.
>
As far as I can see, the spec only states:
PLT 11.1.1: A portlet must not see any parameter targeted to other portlets.
Since the page parameters can be considered to be "targetted" to every
portlets on a page, so I don't think such an extension would break
JSR-168 compliance.
>> - 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.
>
I've not looked at Pluto enough for this, but I would think
reimplementing the code that's responsible for filtering the servlet
parameters to create request parameters should be enough.
>>
>>
>> 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.
I assume you're using PortletWindow as defined by Pluto, ie a facet of
a PortletEntity rather than the generic JSR168 term.
If I understand correctly the current J2/Pluto we have, the actual
limitation is that J2/Pluto supports only 1 PortletWindow per
PortletEntity (and thus a single preference set).
Is that what you want to address ?
> 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.
>
In your above hierarchy, are you proposing this:
Default-prefs -> protlet entity prefs -> page prefs -> portlet window
prefs ?
Hmmm... that's a tough call because if you break the 1 entity = 1 window
relation, the actual scope of a PortletEntity is not really well defined
and rather orthogonal to the notion of Page.
I guess a lot would then depend on how entities are created in your
portal and wether you allow reuse of an entity across pages.
> 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.
>
I don't see how naming conflicts can arise: if a portlet doesn't need
the preference, then it's just a nuisance. If a component already has
a specific pref value for the global name, it will shadow the global
value as expected.
> 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).
>
Agreed, but we don't necessarily have to wait for the spec, we can go
and create our own API extensions, Jetspeed 2 is not the RI :)
> So, I'd give a +1 to option 3, and suggest to look at Portlet Window
> prefs support as well.
>
OK, let's think about that as well...
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Pluto dependency
Posted by David Jencks <da...@yahoo.com>.
As usual, I wasn't quite clear enough :-)
The idea is to use the revision number of the last pluto change
included in the jar. Then, anyone can reproduce the jar contents by
checking out that pluto revision and building. My pluto archive
indicates 164158 as the last revision, so I'd use that. (I recently
realized that svn up reports "at version xxx" where xxx is the last
commit at apache, not the project you are updating)
thanks
david jencks
On May 17, 2005, at 6:23 AM, David Sean Taylor wrote:
> David Jencks wrote:
>> Since pluto is using svn, you might want to use the svn revision
>> number as the version number.
>> pluto-PRIVATE-12345678.jar
>> would leave no doubt about the provenance and contents of the jar and
>> let anyone reproduce it at will by checking out that revision.
>>
> That makes sense.
> Which file's revision number do you recommend, since the jar is not
> checked into SVN?
>
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> [office] +01 707 773-4646
> [mobile] +01 707 529 9194
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Pluto dependency
Posted by Santiago Gala <sg...@hisitech.com>.
El mar, 17-05-2005 a las 06:23 -0700, David Sean Taylor escribió:
> David Jencks wrote:
> > Since pluto is using svn, you might want to use the svn revision number
> > as the version number.
> >
> > pluto-PRIVATE-12345678.jar
> >
> > would leave no doubt about the provenance and contents of the jar and
> > let anyone reproduce it at will by checking out that revision.
> >
> That makes sense.
> Which file's revision number do you recommend, since the jar is not
> checked into SVN?
>
The release number is 170613 right now (the moment I sent the message).
It gets incremented sequentially with every commit in the whole
repository.
Regards
--
Santiago Gala <sg...@hisitech.com>
High Sierra Technology, SLU
Re: Pluto dependency
Posted by David Sean Taylor <da...@bluesunrise.com>.
David Jencks wrote:
> Since pluto is using svn, you might want to use the svn revision number
> as the version number.
>
> pluto-PRIVATE-12345678.jar
>
> would leave no doubt about the provenance and contents of the jar and
> let anyone reproduce it at will by checking out that revision.
>
That makes sense.
Which file's revision number do you recommend, since the jar is not
checked into SVN?
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Pluto dependency
Posted by David Jencks <da...@yahoo.com>.
Since pluto is using svn, you might want to use the svn revision number
as the version number.
pluto-PRIVATE-12345678.jar
would leave no doubt about the provenance and contents of the jar and
let anyone reproduce it at will by checking out that revision.
thanks
david jencks
On May 16, 2005, at 10:59 AM, David Sean Taylor wrote:
> Im about to change the Jetspeed dependencies on Pluto.
>
> The Pluto SVN head, which builds to 1.0.1-rc3, has fixes for:
>
> http://issues.apache.org/jira/browse/JS2-254
> http://issues.apache.org/jira/browse/PLUTO-100
>
> However, I don't think that Pluto will release before the M3 release.
> We will need a version of Pluto to build the M3 release against.
> Im recommending that we use a version that I built today here:
>
> pluto-1.0.1-rc3.jar
>
> that I will upload to my remote server.
>
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> [office] +01 707 773-4646
> [mobile] +01 707 529 9194
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Pluto dependency
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor wrote:
> Im about to change the Jetspeed dependencies on Pluto.
>
> The Pluto SVN head, which builds to 1.0.1-rc3, has fixes for:
>
> http://issues.apache.org/jira/browse/JS2-254
> http://issues.apache.org/jira/browse/PLUTO-100
>
> However, I don't think that Pluto will release before the M3 release.
> We will need a version of Pluto to build the M3 release against.
> Im recommending that we use a version that I built today here:
>
> pluto-1.0.1-rc3.jar
May I suggest to use a less confusion version?
Something like pluto-1.0.1-20050516.jar or pluto-1.0.1-rc3-20050516.jar
>
> that I will upload to my remote server.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Pluto dependency
Posted by David Sean Taylor <da...@bluesunrise.com>.
Im about to change the Jetspeed dependencies on Pluto.
The Pluto SVN head, which builds to 1.0.1-rc3, has fixes for:
http://issues.apache.org/jira/browse/JS2-254
http://issues.apache.org/jira/browse/PLUTO-100
However, I don't think that Pluto will release before the M3 release.
We will need a version of Pluto to build the M3 release against.
Im recommending that we use a version that I built today here:
pluto-1.0.1-rc3.jar
that I will upload to my remote server.
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: Per-page parameters in J2.
Posted by Ate Douma <at...@douma.nu>.
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
Re: Per-page parameters in J2.
Posted by David Sean Taylor <da...@bluesunrise.com>.
Raphaël Luta wrote:
>
> 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 also like option #3 as it fits very nicely (with the fallback) into
the Portlet API's preferences design. Portlets will not need any
Jetspeed specific code to use it. Perhaps we can have some influence in
getting this feature into the next version of the API.
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org