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?
-aaron
On 8/23/06, David Sean Taylor <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
