[OPEN-ILS-DEV] IDL- fieldmapper classes

[Bill Erickson]

> More, even.  I'm planning (plotting) some prototype code to turn the
> IDL into core OpenSRF classes, a la our original domain object stuff,
> but much better... :)


Excellent.  Did we ever reach a conclusion regarding run-time vs.
pre-compiled class handling with the new IDL?  I suppose pure run-time
(extracting from the in-memory XML doc on each field use) could be way too
slow.  I suppose in Perl, you could go so far as to parse the doc and
autogenerate methods based on the fields at load time...

> 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 ;)

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?

>
> > Any thoughts or preferences?
> >
>
> Right now, there are no XML namespace applied to the document.  I
> think, because of the multiple uses this will see, we should invent
> some.  We (Bill) own(s) opensrf.org, so we can use that as the base,
> and store schemas there for validation as well.  Here are some that I
> think would be useful:
>
> * base <class> definitions, <field> and <link> elements, @reltype,
> @class on <link>, etc
>   - namespace URI : http://opensrf.org/spec/IDL/base/v1
>   - should probably be the default namespace
>   - when not the default namespace, use 'osrf' as the prefix
>
> * persistance information -- the @virtual attribute, @key on <link>,
> @primary on <field> (which I don't see anymore)
>   - this isn't OpenSRF's domain, so ...
>   - namespace URI : http://open-ils.org/spec/opensrf/IDL/persistance/v1
>   - should /not/ be the default namespace
>   - use a prefix of 'oils_perist'


The namespaces sound fine to me.



--
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/20060424/71a97849/attachment.html