Jacopo,
Sorry it took about a month to reply...
I've been thinking about this for a while and I think the cleanest
solution is to take advantage of the combination of the screen widget
and the form widget. Many reporting tools just have one thing, a
"report", so they have to use that for both the information output
mechanism, and the container for other reports. These are fairly
different things and it's kind of nice to have different tools for them.
The Screen Widget is a great container mechanism, given that is
exactly what it is designed for: containing and combining
presentation artifacts with the data preparation and conditional
elements to control them. The Form Widget can fit in a screen
definition quite well, and multiple forms can fit in just as well.
Templates can be used, like the current FO wrapper template and such,
to lay out the different forms in any way desired, or they can be
included one after another for a simple inline list.
-David
On Nov 25, 2006, at 2:56 AM, Jacopo Cappellato wrote:
Before going on with this changes we should carefully discuss about
the design decisions because I really think it's time to add a few
more features to the list based form widgets.
As you probably know, form widget definitions, if used inside
screenfop screen, are rendered as xsl-fo (and then pdf) templates.
This, in my opinion, makes the widgets a great tool for simple
(list based) reports (both html and pdf).
There is one feature that is missing and I'd love to see
implemented: addin the ability, in list-based form definitions, to
define special rows for totals/subtotals and for row group breaks.
For example:
let's say we have a list like this:
orderId | orderItemSeqId | amount
---------------------------------
WS10000 | 0001 | 55.00
WS10000 | 0002 | 45.00
WS10001 | 0001 | 10.00
WS10001 | 0002 | 20.00
it would be great to have a way to render it in this way:
orderItemSeqId | amount
---------------------------------
orderId: WS10000
0001 | 55.00
0002 | 45.00
total for order: 100.00
-----------------------
orderId: WS10001
0001 | 10.00
0002 | 20.00
total for order: 30.00
-----------------------
grand total: 130.00
We could implement something like this with the concept of a <row>
element; each form could have more than one <row> elements, each
one with its own fields and with a condition that triggers it.
In the above example, we have defined four different row types:
1) one for the orderId that is triggered at the orderId change
2) one for the order items
3) one for the order subtotal triggered at the orderId change
4) one for the grand total triggered by the end of the list
Is this a good idea?
Jacopo
David E Jones wrote:
This sort of thing should be discussed on the mailing list because
discussion in an issue is not threaded, so you can't respond to a
particular comment.
There are a couple of problems I see with this approach:
1. it's a pretty big change (which on its own isn't a problem...)
2. there are often more than two options, and not just a true/
false; for a single condition yes of course being a boolean it is
always true or false, but it is common to need to decide among
fields to use with different conditions, ie a combination of
multiple factors and not just a single == or != as is implied by
this structure
-David
