gnue-dev
[Top][All Lists]
Advanced

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

Re: [Gnue-dev] GNUe Reports


From: Derek Neighbors
Subject: Re: [Gnue-dev] GNUe Reports
Date: Wed, 1 May 2002 23:33:31 -0700

> I'd like to. Decision will not be made for some time yet but I will
> suggest it. Derek, I would appreciate it if you could give me a list
> of people using GNUe in production but I have a feeling I may know the
> answer to some of these situations already. For instance is it correct

I will give you this offlist as not all entities publicly are willing to admit 
to using free software.  Kind of silly huh.

> to say the designer/forms work for direct access to database as of
> right now but geas (application server for business logic) is being
> rewritten and reports are being actively developed? For the project
This is correct.

> I'm working on I need GEAS to be functionally and reliabily connecting
> to PostgreSQL and forms. Additionally, forms may be too limiting from
GEAS development has been moving forward nicely over past few days.

> what I've seen(but I would have to take a closer look before I would
> decide). If I could get permission to go this route, I might be able
> help work on GNUe framework first...Time will tell.
If you let us know where forms is too limiting we might be able to help.

> Is this situation a standard feature of cross tab reporting? I never
> realized it.
Just matter of bastardizing queries to get there.

> > > - Any layer could be reusable. Not every layer would have a
> > > dynamic data source.
> > 
> > Not sure I understand this one.
> 
> I was thinking in terms of having layers of definitions in a report.
> Nothing distinct about any layer but they can ordered. An example:
> - first layer could contain something like headers and footers
> (reusable in multiple reports)
> - the second layer could hold the report data itself
> - a third layer could have a pull-quote style summary of some portion
> of the data
> --- however, all of this seems well-handled by XSL/XSLT...
Yes.  We plan to support leveling in this fashion.

> I haven't seen FOP (http://xml.apache.org/fop) mentioned in the
> archives. It may be worth a look if you haven't heard of it.
> Obviously, however, since it is part of Apache, its in Java. The
> XSL/XSLT recommendations look quite powerful. Are they under
> consideration?
Best I can tell this takes FO (formatted objects) and transforms it.  We plan 
to support FO.  Our model allows for pluggable components so you could even use 
FOP from apache if you so like to go from our FO to PDF.  I imagine if an 
FO->ps,pdf,etc isnt ready for python by the time we get there, that we will 
either use a java one until a python one becomes ready or consider converting a 
java one to python. :)

-Derek



reply via email to

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