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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
