Comment 15 for bug 1749475

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

Thanks for looking at the branch, Dan.

So, first, WRT the simplicity of the initial use of Event Definition Groups (Groups), specifically that I implemented the brief and full "formats" using one definition for each delivery mechanism. I did it that way because the output is essentially the same with some information omitted in the Brief case. It seemed there was little benefit in duplicating the definitions and then forcing admins to edit two, rather than one, to make local adjustments. It also shows how a definition could be leveraged for more than one "format" if they are basically the same.

Regarding the existential question of "why Groups", that is to support (actually) different formats -- for instance, different bibliography standards -- as options for rendering the data. Without some way of saying "here are a set of definitions that can all be seen as alternative formats for a specific purpose" then we'd have to embed all the different formats (various bibliography formats, the extant brief and full, others yet to be thought of) in one definition. With groups in place, new definitions can be created and added to the "pinned" Groups 1 and/or 2 at will by admins. That was a specific, intentional goal of the development because including the development of several bibliography formats in the initial project would have pushed the cost beyond what could be supported in this first work. By intentionally providing the infrastructure that fully supports dropping in new formats to the initial two groups with just a new event definition and group mapping, we are able to move the ball forward and set the stage for more contributions /immediately/ rather than having to rewrite what's there now (or, massively over-complicate the event definitions in question).

More broadly, the Group IDs are in a reserved ID space so that we can depend on a stable hook for "here's how you can format data for email" or "here's how, for print", but other groups can be imagined ("send via NCIP for remote update, with choices for common NCIP applications", etc) for the reserved ID space, and local-use groups could provide integration points for special-purpose (perhaps locally-developed) external "things".

I hope that helps explain why the Groups infrastructure exists...

Thanks again!