OFBiz › OFBiz - Dev

[jira] Created: (OFBIZ-322) Form widget header link (for sorting) doesn't render if fields have use-whens

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Nicolas Malin (Jira)

[jira] Created: (OFBIZ-322) Form widget header link (for sorting) doesn't render if fields have use-whens

Form widget header link (for sorting) doesn't render if fields have use-whens
-----------------------------------------------------------------------------

Key: OFBIZ-322
URL: http://issues.apache.org/jira/browse/OFBIZ-322
Project: OFBiz (The Open for Business Project)
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Jacques Le Roux
Assigned To: Jacques Le Roux
Priority: Minor
Fix For: SVN trunk

From Leon Torres in http://jira.undersunconsulting.com/browse/OFBIZ-830

Ok this is a tricky bug to describe, so I'll do this by example. Suppose you have a form "ListParties" that you re-use all over and it needs two behaviors for the "partyId" field:

1. Normal behavior: Show the partyId as a hyperlink to the viewParty page.
2. LookupParty behavior: In a LookupParty popup that uses ListParties, have the partyId hyperlink do a javascript:set_value(partyId) instead.

This is a common scenario, where one has to re-use a field for different purposes. The form widget supports this with the use-when attribute. One way to set it up is to use the same field name="" and give them both use-whens as follows,

<field name="partyId" header-link="sortLink" use-when="isLookup==false">
<hyperlink description="${partyId}" target="viewPartyLink?partyId=${partyId}"/>
</field>

<field name="partyId" use-when="isLookup==true">
<hyperlink also-hidden="false" target-type="plain" description="${partyId}"
target="javascript:set_value('${partyId}')"/>
</field>

So in a lookup form, only the second one will be used.

The bug is that the header-link="sortLink" will not work. The sort link is not rendered in the header, preventing the user from sorting by partyId.

However, if you swap the order of the field elements such that the header-link one is second, it will work.

I traced this bug to ModelForm.java renderHeaderRow() where it decides how to render the header-link. The current code marked "Modification Nicolas" is not doing the right thing. It should be evaluating the use-when and comparing it to any other one before deciding to continue.

For now the workaround is to make sure the header-link element comes after the other one.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-322) Form widget header link (for sorting) doesn't render if fields have use-whens

[ http://issues.apache.org/jira/browse/OFBIZ-322?page=comments#action_12449299 ]

Jacques Le Roux commented on OFBIZ-322:
---------------------------------------

Hi Leon,

Hi asked Nicolas (Malin) and here is his answer.
You should use defintions below for fields, else every attribute (but use-when) should be compared to be equals between 2 fields

<field name="partyId" header-link="sortLink" use-when="isLookup==false">
<hyperlink description="${partyId}" target="viewPartyLink?partyId=${partyId}"/>
</field>

<field name="partyIdLink" entry-name="partyId" use-when="isLookup==true">
<hyperlink also-hidden="false" target-type="plain" description="${partyId}"
target="javascript:set_value('${partyId}')"/>
</field

Do you agree ?

Thanks to both of you.

> Form widget header link (for sorting) doesn't render if fields have use-whens
> -----------------------------------------------------------------------------
>
> Key: OFBIZ-322
> URL: http://issues.apache.org/jira/browse/OFBIZ-322
> Project: OFBiz (The Open for Business Project)
> Issue Type: Bug
> Components: framework
> Affects Versions: SVN trunk
> Reporter: Jacques Le Roux
> Assigned To: Jacques Le Roux
> Priority: Minor
> Fix For: SVN trunk
>
>
> From Leon Torres in http://jira.undersunconsulting.com/browse/OFBIZ-830
> Ok this is a tricky bug to describe, so I'll do this by example. Suppose you have a form "ListParties" that you re-use all over and it needs two behaviors for the "partyId" field:
> 1. Normal behavior: Show the partyId as a hyperlink to the viewParty page.
> 2. LookupParty behavior: In a LookupParty popup that uses ListParties, have the partyId hyperlink do a javascript:set_value(partyId) instead.
> This is a common scenario, where one has to re-use a field for different purposes. The form widget supports this with the use-when attribute. One way to set it up is to use the same field name="" and give them both use-whens as follows,
> <field name="partyId" header-link="sortLink" use-when="isLookup==false">
> <hyperlink description="${partyId}" target="viewPartyLink?partyId=${partyId}"/>
> </field>
> <field name="partyId" use-when="isLookup==true">
> <hyperlink also-hidden="false" target-type="plain" description="${partyId}"
> target="javascript:set_value('${partyId}')"/>
> </field>
> So in a lookup form, only the second one will be used.
> The bug is that the header-link="sortLink" will not work. The sort link is not rendered in the header, preventing the user from sorting by partyId.
> However, if you swap the order of the field elements such that the header-link one is second, it will work.
> I traced this bug to ModelForm.java renderHeaderRow() where it decides how to render the header-link. The current code marked "Modification Nicolas" is not doing the right thing. It should be evaluating the use-when and comparing it to any other one before deciding to continue.
> For now the workaround is to make sure the header-link element comes after the other one.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-322) Form widget header link (for sorting) doesn't render if fields have use-whens

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-322?page=comments#action_12451937 ]

