You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by David Le Strat <dl...@yahoo.com> on 2004/06/15 04:48:17 UTC
Re: [J2] Prefs impl does not support adding properties in a transparent way.
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
<sc...@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 *
> * <we...@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
Re: [J2] Prefs impl does not support adding properties in a transparent way.
Posted by David Le Strat <dl...@yahoo.com>.
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
<sc...@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
> > <sc...@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
> > > > <sc...@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 *
> > > > > * <we...@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 *
> > > * <we...@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
Re: [J2] Prefs impl does not support adding properties in a
transparent way.
Posted by Scott T Weaver <sc...@binary-designs.net>.
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
> <sc...@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
> > > <sc...@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 *
> > > > * <we...@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 *
> > * <we...@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!?
> Yahoo! Mail - You care about security. So do we.
> 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
--
******************************************
* Scott T. Weaver *
* <we...@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
Re: [J2] Prefs impl does not support adding properties in a transparent way.
Posted by David Le Strat <dl...@yahoo.com>.
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
<sc...@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
> > <sc...@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 *
> > > * <we...@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 *
> * <we...@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!?
Yahoo! Mail - You care about security. So do we.
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
Re: [J2] Prefs impl does not support adding properties in a
transparent way.
Posted by Scott T Weaver <sc...@binary-designs.net>.
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
> <sc...@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 *
> > * <we...@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 *
* <we...@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