portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Le Strat <dlest...@yahoo.com>
Subject Re: [J2] Prefs impl does not support adding properties in a transparent way.
Date Tue, 15 Jun 2004 23:22:27 GMT
Scott,

It depends how you look at it. When I started with the
Prefs implementation, my goal was mostly to use it for
user attributes.  And I felt that it was useful for
user attributes to have some consistency (basically
PLT17).

The implementation of Prefs is being used way behond
that scope so it may be time to tweak it to address
everyone needs.

An easy way to do this is to completely decouple the
PropertyManager from the prefs API.  And as we move
into that direction we may realize that we don't
really need the PropertyManager...  I am fine with
that, that's what software does, it evolves...

Regarding storing everything as String, sure.

Have a good one.

David.

--- Scott T Weaver
<scotts-jetspeed-list@binary-designs.net> wrote:
> I was able to able make modifications to the prefs
> api to exclude paths
> provided in a String[] in the constructor.
> 
> However, I am not happy with this solution.  David,
> I know you spent a
> lot of time on the PropertyManager, but I think it
> might be overkill.  I
> don't see where a user having a set of properties in
> a node that differs
> from another user's would cause an issue, that's why
> you can supply a
> default in the get*() methods ;).  
> 
> IMOHO, prefs should not force the type referential
> integrity we are
> currently enforcing with the property manager.  What
> I gather from the
> javadoc, Prefs represent a generic storage mechanism
> that can be
> tailored on a per user basis.
> 
> I also feel we should store all values as Strings
> relative to the DB and
> let Prefs api do the type conversion as opposed to
> storing the values in
> typed columns as we do now. 
> 
> 
> On Tue, 2004-06-15 at 09:04, David Le Strat wrote:
> > Scott,
> > 
> > Your suggestion makes sense. If you want to make
> that
> > change, I am fine with it.  FYI, I am going to be
> > unavailable for the next 2 weeks.
> > 
> > Regards,
> > David.
> > 
> > --- Scott T Weaver
> > <scotts-jetspeed-list@binary-designs.net> wrote:
> > > Hi David,
> > > 
> > > Here is my issue.  A portlet can have any number
> of
> > > preferences and
> > > those preferences can have any number of values.
> 
> > > For supporting
> > > multiple values, I took the approach of each
> > > preference being a node and
> > > it's values being any number properties (keyed:
> > > 1..n) within that node,
> > > so you can see where having the property manager
> all
> > > the time would
> > > really start to become a pain plus it exposes
> our
> > > implementation, which,
> > > IMOHO, is a bad idea.
> > > 
> > > There are default preferences that come with a
> > > Portlet in its descriptor
> > > and there are per entity/user preferences that
> will
> > > default to those in
> > > deployment descriptor.  However, a portlet is
> not
> > > limited to those
> > > defined in the portlet.xml i.e. more could be
> added
> > > my an admin or the
> > > user themselves.  So, as you can see, a user's
> set
> > > of preferences could
> > > differ from those provided in the deployment
> > > descriptor.
> > > 
> > > I think I would be happy with being able to
> exclude
> > > entire nodes and
> > > their descendants from the PortetManager
> > > restriction.
> > > 
> > > On Mon, 2004-06-14 at 22:48, David Le Strat
> wrote:
> > > > Scott,
> > > > 
> > > > The reason, I introduced this restriction was
> to
> > > be
> > > > able to tie preferences to property sets and
> > > enforce
> > > > consistency in the properties of a user
> profile
> > > for
> > > > instance.
> > > > 
> > > > I am not sure we would want to find yourself
> in a
> > > > situation where user A has property 1, 2, 3 on
> > > their
> > > > profile and user B property 1, 2, 6 and no
> > > consistency
> > > > in the definition of the profile properties.
> > > > 
> > > > Now, there are other ways to enforce that kind
> of
> > > > consistency that to enforce it at the prefs
> layer.
> > >  If
> > > > this is causing an issue, I am +1 on making
> > > changes,
> > > > as long as we keep in mind the point mentioned
> > > above.
> > > > 
> > > > Regards,
> > > > 
> > > > David.
> > > > 
> > > > --- Scott T Weaver
> > > > <scotts-jetspeed-list@binary-designs.net>
> wrote:
> > > > > Why do we have to
> > > PropertyManager.addPropertyKeys()
> > > > > to be able to add
> > > > > properties to a node?  I do no see anywhere
> in
> > > the
> > > > > java.util.Prefs docs
> > > > > where this a requirement.  Right now this
> has
> > > become
> > > > > a large road block
> > > > > in converting Portlet preferences to uses
> our
> > > Prefs
> > > > > impl.  I do not want
> > > > > to manually add allowed properties every
> time a
> > > new
> > > > > value is added to a
> > > > > portlet preference.
> > > > > 
> > > > > I vote +1 on removing this restriction.
> > > > > 
> > > > > Regards,
> > > > > -- 
> > > > > ******************************************
> > > > > *           Scott T. Weaver              *
> > > > > *         <weaver@apache.org>            *
> > > > > *     <http://www.einnovation.com>       *  
> 
> > > > > * -------------------------------------- *
> > > > > *   Apache Jetspeed Enterprise Portal    *
> > > > > *     Apache Pluto Portlet Container     *
> > > > > *                                        *
> > > > > * OpenEditPro, Website Content Mangement *
> > > > > *     <http://www.openeditpro.com>       *
> > > > > ******************************************
> > > > > 
> > > > > 
> > > > >
> > > >
> > >
> >
>
---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > > > jetspeed-dev-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail:
> > > > > jetspeed-dev-help@jakarta.apache.org
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > 	
> > > > 		
> > > > __________________________________
> > > > Do you Yahoo!?
> > > > Friends.  Fun.  Try the all-new Yahoo!
> Messenger.
> > > > http://messenger.yahoo.com/
> > > > 
> > > >
> > >
> >
>
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > jetspeed-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > jetspeed-dev-help@jakarta.apache.org
> > > -- 
> > > ******************************************
> > > *           Scott T. Weaver              *
> > > *         <weaver@apache.org>            *
> > > *     <http://www.einnovation.com>       *   
> > > * -------------------------------------- *
> > > *   Apache Jetspeed Enterprise Portal    *
> > > *     Apache Pluto Portlet Container     *
> 
=== message truncated ===



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 

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


Mime
View raw message