portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject psml prefs
Date Wed, 23 Aug 2006 17:03:40 GMT
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 

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 

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 

<!DOCTYPE database SYSTEM 
<!-- 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" 
         <unique name="UK_ENTITY_ID">
             <unique-column name="ENTITY_ID"/>

     <table name="JET_PREFS">
         <column name="PREF_ID" primaryKey="true" required="true" 
         <column name="ENTITY_ID" type="VARCHAR" required="true" 
         <column name="PREF_TYPE" type="VARCHAR" required="true" 
         <column name="PRINCIPAL" type="VARCHAR" required="true" size="60"/>
         <column name="PREF_NAME" type="VARCHAR" required="true" 
         <column name="PREF_VALUE" type="VARCHAR" required="true" 
         <foreign-key foreignTable="JET_ENTITY" onDelete="cascade">
             <reference foreign="ID" local="ENTITY"/>
         <index name="JET_PREFS_IX1">
             <index-column name="ENTITY_ID"/>
             <index-column name="PREF_TYPE"/>
             <index-column name="PRINCIPAL"/>

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

View raw message