gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnue-dev] GNUe Reports Output Markup


From: Jason Cater
Subject: Re: [Gnue-dev] GNUe Reports Output Markup
Date: Tue, 26 Mar 2002 18:21:12 -0600

On Tue, 26 Mar 2002 17:50:40 -0600 (CST)
"Derek Neighbors" <address@hidden> wrote:

> The only bad decisons are those not made right... :)

Hmm... now how do I make right that investment in Yahoo last year? :)

> >    We might, however, provide *hints* (e.g., this report looks
> >    best in a landscape format, etc)
> 
> I see this as something the reports 'client' chooses so is irrelevant to
> the spec.  

I would agree. I only included this aside as I knew it would come up. I do
have some reports that just *will not* work in a portrait format, but
these are the exception and probably shouldn't be addressed in the
definition XML. 

> I would say staroffice/excel/word (in native xml format)  Mind you Im
> not saying MAIL MERGE, but rather actually transform into these formats.
>  I wont elaborate too much but Excel's format is very interesting in
>  this area as its SOOO much better than exporting to csv then opening in
>  excel.

Actually, Excel (or at least OpenOffice's scalc) is a *big* need for me.
CSV is very limited in it's usefulness. I was just apprehensive about
mentioning a non-free file format as a "necessity" :) 

I included RTF because I figured it'd meet most of the "Word Processor"
needs. For the most part, RTF would do everything we need for this class
of output. (Or will it? how well are tables supported in RTF?)

> I tend to agree, the only exception I can think of is in native excel 
> format you can carry expressions as well. which is interesting, but
> thats another conversation and not a necessity.

Hmm... interesting idea.  I'm not sure of the practicality of saving the
formulas, but having them show up in Excel would rock a few socks. That'll
give me something to think about in between pizza slices. It'd probably
introduce too much overhead to be worth the few possible advantages, but
it certainly is worth thinking about.

One think the reporting engine currently supports are Structural Comments.
They are off by default. If enabled, they place XML comments between
elements. For example, all sections are enclosed by 
 <!--[section:mysection]--> ... <!--[/section:mysection]-->
and all field values would be: 
<!--[field:myfieldname]--> field value <!--[/field:myfieldvalue]-->

I included this functionality to debug my reporting engine. But, these
could possibly be used to include "hints". In the case of excel formula
support, the computed value could appear as: 

<!--[formula:'field1/field2*100"]-->Computed Value <!--[/formula]-->

These comments would normally be discarded by the transformation programs,
but, in the Excel case, we might actually put useful, optional
meta-information there. I'm not sure how people would feel about this
approach. 

Note that "hints" weren't my initial intention... these comments were for
were only for debugging :) 

> -Derek

-- Jason



reply via email to

[Prev in Thread] Current Thread [Next in Thread]