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 <[EMAIL PROTECTED]> 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 > > <[EMAIL PROTECTED]> 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 > > > > <[EMAIL PROTECTED]> > 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 * > > > > > * <[EMAIL PROTECTED]> * > > > > > * <http://www.einnovation.com> * > > > > > > * -------------------------------------- * > > > > > * Apache Jetspeed Enterprise Portal * > > > > > * Apache Pluto Portlet Container * > > > > > * * > > > > > * OpenEditPro, Website Content Mangement * > > > > > * <http://www.openeditpro.com> * > > > > > ****************************************** > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > > > > > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > __________________________________ > > > > Do you Yahoo!? > > > > Friends. Fun. Try the all-new Yahoo! > Messenger. > > > > http://messenger.yahoo.com/ > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > -- > > > ****************************************** > > > * Scott T. Weaver * > > > * <[EMAIL PROTECTED]> * > > > * <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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
