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: Mon, 22 Apr 2002 23:12:58 -0700

> I have the small possibility that I will be implementing a project for a
> greenhouse nursery to coordinate inventory management, accounting and
> customer management (ERP? I'm not too familiar with industry jargon). I
> considered (and am considering) the possibility of using PostgreSQL
> (database) / omniORB (application server) / GTK+ 2.0 (GUI) using
> Python/C primarily. This is all dependent on if I am given the go-ahead.

You might want to consider just using the GNU Enterprise Framework.  It will 
make your life much easier. :)

> However, since we're currently locked in proprietary NT/2000 solution
> printing will be the most serious obstacle. I plan to get around this by
> creating all reports as PDFs since they are good quality, its useful for
> them to be saved as files anyway and I can then use Adobe Acrobat Reader
> to do the printing. In the meantime I've come across GNUe and I like the
> direction its heading. Perhaps the biggest concern my employers have is
> the maintainability of the software when I leave - they really want the
> security of having a support channel. My latest thought is to suggest
> making the software open source (perhaps utilizing GNUe) so that the
> software can have a longevity that outlasts me.

I would use GNUe (but Im biased), mainly because the core tools will be 
supported as other people are using them right now today.  If you wanted to 
release your applications under a GPL compatiable licensee that would surely be 
doable and you could help ensure perhaps others would adopt them giving them 
even more comfort.  I can also give you a list of software houses that 
currently either employ GNUe developers or do GNUe consulting.  This is one of 
the powers of somethign like GNUe.

Example: SAP is a framework.  Company A might use SAP differently than Company 
B.  However, if company B needs a consultant they go to SAP and get a 
consultant or hire someone that knows SAP (not necessarily their exact 
implementation) and be ok.  Think of GNUe in a similar way.  Onlly instead of 
one vendor to choose from think of it as several.  Plus they will have ALL the 
source so they can never be damaged by no support. 

> While none of these decisions are final (and may not be decided for some
> months yet since other projects are on the go as well) I thought it
> might be helpful for you to hear that GNUe is a consideration. The
> biggest downside currently is that not all of the base tools are ready
> to give a convincing proof of the viability of this particular open
> source solution.

While this is true, there are few people using GNUe in production.  I can 
gladly give you their contact information so you can hear their experience and 
if you like perhaps set up a VNC demo session of how they have things setup and 
working.

> - I have had to make several different reports where information is
> summarized by one field, seperated into particular groups and then
> displayed in columns to the right of the field. More generally, this
> would be a horizontal grouping which sometimes (often) needs to
> automatically attach to the correct column.
> 
> ie.           Jan     Feb     Mar     
> Customer      $1      $2      $1.5
> 
> While this can be similar to an Excel pivottable it can also be
> something like this:
> 
>               Value_A         Value_B         Value_C
> Customer 1    x               x
> Customer 2                    x               x
> 
> Where Value_A is actually all possible values of another field displayed
> in full as column headings. This is a one (customer) to many
> relationship expanded and showing some value summarized from the 'many'
> table.

Cross tab reporting is do able and will be supported at some point. :)

> - The ordering of items on a report is frequently requested to be
> tweaked and rarely in the same order. ie. "alphabetical but show this
> one first". Some quick method such as entering in a known column value
> with a placement marker would be very useful. Without this it is often
> necessary to create an Excel report so that the values can be resorted,
> redisplayed, etc...

We support triggers and complex queries etc in reports (or will) that will 
allow you do about anything for this sort of thing.

> - As briefly discussed on this list in March, the ability to preserve
> formulas when outputting to Gnumeric/Excel would be very nice. This is
> probably most critical for subtotals since they are frequently used with
> autofilter to provide a basic tool to explore the data with details. In
> fact Excel is often used to provide analysis reports which can be played
> with, graphed, etc... If raw data is imported into Excel w/o formulas
> frequently it is necessary to create a macro to format the raw data and
> add in formulas, etc. since everytime the report is run the same
> formulas are needed... In short, reports with formulas are used all of
> the time.

We have discussed this and think we have an acceptable way to approach this and 
this will be one way we kick some tail over other reporting tools!

> - Absolute and relative positioning should both be allowed. They can
> easily coexist and each serves a useful purpose. I'd like to see the
> report defined in layers and have different types of layers. Some would
> be fixed position (ie. headers, footers, watermarks, ...) which could be
> repeated on certain pages (ie. all/odd/even), others free flowing from
> the point where they begin until the data runs out, ...
> --- Of the top of my head I can't see why the sample report displayed on
> GNUe now, or a pre-printed form or labels couldn't all be done with the
> same tool...fixed text for a dotmatrix might be a little more tricky to
> fit into this model.

We plan to support both, I wont go into great details here, but the engine is 
highly flexible.

> - I have a few more ideas that might make what I'm saying more concrete
> but I don't have time to type them up right now.

We love ideas, just be careful or you are liable to get put to work. :)

> - Any layer could be reusable. Not every layer would have a dynamic data
> source.

Not sure I understand this one.

> - Many reports seem to lack one small detail which necessitates
> recreating the entire thing in a more accessible and manipulatable form.
> Some ability for filtering the report before it is output would be
> useful (ie. via python)

We have several ways to do this (re queries and triggers in reports)

> Sorry for the mess. I wanted to get this sent out today and as a result
> you find this a little incoherent. My apologies.

Seems coherent to me, but hey Im a heavy crack smoker. ;)

-Derek



reply via email to

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