[OPEN-ILS-DEV] IDL- fieldmapper classes

[Bill Erickson]

> I don't think we did, but generating the code at compile time seems
> best.  Something like:
>
>   package OpenILS::BuilderExtention;
>   use base 'OpenSRF::Builder';
>   ...
>   1;
>   __END__
>
>   use OpenILS::BuilderExtention;
>   OpenILS::BuilderExtention->compile( $xml_file );
>
> where OpenSRF::Builder is a generic class that provides hooks for
> subclassing so that non-native elements and attributes are handled
> automagically.


Cool, that makes sense.

>
> > > > The class hints save space and will need to be retained in some form
> to
> > > > support existing code.  I kind of like using the DB style
> > <schema>.<object>
> > > > ( action.survey) naming scheme, though, as the class name
> proper.  It's
> > > > descriptive and seemingly language neutral.
> > >
> > > Other than the fact that :: is used as a hierarchical separator for
> > > perl classes (and C++ and Java, too), I don't see any reason to do
> > > away with '::', but if you greatly prefer '.' I won't fight too hard.
> >
> > I prefer "." because it seems more universal, but I'll leave the dueling
>
> > gloves in their case ;)
>
> Well .... we should probably decide which to use for this project, but
> it sounds like we agree that there shouldn't be a restriction based in
> code, per se.
>
> I call for a vote!
>
> Option 1)  delimit class hierarchy with a period (.)
> Option 2)  delimit class hierarchy with a double colon (::)
>
> Bill and I can't vote (well, we've already voted) ... anyone else care at
> all?
>
> >
> > > However, I don't want the assumption to be that the class name maps
> > > directly to a database table, though, because 1) the DB will
> > > necessarily define keywords that make creating useful names hard
> > > (user, group and table, to name a few), and I don't want to place a
> > > restriction on the number of parts in the class identifiers, either.
> > > We already have some classes with three parts even with Fieldmapper
> > > stripped from the front, and I tend to thing of the name as
> > > descriptive as a whole as opposed to <stuff>.<specific_object>.
> > >
> > > In other words, I agree with the premise of removing any
> > > implementation specifics from the class id, and that includes DB
> > > semantics.  I would go as far as to say "class identifiers must be
> > > unique", and leave it at that.  Take, for example, org unit addresses.
>
> > > I'd like those to be something like 'actor.org_unit.adress'
> >
> > Absolutely.  We should be at liberty to call the classes what we feel is
> > necessary and let the DB code handle any necessary mapping.  So, is the
> idea
> > to have a class name and a class hint in each class?
> >
>
> If we had a <description> under the <class>, or maybe even just
> @label, we could use the @id on <class> to hold the hint, and just use
> the friendly name as human readable info.  I don't think we should put
> any more tags under <class> unless we bring back <fields> and <links>,
> though.
>
> In fact I'd vote for those to come back anyway.  It makes it much
> easier to address the entire set of fields or links in code that has
> to use this XML.  What was the driver for those going away?


Refresh my memory, are the 'fields' and 'links' attributes simply lists of
field and link IDs that are contained within a given class?




--
Bill Erickson
PINES Systems Developer
Georgia Public Library Service
billserickson at gmail.com
http://open-ils.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20060501/a53fc16d/attachment.html