You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Nick Lothian <ni...@mackmo.com> on 2005/01/01 04:24:38 UTC
Re: Some thoughts about portlet api: Dynamic portlet preferences
David Barral wrote:
>
> Greetings.
>
> Looking at the JSR168 and the Api Javadoc I see that the API allows
> the creation of portlet preferences that are not listed in the portlet
> deployment descriptor (using the setValue/setValues and store).
>
> I believe this is a semantic problem. Is there any reason to allow
> this beahaviour. Honestly I don't get it cause a portlet should
> declare in its portlet XML de preferences that affect its
> customization. Why should the portlet create new ones? I've been
> thinking for a while and everything can be mapped to a fixed set of
> properties.
>
There are many use cases where dynamic properties are appropriate. For
instance, if a portlet needs to store metadata about dynamicaly
generated fields that will be displayed to the user it might be
appropriate to store them as preferences.
Another example: In the portlet spec they give an example of a stock
quote portlet, where the stock tickers to display and the frequency to
refresh them are stored as preferences. If each stock ticker could have
a different refresh period then dynamic preferences make it easier to
store these different refersh periods.
> If the aim is to store properties that affect the mechanics of the
> portlet, seems to be wrong because the model layer beneath the
> portltet should handle that.
>
If you are attempting to write portlets that are portable across many
portals then it may well be appropriate to preferences for things that
would normally be done from a database.
Nick
Re: Some thoughts about portlet api: Dynamic portlet preferences
Posted by David Barral <da...@elrincondelprogramador.com>.
I don't think we can reach an agreement here. Anyway thanks for the effort.
Nick Lothian wrote:
> David Barral wrote:
>
>>
>>>> Greetings.
>>>>
>>>> Looking at the JSR168 and the Api Javadoc I see that the API allows
>>>> the creation of portlet preferences that are not listed in the
>>>> portlet deployment descriptor (using the setValue/setValues and store).
>>>>
>>>> I believe this is a semantic problem. Is there any reason to allow
>>>> this beahaviour. Honestly I don't get it cause a portlet should
>>>> declare in its portlet XML de preferences that affect its
>>>> customization. Why should the portlet create new ones? I've been
>>>> thinking for a while and everything can be mapped to a fixed set of
>>>> properties.
>>>>
>>>
>>> There are many use cases where dynamic properties are appropriate.
>>> For instance, if a portlet needs to store metadata about dynamicaly
>>> generated fields that will be displayed to the user it might be
>>> appropriate to store them as preferences.
>>>
>>> Another example: In the portlet spec they give an example of a stock
>>> quote portlet, where the stock tickers to display and the frequency
>>> to refresh them are stored as preferences. If each stock ticker could
>>> have a different refresh period then dynamic preferences make it
>>> easier to store these different refersh periods.
>>
>>
>>
>> I can't agree here. I have seen StockQuotePortlet implementations that
>> use a fixed set of properties.
>> Using dynamic preferences isn't neccesarly an easier way of handling
>> that case. Suppose that this portlet also have other preferences (i.e.
>> the amount of info provided, in other words, the columns that are
>> shown in the Ticker Table).
>> In order to display the stocks quotes you must do something like:
>> for each preference in the preference map {
>> if it's not the info amount preference {
>> Refresh ticker quote if needed;
>> Write ticker quote;
>> }
>> }
>>
>> You could avoid this by using two array "tickers" and "refreshPeridos".
>> Moreover if you want to allow the user to reset the quotes to the
>> original ones (defined in the portlet.xml) yo must do the same as
>> above but calling reset instead of writting the ticker. It's more
>> complicated than two resets "reset(tickers), reset(refreshPeriods)".
>>
>> I'm assuming that multivalued preferences are always ordered so I can
>> solve the problem with two arrays. I don't remember reading anything
>> about order in JSR168, but the use of arrays semantically implies that
>> the preferences are ordered (in our framework order is mantained. Also
>> a HttpServletRequest do so with the POST/GET parameters. Seems to be a
>> reasonable asumption).
>>
> The point isn't that you can solve that particular problem in another
> way - the point is that dynamic preferences are useful in this case
> because they allow extra flexibility in the way you implement your
> solution.
>
> (BTW, There is nothing in the specification that specifies ordering of
> values in a multi-valued preference.)
>
> [snip]
>
>> references system.
>>
>>>
>>>> If the aim is to store properties that affect the mechanics of the
>>>> portlet, seems to be wrong because the model layer beneath the
>>>> portltet should handle that.
>>>>
>>>
>>> If you are attempting to write portlets that are portable across many
>>> portals then it may well be appropriate to preferences for things
>>> that would normally be done from a database.
>>
>>
>>
>> The problem here is very similar. It can be also solved with a fixed
>> amount of preferences.
>> It's important to notice that the portlet cannot assume the way the
>> portal manage the persistence. For instance if the portal use LDAP
>> (preferences are supposed to be set few times and read many so it fits
>> better than a DB) handling that kind of portltet would decrease
>> performance.
>>
>> I see your point but don't you think that kind of portability should
>> be addressed with WSRP? Such a portlet with heavy model layer should
>> work with the producer DB (i.e. Amazon offers a portlet, it uses the
>> signon and customization features from the portal, but customer info
>> stays under Amazon). Maybe the Stock Quote portlet (or any typical
>> MyXXXX portlet) isnt't enough to study in depth the portal/portlet
>> scenario.
>>
> I should be able to implement my portlet as a complete application using
> only JSR-168 (no WSRP).
>
>> I strongly believe the future scenario will consist of Internet
>> portals (MyYahoo clones) that will use WSRP remote portlets and very
>> few, specific and light local portlets, and Intranet portals that will
>> use heavier local portlet based on DB/WebService model layers.
>>
> I tend to disagree. I'm not a big believer in WSRP - especially not for
> Internet portals or anywhere where performance is important.
>
--
/**
* David Barral
* El Rincón del programador [http://www.elrincondelprogramador.com]
* david@elrincondelprogramador.com
*/
Re: Some thoughts about portlet api: Dynamic portlet preferences
Posted by Nick Lothian <ni...@mackmo.com>.
David Barral wrote:
>
>>> Greetings.
>>>
>>> Looking at the JSR168 and the Api Javadoc I see that the API allows
>>> the creation of portlet preferences that are not listed in the
>>> portlet deployment descriptor (using the setValue/setValues and store).
>>>
>>> I believe this is a semantic problem. Is there any reason to allow
>>> this beahaviour. Honestly I don't get it cause a portlet should
>>> declare in its portlet XML de preferences that affect its
>>> customization. Why should the portlet create new ones? I've been
>>> thinking for a while and everything can be mapped to a fixed set of
>>> properties.
>>>
>>
>> There are many use cases where dynamic properties are appropriate.
>> For instance, if a portlet needs to store metadata about dynamicaly
>> generated fields that will be displayed to the user it might be
>> appropriate to store them as preferences.
>>
>> Another example: In the portlet spec they give an example of a stock
>> quote portlet, where the stock tickers to display and the frequency
>> to refresh them are stored as preferences. If each stock ticker could
>> have a different refresh period then dynamic preferences make it
>> easier to store these different refersh periods.
>
>
> I can't agree here. I have seen StockQuotePortlet implementations that
> use a fixed set of properties.
> Using dynamic preferences isn't neccesarly an easier way of handling
> that case. Suppose that this portlet also have other preferences (i.e.
> the amount of info provided, in other words, the columns that are
> shown in the Ticker Table).
> In order to display the stocks quotes you must do something like:
> for each preference in the preference map {
> if it's not the info amount preference {
> Refresh ticker quote if needed;
> Write ticker quote;
> }
> }
>
> You could avoid this by using two array "tickers" and "refreshPeridos".
> Moreover if you want to allow the user to reset the quotes to the
> original ones (defined in the portlet.xml) yo must do the same as
> above but calling reset instead of writting the ticker. It's more
> complicated than two resets "reset(tickers), reset(refreshPeriods)".
>
> I'm assuming that multivalued preferences are always ordered so I can
> solve the problem with two arrays. I don't remember reading anything
> about order in JSR168, but the use of arrays semantically implies that
> the preferences are ordered (in our framework order is mantained. Also
> a HttpServletRequest do so with the POST/GET parameters. Seems to be a
> reasonable asumption).
>
The point isn't that you can solve that particular problem in another
way - the point is that dynamic preferences are useful in this case
because they allow extra flexibility in the way you implement your
solution.
(BTW, There is nothing in the specification that specifies ordering of
values in a multi-valued preference.)
[snip]
> references system.
>
>>
>>> If the aim is to store properties that affect the mechanics of the
>>> portlet, seems to be wrong because the model layer beneath the
>>> portltet should handle that.
>>>
>>
>> If you are attempting to write portlets that are portable across many
>> portals then it may well be appropriate to preferences for things
>> that would normally be done from a database.
>
>
> The problem here is very similar. It can be also solved with a fixed
> amount of preferences.
> It's important to notice that the portlet cannot assume the way the
> portal manage the persistence. For instance if the portal use LDAP
> (preferences are supposed to be set few times and read many so it fits
> better than a DB) handling that kind of portltet would decrease
> performance.
>
> I see your point but don't you think that kind of portability should
> be addressed with WSRP? Such a portlet with heavy model layer should
> work with the producer DB (i.e. Amazon offers a portlet, it uses the
> signon and customization features from the portal, but customer info
> stays under Amazon). Maybe the Stock Quote portlet (or any typical
> MyXXXX portlet) isnt't enough to study in depth the portal/portlet
> scenario.
>
I should be able to implement my portlet as a complete application using
only JSR-168 (no WSRP).
> I strongly believe the future scenario will consist of Internet
> portals (MyYahoo clones) that will use WSRP remote portlets and very
> few, specific and light local portlets, and Intranet portals that will
> use heavier local portlet based on DB/WebService model layers.
>
I tend to disagree. I'm not a big believer in WSRP - especially not for
Internet portals or anywhere where performance is important.
Re: Some thoughts about portlet api: Dynamic portlet preferences
Posted by David Barral <da...@elrincondelprogramador.com>.
>> Greetings.
>>
>> Looking at the JSR168 and the Api Javadoc I see that the API allows
>> the creation of portlet preferences that are not listed in the portlet
>> deployment descriptor (using the setValue/setValues and store).
>>
>> I believe this is a semantic problem. Is there any reason to allow
>> this beahaviour. Honestly I don't get it cause a portlet should
>> declare in its portlet XML de preferences that affect its
>> customization. Why should the portlet create new ones? I've been
>> thinking for a while and everything can be mapped to a fixed set of
>> properties.
>>
>
> There are many use cases where dynamic properties are appropriate. For
> instance, if a portlet needs to store metadata about dynamicaly
> generated fields that will be displayed to the user it might be
> appropriate to store them as preferences.
>
> Another example: In the portlet spec they give an example of a stock
> quote portlet, where the stock tickers to display and the frequency to
> refresh them are stored as preferences. If each stock ticker could have
> a different refresh period then dynamic preferences make it easier to
> store these different refersh periods.
I can't agree here. I have seen StockQuotePortlet implementations that use a fixed set of properties.
Using dynamic preferences isn't neccesarly an easier way of handling that case. Suppose that this portlet also have other preferences (i.e. the amount of info provided, in other words, the columns that are shown in the Ticker Table).
In order to display the stocks quotes you must do something like:
for each preference in the preference map {
if it's not the info amount preference {
Refresh ticker quote if needed;
Write ticker quote;
}
}
You could avoid this by using two array "tickers" and "refreshPeridos".
Moreover if you want to allow the user to reset the quotes to the original ones (defined in the portlet.xml) yo must do the same as above but calling reset instead of writting the ticker. It's more complicated than two resets "reset(tickers), reset(refreshPeriods)".
I'm assuming that multivalued preferences are always ordered so I can solve the problem with two arrays. I don't remember reading anything about order in JSR168, but the use of arrays semantically implies that the preferences are ordered (in our framework order is mantained. Also a HttpServletRequest do so with the POST/GET parameters. Seems to be a reasonable asumption).
In the end all is caused by the limitatiosn of the portlet prefrences in JSR168. Key-value/Key-values pairs isn't enough. Information is hierarchical by nature. Woudn't be great if we could write somethig as simple as
for each element in tickers {
refresh ticker.name if ticker.refreshPeriod exhausted
write ticker.name and value
}
To avoid this limitation coding of keys could be necessary (i.e. Preference pair [Ticker,Dell.12], Bookmark pair [bookmarks.browsers.Google,http://www.google.com]). Very nasty.
The spec said that portal vendor can provide a more powerful preferences system, but in my humble opionion that statement does little good to the standard. JSR168 should have definined a hierarchical preferences system.
>
>> If the aim is to store properties that affect the mechanics of the
>> portlet, seems to be wrong because the model layer beneath the
>> portltet should handle that.
>>
>
> If you are attempting to write portlets that are portable across many
> portals then it may well be appropriate to preferences for things that
> would normally be done from a database.
The problem here is very similar. It can be also solved with a fixed amount of preferences.
It's important to notice that the portlet cannot assume the way the portal manage the persistence. For instance if the portal use LDAP (preferences are supposed to be set few times and read many so it fits better than a DB) handling that kind of portltet would decrease performance.
I see your point but don't you think that kind of portability should be addressed with WSRP? Such a portlet with heavy model layer should work with the producer DB (i.e. Amazon offers a portlet, it uses the signon and customization features from the portal, but customer info stays under Amazon). Maybe the Stock Quote portlet (or any typical MyXXXX portlet) isnt't enough to study in depth the portal/portlet scenario.
I strongly believe the future scenario will consist of Internet portals (MyYahoo clones) that will use WSRP remote portlets and very few, specific and light local portlets, and Intranet portals that will use heavier local portlet based on DB/WebService model layers.
Regards and Happy new Year!!
David
--
/**
* David Barral
* MyPersonalizer Team [http://www.tic.udc.es/~fbellas/mypersonalizer]
* david@elrincondelprogramador.com
*/