Without cluttering the js/API itself, not so much, JavaScript itself doesn't have an internal enumeration type, usually this is worked around by having a static class that has each key to a paired value that is used, this makes the code more obvious as you can use friendly inferences maybe through an enum helper...
if (Enum.contains(enumeration, value)) ... would be easier against multiple enumerations as opposed to creating static case statements... I don't know all the specifics of the JS for shindig, just javascript in general. -- Michael J. Ryan -- Software Developer -- Apollo Group > -----Original Message----- > From: Dan Brickley [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 26, 2008 3:50 AM > To: [email protected] > Subject: Re: Schema sources (was Re: Shindig PHP Architecural Overview > Article) > > Dan Brickley wrote: > > Rajdeep Dua wrote: > >> Thanks for the encouraging feedback. > >> Chris - I will make the changes based on your feedback > >> > >> The schema diagram has been drawn manually -- no auto-generation as > >> of now > >> ,exploring various tools to do this. > > > > Ah ok. Where in the PHP/Java/Javascript sources (or wiki etc) is the > > most authoritative source spec for the schema? I'm looking at mapping > > this stuff into RDF/FOAF, but for now have just worked from one of > the > > demo SQL backends that was circulated... > > Kevin Marks in IRC gently encouraged me to look in the spec, > > phenny: danbri: 07:27Z <KevinMarks> tell danbri OpenSocial Person field > is in the Spec: > http://code.google.com/apis/opensocial/docs/0.8/reference/#opensocial.P > erson.Field > > Which apart from making me realise it was a dumb sounding question, > makes me also clarify my question: is there a *machine-friendly* schema > of some kind that can be used as a common authoritative source. The > spec > source doesn't seem designed (microformats-style) to be machine-parsed. > > To which Kevin in IRC is just now replying: these docs are generated by > javadoc from the Javascript API source. And a copy of that seems to be > in the Apache SVN: > > http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/openso > cial-reference/person.js > ...and more in > http://svn.apache.org/repos/asf/incubator/shindig/trunk/features/openso > cial-reference/ > > > So I'll treat that as authoritative at least until I find a copy on the > main opensocial site... > > > Looking there in person.js I see (to use gender as an example) > > /** > * Person's gender, specified as an opensocial.Enum with the enum's > * key referencing opensocial.Enum.Gender. > * Container support for this field is OPTIONAL. > * > * @member opensocial.Person.Field > */ > GENDER : 'gender', > > ...but nothing more in the js to associate either 'GENDER' or 'gender' > with the enumerated values (rather than, say, a string). All the typing > information is in the comments. > > Over in enum.js we see the enumerated values, but I don't see how to > programmatically associate them with the GENDER field: > > /** > * @static > * @class > * The enum keys used by the gender field. > * <p><b>See also:</b> > * <a href="opensocial.Person.Field.html"> > * opensocial.Person.Field.Gender</a> > * </p> > * > * @name opensocial.Enum.Gender > */ > opensocial.Enum.Gender = { > /** @member opensocial.Enum.Gender */ > MALE : 'MALE', > /** @member opensocial.Enum.Gender */ > FEMALE : 'FEMALE' > }; > > > Am I missing something obvious? Is there a way I can write a bit of .js > to determine that one field is string-valued, while another takes an > enum? > > thanks for listening ;) > > cheers, > > Dan This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
