Evergreen

split IDL into per-class files

Bug #1656331 reported by Galen Charlton
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
New
Wishlist
Unassigned

Bug Description

For managing local customizations to the IDL, it would be convenient to split the monolithic fm_IDL.xml into a file per class. We propose an approach like this:

- break up the IDL into an XML snippet for each class, under Open_ILS/examples/fm_IDL.d/
- during installation, copy the snippets over to $SYSCONFDIR/fm_IDL.d
- add a script that gets invoked during installation (and which can be re-run at will and as part of autogen.sh) that scans through everything in $SYSCONFDIR/idl.d and reconstitutes $SYSCONFDIR/fm_IDL.xml

Some points in favor of this:

* for anybody who does particularly extensive tweaking, having a bunch of small files rather than a single big one would ease dealing with merge conflicts
* adding a new class (e.g., for an IDL reporting source) would just be a matter of tossing a new file into fm_IDL.d and doing an autogen and service restart
* it won't be necessary to update clients that expect a monolithic fm_IDL.xml

Evergreen master

Revision history for this message
Bill Erickson (berick) wrote :

+1.

I'm curious about the naming convention for the snippet files. fm_IDL.d/aou.xml? Or something more verbose?

The IDL-compiler script will need to be functional from within the repo without any assumptions about files getting installed. IIUC, the i18n code and certainly the Angular/Karma unit test data collector (staff/test/data/idl2js.pl) require access to a compiled IDL regardless of whether Evergreen is locally installed. Maybe that just means running the compiler during 'make' (at least before 'make install') or teaching these scripts to invoke the compiler themselves.

Not to muddy the waters, but while we're in there, should we move the IDL data from 'examples' and into a new 'src' directory (src/IDL/* or similar)? Low priority, obviously.

Revision history for this message
Thomas Berezansky (tsbere) wrote :

Just as a reference point so it isn't forgotten: i18n expects the monolithic fm_IDL.xml right now, and I believe that process happens long before the proposed script to re-make it would run. As such it would likely need to be adjusted to look at the fm_IDL.d directory as well. The fact that it then makes a translatable reporter monolithic fm_IDL.xml makes things a bit harder and needs to be taken into account.

Revision history for this message
Mike Rylander (mrylander) wrote :

Bill, I think naming them after the class id as you suggest would be best, actually. First, it reinforces class id uniqueness, and second, it makes it easier for local git repos maintain tweaks to core classes.

Just to spitball about implementation ... Since we have TemplateToolkit as a dep, we could leverage the ttree tool to compile the monolith at will.

Seems i18n will need to learn to deal with (and add DTD includes to) each class file. That shouldn't be hard -- we do directories of files in the template area, no? We could just generate the &entity; files for the i18n-ized version, and when compiling the various monoliths, specify either the static directory or the &entity;-ized one, /and/ a customization directory. Caveat developer, re adding customizations with existing class names, of course, but that's the case today, too. The compiler could easily warn on errors of that kind.

Tiffany Little (tslittle)
tags: added: needsdiscussion
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.