[OPEN-ILS-DEV] IDL- fieldmapper classes

[Mike Rylander]

On 4/24/06, Bill Erickson <billserickson at gmail.com> wrote:
> >
> > 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...

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.

>
> > > 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?

> > >
> > > 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.
>

cool ... any other thoughts?  Murphy, that making sense to you?

--
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org