portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott T Weaver" <scotts-jetspeed-l...@binary-designs.net>
Subject RE: psml prefs
Date Wed, 23 Aug 2006 19:31:36 GMT
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:aaronmevans@gmail.com]
> 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 <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



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


Mime
View raw message