Re: Reporting

[Murray Cumming <murrayc murrayc com>]

On Mon, 2005-04-18 at 17:58 -0500, Greg Breland wrote:
> Suprised to see a post on your Blog about reporting in Glom but not the
> mailing list.  I assume this is the correct place to talk about this
> topic?

Sure, I just don't think there's many people on this mailing list yet.
For the archive, here's the URL:
http://www.murrayc.com/blog/tech/2005-04-18-17-30.html

> First, I agree that Glom needs a way to create/run reports.  It would be
> ideal if this solution had a GUI that non developers could use to
> create/modify reports.

I'm not personally very concerned with that. For most cases I think it's
OK if the database developer creates the reports that the user needs,
and then the user can just choose from the list of reports.

But if it's easy enough then we can let the user do their own custom
reports without changing the set of official reports. It would use the
same code.

>   It would also be nice for it to have at least
> some knowledge of the database structure to make building the report
> query easier.

Of course.

> However, I think reporting is out of scope for Glom outside of
> integrating with a 3rd party product. Its also true there are no good
> options for 3rd party reporting. That said, this is just my opinion and
> the person submitting code decides whats in scope.  

I disagree. The reports described on my blog should be simple enough.
FileMaker has this functionality too.

> I guess I've used a lot of packages over the years that decided, for
> various reasons, that they needed an integrated report writer. They do
> it because there was no good 3rd party tool available(Mr Project) or
> they wanted very tight integration(MS Access).

We should have reporting because
- there's no good-enough alternative.
- there's unlikely to be a good-enough alternative that isn't
integrated.
- it's what people want.

The data (though not the table and field titles, and not the
relationships) is on the server, so people can use a 3rd party system if
they want. That's an advantage.

>   I have yet to see an
> implementation that worked out well.  Some examples are:
>
> Mr Project
> Goldmine
> SalesLogix
> MS Access

I don't know GoldMine or SalesLogix, but the others clearly have a
different scope.

> I would advocate creation of a separate project to make sure things
> don't start overly mingling.

I'm happy for it to be started separately, but I'd expect to integrate
it later. However, I think you'll want to use the structure information
and the display functions from Glom from the start.

>   I would be willing to help out with a
> reporting project that is fully application independent.

Bear in mind that a generic tool would have a bigger scope and would
therefore be more difficult to implement and difficult to use.

>   I'm in the
> same boat as Glom in that I know I'll need a reporting system at some
> point and there are no viable candidates.  The real question is how much
> integration do you require for Glom?
>
> My project doesn't need much integration at all.  The only requirement I
> would have is that the output be 100% cross platform.  I wouldn't
> include Cairo in that definition.  Output would have to be something
> like HMTL, PDF, PS or maybe even SVG.  I'm flexible with the GUI
> designer interface.

I'm happy to use HTML for the foreseeable future.

> A reporting system is a huge project.

Not for Glom. It's very difficult to do some big "enterprise" thing that
can theoretically do everything anybody would need, but which nobody
understands. But by ignoring a few niche things, Glom can be much
simpler and easier.

Projects have to start somewhere, and I think my description on my Blog
would be a perfectly good start.

>   Its probably bigger than both my
> project and Glom put together.  I would expect we would focus on getting
> a very basic framework working and since its a separate project let
> others improve it as needed and we all reap the benefits.

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com