[OPEN-ILS-DEV] IDL- fieldmapper classes
Mike Rylander
mrylander at gmail.com
Sat Apr 22 17:42:12 EDT 2006
On 4/22/06, Bill Erickson <billserickson at gmail.com> wrote:
> How do you guys want to handle the class id's? The current IDL uses the
> Perl class names (Fieldmapper::action::survey). There's also the DB names
> (action.survey) and the class hints (asv).
>
> The IDL will become the "fieldmapper", so I think we can safely drop that.
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... :)
> 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.
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'
>
> 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'
Thoughts?
> Keep 'em coming, Murphy ;)
>
Ditto.
> -bill
>
>
>
> On 4/21/06, S. K. Murphy <error23 at gmail.com> wrote:
> >
> > Part 2.c:
> >
> http://forest.gapines.org/~murphy/IDL/Fieldmapper_links_rt.xml
> has @reltype defined for each link.
> >
> > -Murphy
> >
> >
> > On 4/21/06, S. K. Murphy <error23 at gmail.com> wrote:
> > >
> > > Part 2.b:
> > >
> http://forest.gapines.org/~murphy/IDL/Fieldmapper_links.xml
> has the attribute @id changed to @name for links and fields.
> > >
> > > -Murphy
> > >
> > >
> > >
> > > On 4/21/06, S. K. Murphy <error23 at gmail.com > wrote:
> > > >
> > > > Part 2:
> > > > Fieldmapper into this XML file:
> http://forest.gapines.org/~murphy/IDL/Fieldmapper_links.xml
> > > > The links are now here, but some of the fields are incomplete; they
> just have the placeholder string "unknown".
> > > > If I'm missing links or whatnot, let me know; until then, I'll be
> working on determing reltypes.
> > > >
> > > > -Murphy
> > > >
> > > >
> > > >
> > > >
> > > > On 4/10/06, S. K. Murphy < error23 at gmail.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 4/10/06, S. K. Murphy <error23 at gmail.com> wrote:
> > > > > >
> > > > > > After a long silence, I bring part 1:
> > > > > > Fieldmapper converted into this IDL. None of the 'links' are in
> place yet, and some of the fields don't have complete information; I've
> commented where I don't know what class/type a field should have. If anyone
> gets a chance to answer some of those, that'd be great, and I'll have the
> links section up soon.
> > > > > >
> > > > > >
> > > > > >
> http://forest.gapines.org/~murphy/IDL/Fieldmapper_nolinks.xml
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Murphy
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > "But can you imagine if we all start demanding?"
> > > >
> > > >
> > > >
> > > > --
> > > > "But can you imagine if we all start demanding?"
> > >
> > >
> > >
> > > --
> > > "But can you imagine if we all start demanding?"
> >
> >
> >
> > --
> > "But can you imagine if we all start demanding?"
>
>
>
> --
> Bill Erickson
> PINES Systems Developer
> Georgia Public Library Service
> billserickson at gmail.com
> http://open-ils.org
--
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org
More information about the Open-ils-dev
mailing list