I do the same thing you do, Aaron, by using the preferences in the PSML as opposed to having multiple portlet definitions in my portlet.xml
I actually looked at doing init-parameters before using the prefs. IIRC, I ran into an issue regarding access to them. I forget exactly what it was now :-( Regards, -scott > -----Original Message----- > From: Aaron Evans [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 23, 2006 1:29 PM > To: Jetspeed Developers List > Subject: Re: psml prefs > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
