No,
I'm suggesting that it would be nice to be able to use a constant as
opposed to a String literal to check the params of
Set<String> profileDetails
e.g. currently I have to do this:
if (profileDetails.contains("about_me")) {
...
}
I'd suggest being able to do this:
if (profileDetails.contains(Person.Field.ABOUT_ME)) {
...
}
as is the case with JS. Does that make more sense?
Ray
On Wed, 2008-04-02 at 23:18 +0200, Cassie wrote:
> Raymond -
>
> I'm a little confused. Are you simply saying we missed a field on the
> person object that exists on the opensocial javascript person object?
>
> Or, would you instead like to extend the Person.java class to add your
> own field?
>
> If it's the latter, then I would suggest making your own subclass of
> Person and returning that in your code. If it's the former, the
> aboutMe field in the javascript spec is a String, and the Person
> object has a matching String field. Because the javascript spec says
> that field must be a String there is no way to add additional
> properties or anything like you can with some of the other fields
> (address, organization, etc). Were you perhaps talking about a
> different field?
>
> Thanks!
>
> - Cassie
>
>
> On Wed, Apr 2, 2008 at 8:48 PM, Raymond Auge <[EMAIL PROTECTED]> wrote:
> > I'm wondering if you'd accept adding the fields to the Java entities
> > matching those in JS.
> >
> > If so, what form would you want them in?
> >
> > - public enum of entity (e.g. Person.Field.ABOUT_ME)
> > - public inner class with public static fields (e.g. looks like above)
> > - external class with public static fields (e.g. PersonField.ABOUT_ME)
> >
> > I can submit a patch over the weekend once I know if you want this.
> >
> > Would be nice to do this for all entities that have this in JS.
> >
> > Thoughts?
> >
> > Raymond Augé
> > Software Engineer
> > Liferay, Inc.
> > Enterprise. Open Source. For Life.
> >
>
Raymond Augé
Software Engineer
Liferay, Inc.
Enterprise. Open Source. For Life.
