I guess I have a more simplistic situation than most in that my app is a
single user desktop app - so I have no complications with remote users and
connections, though I understand where you are coming from. In my situation
most reports are either viewed or printed - so displaying the report in a
pdf viewer is adequate as I can view, print or save a file (for attachment
to an email) from there - I'm intending to keep things very simple
initially and possibly develop further as needed. You have a valid point re
user input and the thought had crossed my mind. Again, I have a simplistic
situation - a membership system - where typically I want all records listed
in a report eg all members who haven't paid their annual dues, or all
members with a birthday this month, so I don't typically get much user input
to select in reports.
Having said that, a more general and flexible tool is obviously better
than a simplistic one that only fits one applications situation, and
probably inevitably the requirements will expand over time anyway. It would
seem unproductive to develop essentially the same thing twice. How advanced
is your development and would you be willing to share the fruits of your
labor?
Regards
Roger
--------------------------------------------------
From: "johnf" <[email protected]>
Sent: Wednesday, May 27, 2009 12:20 AM
To: "Dabo Users list" <[email protected]>
Subject: Re: [dabo-users] Report Runtime
> On Monday 25 May 2009 05:33:27 pm Roger Lovelock wrote:
>> Hi All,
>> A thought I had! The most common enhancement to my dabo application
>> is
>> new report formats (changes or additions). Because of the nature of the
>> report writer and the way reports are run it means adding code to the
>> main
>> app and redistributing an updated version to all users. My thought was
>> that
>> if a generalised report runner was included in my app I would only need
>> to
>> distribute text and/or xml files to add new reports. To explain - if I
>> had
>> an xml or text file per report which included the descriptive name of the
>> report, connection name, sql statement and report definition file name
>> then
>> a generalised routine (optionally stand-alone or alternatively embedded
>> in
>> the application) could do the following :- read all report text files
>> display a drop down list of available reports
>> (descriptive
>> name) upon selection of a list item
>> get the connection
>> create a dataset from the sql statement
>> run the specified report and display the pdf
>> To add a new report would just need the relevant report text file, cdxml
>> file and rfxml files loaded in the app directory.
>>
>> Of course two other thoughts come to mind
>> - all the data in the report text file could be included
>> in
>> the rfxml file. - A stand-alone user friendly ad-hoc report generator
>> could
>> be developed from this base utilising the report designer as a starting
>> point.
>>
>> Has anyone else had thoughts or done anything along these lines? Any
>> suggestions?
>>
>> Roger
>
> Larry and I are doing something very similar. Although, your description
> does
> not cover all the issues. For example you need more than just a dropdown
> to
> select a report. You need a way to interact with the user. Most reports
> will need input from the user - such as date ranges or client names. IOW
> the
> params for the sql. BTW that is not as easy as it may sound.
> Dynamically,
> displaying textboxes, date boxes, spinners, dropdowns can be a pain and
> remember that you can have ranges and may need to provide validation along
> with lookups for each control.
>
> That said, are you going to limit the reporting tool to PDF's? Most apps
> these days need to email, create spreadsheets, SMS text?, and of course
> printing.
>
> BTW how would you handle the connection problem for remote users? If the
> connection is within the report then it would be likely that the
> connection
> would be wrong for the remote users.
>
> I'm not shooting down the idea. I like it (or I wouldn't be doing
> something
> similar). But there is much more than what you described required.
>
>
>
> --
> John Fabiani
> _______________________________________________
> Post Messages to: [email protected]
> Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
> Searchable Archives: http://leafe.com/archives/search/dabo-users
> This message:
> http://leafe.com/archives/byMID/[email protected]
>
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message:
http://leafe.com/archives/byMID/[email protected]
