portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Evans" <aaronmev...@gmail.com>
Subject Re: psml prefs
Date Wed, 23 Aug 2006 17:28:36 GMT
Hi David,
I'm not sure what other developers are using preferences in the PSML
for but generally when I use them in that way, I use them mainly as
portlet configurations so I can reuse the same portlet definition (in
portlet.xml) multiple times.

More often then not, I end up making them read-only since they are
more configurations than preferences.  My portlets have other
preferences that are designed to be user preferences rather than
configs, so it is for those that I need the per user stuff.

In a way, I would prefer (and this is just an idea for perhaps some
future release) it if I could override init-param values in the PSML
rather than preferences (ie. init-params specified in the PSML would
override the defaults in portlet.xml).

To me this would be of more use and I would stop using preferences as
configurations in favour of this new mechanism.  It would also make it
easier to employ as portlet configurations since you can't get
preferences until you have access to the request whereas init params
are available from the get-go in the init method of the portlet.

Comments from other developers?


On 8/23/06, David Sean Taylor <david@bluesunrise.com> wrote:
> Im looking at the PSML prefs feature.
> It doesn't seem right to me, but maybe I don't understand the goal of
> the developers.
> It appears that we wrapper/delegate the PortletApplication to the
> Entity/Prefs component, to intercept requests for default prefs from the
>   registry. If the current page has prefs, they are inserted into the
> preference tree, and as a side effect, the preferences impl eventually
> stores them overriding the default prefs for ALL entities, not just the
> current page. Is this the intended behavior?
> I would think it would make more sense to:
> * not intercept requests for default prefs out of the registry
> * not overwrite the default prefs 'in the registry'
> Prefs are stored 'in the registry' under the pref tree
> '/portlet_application', where as 'per user' and 'shared prefs' are
> stored under '/portlet_entity'
> Im trying to work out a better solution, and have come up with
> 1) psml pages must be deployed
> 2) during deployment, check for prefs in the psml, if found, write out
> to the prefs storage under
> /portlet_entity/{entity_id}/no_principal/preferences/...
> Using the no_principal nodes, the current entity manager will correctly
> fallback during pref search (if configured) from:
> 1. user prefs
> 2. no_principal prefs (psml prefs and 2.0 prefs)
> 3. default prefs (registry prefs)
> To be honest, it was never clear to me why PSML was the best place for
> pref definitions if they are going to be stored in the portlet registry
> These prefs are being used correctly, until a user customizes their
> prefs, at that point, the default prefs are no longer used (correctly),
> since user prefs are now being stored into the tree as
> /portlet_entity/{entity_id}/{username}/preferences/...
> After 10 months working with 2.0 in production, Im finding that the
> non-normalized representation of data makes data integration difficult
> in IT environments. For example, the principal tables are difficult to
> join against when we try to join user information with our tables. Same
> problem for prefs, with the non-normalized FULL_PATH. I've been playing
> around with a new schema for portlet prefs, which would be backed by an
> alternative entity implementation. Its just conceptual now, comments
> welcome.
> <!DOCTYPE database SYSTEM
> "http://db.apache.org/torque/dtd/database_3_2.dtd">
> <!-- Autogenerated by JDBCToXMLSchema! -->
> <database name="j2">
>      <table name="JET_ENTITY">
>          <column name="ENTITY_ID" primaryKey="true" required="true"
> size="100" type="VARCHAR"/>
>          <column name="APP_NAME" required="true" size="255" type="VARCHAR"/>
>          <column name="PORTLET_NAME" required="true" size="255"
> type="VARCHAR"/>
>          <unique name="UK_ENTITY_ID">
>              <unique-column name="ENTITY_ID"/>
>          </unique>
>      </table>
>      <table name="JET_PREFS">
>          <column name="PREF_ID" primaryKey="true" required="true"
> type="INTEGER"/>
>          <column name="ENTITY_ID" type="VARCHAR" required="true"
> size="100"/>
>          <column name="PREF_TYPE" type="VARCHAR" required="true"
> size="10"/>
>          <column name="PRINCIPAL" type="VARCHAR" required="true" size="60"/>
>          <column name="PREF_NAME" type="VARCHAR" required="true"
> size="255"/>
>          <column name="PREF_VALUE" type="VARCHAR" required="true"
> size="255"/>
>          <foreign-key foreignTable="JET_ENTITY" onDelete="cascade">
>              <reference foreign="ID" local="ENTITY"/>
>          </foreign-key>
>          <index name="JET_PREFS_IX1">
>              <index-column name="ENTITY_ID"/>
>              <index-column name="PREF_TYPE"/>
>              <index-column name="PRINCIPAL"/>
>          </index>
>      </table>
> </database>
> ---------------------------------------------------------------------
> 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

View raw message