[OPEN-ILS-DEV] IDL- fieldmapper classes

[Mike Rylander]

On 4/22/06, Mike Rylander <mrylander at gmail.com> wrote:
> 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.
>
> I think we can do away with @class on <field>, as that should be
> covered by <link>.  Also, for fields that are used to contain a
> has_many link (the 'questions' field on 'survey'), a type of 'array'
> makes sense.  Another option is to remove <field>s that have <link>s
> altogether.  The <link> gives us enough information to construct a
> class member with all the logic needed to fill in the object that
> lives there.

I've reconsidered the idea of removing <field>s that have <link>s
after creating a script to generate the IDL from the current
fieldmapper and Class::DBI code (more on that in another message).  It
looks like it's best to keep all of the <field> and <link> elements,
as some <link>s don't actually have <field>s (or, more specifically,
array positions in Fieldmapper) at the moment.

I have, however, moved the @class attribute to the link, since I don't
think we plan to support non-primitive datatypes in unfleshed
<field>s.  If we do end up doing that, it would be best to use the
<link> mechanism with non-persistant object classes describing the
complex object, as that should give all the information required for
manipulating the object to the app, and avoids language specific black
boxes (think: DateTime objects in Perl vs. a date-time OpenSRF class
that is implemented via DateTime for Perl and the Date object for JS).

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