Jacques Le Roux commented on OFBIZ-322:
---------------------------------------

Hi Leon,

Did you receive this message ?

Thanks

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-322) Form widget header link (for sorting) doesn't render if fields have use-whens

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-322?page=comments#action_12451957 ]

Hederer Jean-Sébastien commented on OFBIZ-322:
----------------------------------------------

This type of need could be better implemented (perhaps) with sonething like:

<use-when condition="isLookup==false">
<true>
<field name="partyId" header-link="sortLink">
<hyperlink description="${partyId}" target="viewPartyLink?partyId=${partyId}"/>
</field>
</true>
<false>
<field name="partyId" use-when="isLookup==true">
<hyperlink also-hidden="false" target-type="plain" description="${partyId}"
target="javascript:set_value('${partyId}')"/>
</field>
</false>
</use-when>

It would be easier to read and maintain.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-322) Form widget header link (for sorting) doesn't render if fields have use-whens

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-322?page=comments#action_12451959 ]

Hederer Jean-Sébastien commented on OFBIZ-322:
----------------------------------------------

without the:
use-when="isLookup==true"

but everyone understood the spirit of the proposal (? I hope).

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-322) Form widget header link (for sorting) doesn't render if fields have use-whens

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-322?page=comments#action_12451994 ]

Jacques Le Roux commented on OFBIZ-322:
---------------------------------------

Yes this seems good, did you try it Jean-Sébastien ?

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-322) Form widget header link (for sorting) doesn't render if fields have use-whens

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-322?page=comments#action_12452009 ]

Chris Howe commented on OFBIZ-322:
----------------------------------

If you're looking to change the use-when function, it should probably mimic the if, if-exists, ect of the simple-method for continuity/simplicity.

David E Jones-2

Re: [jira] Commented: (OFBIZ-322) Form widget header link (for sorting) doesn't render if fields have use-whens

In reply to this post by Nicolas Malin (Jira)

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

On Nov 22, 2006, at 8:10 AM, Hederer Jean-Sébastien (JIRA) wrote:

