Posted by
Jacopo Cappellato on
URL: http://ofbiz.116.s1.nabble.com/jira-Created-OFBIZ-322-Form-widget-header-link-for-sorting-doesn-t-render-if-fields-have-use-whens-tp172593p172596.html
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
>