reportspecs

[Wessel Dankers]

On 2003-07-05 17:46:42-0400, Francis J. Lacoste wrote:
> On jeu, 2003-06-26 at 05:31, Wessel Dankers wrote:
> > I was tracking down how Lire loads reportspecs and I noticed that our
> > devious scheme isn't going to work—it needs the path configuration to load
> > the reportspecs but it needs the reportspecs to load the configuration.
> 
> Well, this isn't necessarly so. I mean, it would be possible to separate
> the configuration file parsing from the validation stage. 

That would mean we'd use certain variables before the validation has taken
place. Not pretty, but doable.

> Also, the report' configuration object should be stored in a different
> section than 'global'. (Iirc, we discussed using 'reports'). Which means
> that the report validation could be done once the 'global' section is
> validated (and thus the variables needed to find the report specs are
> available).

I'd hate to introduce special handling for this. That is to say, an extra
section like <reports> is okay, as long as it isn't any different from the
<global> and <job> sections. That's also how I implemented it now. But I
want to keep the underlying system based on a central, simple principle.
This prevents baroqueness in the long term future.

> > But then I thought, why would we insist on including this information in
> > the reportspec files anyway? Looking at it abstractly, the reportspecs are
> > like little programs in a declarative language. 
> > Why should these little
> > programs be special in comparison to the rest of Lire in that they get to
> > keep their own configuration information? I say, let them get in line and
> > surrender their params! :)
> 
> I'm not sure I'm understanding what you want to do here. Are you
> suggesting that report specifications shouldn't have parameters? 

Of course they can have parameters. They should just be declared in the
config-spec file and not with the actual "code". Other parts of Lire use
parameters too and they too declare them seperately. I see no reason why
these report-specs are any different from say, ChartWriter.pm.

> If you suggest that, the configurability of the report specification
> should be in a separate file configuration XML specification, I really
> do not agree. The whole idea of the report specification is to have all
> that is related to the report in the same file: report generating
> instructions, documentation, parameters, etc. 

I understand that. It would be nice to avoid splitting (see below).

> On the other hand,  we could develop a lr_install tool which would be
> required to install/register new report specification with the system.
> That tool could generate the XML configuration specification from the
> report specification. This would also remove the burden of remembering
> the directory layout (reports/superservice/) on the user. The tool could
> also make sure that the report is valid (and thus prevent later errors).
> In fact, such a registration tool might provide a lot of useful hooks.

It sounds like a reasonable option, although the prospect of having various
files that could potentially get out of sync doesn't sound too exciting.

> Another enhancements would be to use the Lire Configuration
> Specification Language in place of the custom <param> elements in the
> report specification language. Thus, report specifications would use
> elements from two namespaces (LRSML and LCSML).

There is an additional complication: the config file currently determines
where to look for reportspecs. If we'd use an lr_install and we would need
configspec files to be generated from reportspecs, there's not much point
in having the reportspec path as a variable anymore. Personally I feel that
the variable can go but you may not agree. When those paths are static
there's nothing against just parsing reportspecs to pick out the
interesting configspec nuggets. Good use of XML namespaces too.

Regards,

-- 
Wessel Dankers <wsl at logreport.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.logreport.org/pipermail/development/attachments/20030706/082f8573/attachment.bin