> [ http://issues.apache.org/jira/browse/OFBIZ-322?
> page=comments#action_12451957 ]
>
> Hederer Jean-Sébastien commented on OFBIZ-322:
> ----------------------------------------------
>
> This type of need could be better implemented (perhaps) with
> sonething like:
>
> <use-when condition="isLookup==false">
> <true>
> <field name="partyId" header-link="sortLink">
> <hyperlink description="${partyId}"
> target="viewPartyLink?partyId=${partyId}"/>
> </field>
> </true>
> <false>
> <field name="partyId" use-when="isLookup==true">
> <hyperlink also-hidden="false" target-type="plain"
> description="${partyId}"
> target="javascript:set_value('${partyId}')"/>
> </field>
> </false>
> </use-when>
>
> It would be easier to read and maintain.
>
>> Form widget header link (for sorting) doesn't render if fields
>> have use-whens
>> ---------------------------------------------------------------------
>> --------
>>
>> Key: OFBIZ-322
>> URL: http://issues.apache.org/jira/browse/OFBIZ-322
>> Project: OFBiz (The Open for Business Project)
>> Issue Type: Bug
>> Components: framework
>> Affects Versions: SVN trunk
>> Reporter: Jacques Le Roux
>> Assigned To: Jacques Le Roux
>> Priority: Minor
>> Fix For: SVN trunk
>>
>>
>> From Leon Torres in http://jira.undersunconsulting.com/browse/
>> OFBIZ-830
>> Ok this is a tricky bug to describe, so I'll do this by example.
>> Suppose you have a form "ListParties" that you re-use all over and
>> it needs two behaviors for the "partyId" field:
>> 1. Normal behavior: Show the partyId as a hyperlink to the
>> viewParty page.
>> 2. LookupParty behavior: In a LookupParty popup that uses
>> ListParties, have the partyId hyperlink do a javascript:set_value
>> (partyId) instead.
>> This is a common scenario, where one has to re-use a field for
>> different purposes. The form widget supports this with the use-
>> when attribute. One way to set it up is to use the same field
>> name="" and give them both use-whens as follows,
>> <field name="partyId" header-link="sortLink" use-
>> when="isLookup==false">
>> <hyperlink description="${partyId}" target="viewPartyLink?
>> partyId=${partyId}"/>
>> </field>
>> <field name="partyId" use-when="isLookup==true">
>> <hyperlink also-hidden="false" target-type="plain" description="$
>> {partyId}"
>> target="javascript:set_value('${partyId}')"/>
>> </field>
>> So in a lookup form, only the second one will be used.
>> The bug is that the header-link="sortLink" will not work. The sort
>> link is not rendered in the header, preventing the user from
>> sorting by partyId.
>> However, if you swap the order of the field elements such that the
>> header-link one is second, it will work.
>> I traced this bug to ModelForm.java renderHeaderRow() where it
>> decides how to render the header-link. The current code marked
>> "Modification Nicolas" is not doing the right thing. It should be
>> evaluating the use-when and comparing it to any other one before
>> deciding to continue.
>> For now the workaround is to make sure the header-link element
>> comes after the other one.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the
> administrators: http://issues.apache.org/jira/secure/
> Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/
> software/jira
>
>

Jean-Sébastien HEDERER

Re: [jira] Commented: (OFBIZ-322) Form widget header link (for sorting) doesn't render if fields have use-whens

Hop hop hop. In my mind, there was no change of <field use-when="...">
but a new tag.

I saw that there are many times this situation where there are two
fields and one or the other is used on the same condition. A better
solution could be a "<switch condition="..."><case
value="..."></switch>" tag perhaps.

"David E Jones" a écrit le 22/11/2006 21:09 :

>
> 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
>
>
> On Nov 22, 2006, at 8:10 AM, Hederer Jean-Sébastien (JIRA) wrote:
>
>> [
>> http://issues.apache.org/jira/browse/OFBIZ-322?page=comments#action_12451957
>> ]
>>
>> Hederer Jean-Sébastien commented on OFBIZ-322:
>> ----------------------------------------------
>>
>> This type of need could be better implemented (perhaps) with
>> sonething like:
>>
>> <use-when condition="isLookup==false">
>> <true>
>> <field name="partyId" header-link="sortLink">
>> <hyperlink description="${partyId}"
>> target="viewPartyLink?partyId=${partyId}"/>
>> </field>
>> </true>
>> <false>
>> <field name="partyId" use-when="isLookup==true">
>> <hyperlink also-hidden="false" target-type="plain"
>> description="${partyId}"
>> target="javascript:set_value('${partyId}')"/>
>> </field>
>> </false>
>> </use-when>
>>
>> It would be easier to read and maintain.
>>
>>> Form widget header link (for sorting) doesn't render if fields have
>>> use-whens
>>> -----------------------------------------------------------------------------
>>>
>>>
>>> Key: OFBIZ-322
>>> URL: http://issues.apache.org/jira/browse/OFBIZ-322
>>> Project: OFBiz (The Open for Business Project)
>>> Issue Type: Bug
>>> Components: framework
>>> Affects Versions: SVN trunk
>>> Reporter: Jacques Le Roux
>>> Assigned To: Jacques Le Roux
>>> Priority: Minor
>>> Fix For: SVN trunk
>>>
>>>
>>> From Leon Torres in http://jira.undersunconsulting.com/browse/OFBIZ-830
>>> Ok this is a tricky bug to describe, so I'll do this by example.
>>> Suppose you have a form "ListParties" that you re-use all over and
>>> it needs two behaviors for the "partyId" field:
>>> 1. Normal behavior: Show the partyId as a hyperlink to the viewParty
>>> page.
>>> 2. LookupParty behavior: In a LookupParty popup that uses
>>> ListParties, have the partyId hyperlink do a
>>> javascript:set_value(partyId) instead.
>>> This is a common scenario, where one has to re-use a field for
>>> different purposes. The form widget supports this with the use-when
>>> attribute. One way to set it up is to use the same field name="" and
>>> give them both use-whens as follows,
>>> <field name="partyId" header-link="sortLink"
>>> use-when="isLookup==false">
>>> <hyperlink description="${partyId}"
>>> target="viewPartyLink?partyId=${partyId}"/>
>>> </field>
>>> <field name="partyId" use-when="isLookup==true">
>>> <hyperlink also-hidden="false" target-type="plain"
>>> description="${partyId}"
>>> target="javascript:set_value('${partyId}')"/>
>>> </field>
>>> So in a lookup form, only the second one will be used.
>>> The bug is that the header-link="sortLink" will not work. The sort
>>> link is not rendered in the header, preventing the user from sorting
>>> by partyId.
>>> However, if you swap the order of the field elements such that the
>>> header-link one is second, it will work.
>>> I traced this bug to ModelForm.java renderHeaderRow() where it
>>> decides how to render the header-link. The current code marked
>>> "Modification Nicolas" is not doing the right thing. It should be
>>> evaluating the use-when and comparing it to any other one before
>>> deciding to continue.
>>> For now the workaround is to make sure the header-link element comes
>>> after the other one.
>>
>> --This message is automatically generated by JIRA.
>> -
>> If you think it was sent incorrectly contact one of the
>> administrators: http://issues.apache.org/jira/secure/Administrators.jspa
>> -
>> For more information on JIRA, see:
>> http://www.atlassian.com/software/jira
>>
>>
>
>

Jacopo Cappellato

Re: [jira] Commented: (OFBIZ-322) Form widget header link (for sorting) doesn't render if fields have use-whens

In reply to this post by David E Jones-2

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:

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-322) Form widget header link (for sorting) doesn't render if fields have use-whens

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-322?page=comments#action_12455781 ]

Jacques Le Roux commented on OFBIZ-322:
---------------------------------------

Hi Leon, Nicolas, Jean-Sebastien,

Should we close this issue, any thoughts ?

Nicolas Malin (Jira)

[jira] Closed: (OFBIZ-322) Form widget header link (for sorting) doesn't render if fields have use-whens

In reply to this post by Nicolas Malin (Jira)

[ http://issues.apache.org/jira/browse/OFBIZ-322?page=all ]

Jacques Le Roux closed OFBIZ-322.
---------------------------------

Resolution: Later

David E Jones-2

Re: [jira] Commented: (OFBIZ-322) Form widget header link (for sorting) doesn't render if fields have use-whens

In reply to this post by Jacopo Cappellato

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
>
>