Re: [Trinidad] Detailstamp facet problem

[Henk Vanhoe]

When you have a big screen with many detail-regions, I think that it is 
more natural for a user to fill out each region one at a time and to be 
able to fold/unfold each region without triggering validation. Only when 
you're ready filling in each field of this page and when you submit the 
entire page, you want to have your entries validated.

When validation is dependent on other fields in the page, the problem 
can become more serious. F.i. it is possible that there are several 
records in a page with in each record a numerical value, that the sum of 
the values in each record is validated and that the sum must have a 
minimum value. With immediate="false" it is impossible to fold these 
records as long as this minimum value is not reached.

Henk

Adam Winer wrote:
A major concern is:
- Required field is present in the detail
- User collapses with the required field blank
- Submit, and we show an error that the required
 field is empty - but the user can't see the field that
 has the error!

What's the concern with leaving immediate="false"
on the table?

-- Adam


On 6/27/07, Henk Vanhoe <[EMAIL PROTECTED]> wrote:
Now it works without problems, thank you!

I already feared that the original behavior is the expected behaviour.
However, I still think that it would be handy to have a detail
functionality where it is possible to fold/unfold the detail without
triggering validation and still being able to save the content of the
closed detail. But maybe it is possible to implement it myself in
javascript, if we really need to have this functionality...

Henk

Adam Winer wrote:
> BTW, to be clear:  the original behavior, where contents
> are not submitted with the "details" are closed, is
> currently "not a bug" - set immediate to false (the default).
>
> What I fixed was the issue where the contents were
> showing up blank, which was a bug that would
> affect any use of nested tr:tables.
>
> -- Adam
>
>
>
> On 6/25/07, Adam Winer <[EMAIL PROTECTED]> wrote:
>> OK, the detailStamp bug is fixed.
>>
>>
>> -- Adam
>>
>>
>> On 6/25/07, Adam Winer <[EMAIL PROTECTED]> wrote:
>> > I've filed the detailStamp bug as:
>> >
>> > http://issues.apache.org/jira/browse/TRINIDAD-75
>> >
>> > It repros in the Trinidad demo bundle too.
>> >
>> > -- Adam
>> >
>> >
>> > On 6/25/07, Adam Winer <[EMAIL PROTECTED]> wrote:
>> > > On 6/22/07, Henk Vanhoe <[EMAIL PROTECTED]> wrote:
>> > > > Finally, I have found some time to make a testproject where 
this
>> problem
>> > > > (bug?) can be duplicated...
>> > > >
>> > > > There is a jsp in this project
>> > > > (/detailstamptest/faces/table/changeTable.jspx) which
>> consists of a
>> > > > table with one element. Next to this element there is a 'Show
>> detail'
>> > > > link. When you click on this link you see a new table with two
>> > > > addresses. When you close the detail and reopen it, the
>> detail-table
>> is
>> > > > empty and there are some error-messages in the logs ("Exception
>> while
>> > > > determining read-only state of value-binding").
>> > > >
>> > > > This problem can be solved by changing the
>> > > > org.apache.myfaces.trinidad.CLIENT_STATE_METHOD param
>> in web.xml from
>> > > > "all" to "token".
>> > >
>> > > I can reproduce this.  It's strange - I assume it's a 
serialization
>> > > issue somewhere in the table state saving code, but just a guess.
>> > >
>> > > > However, now there is a new problem... When you open
>> > > > the detail, change one of the street-names, close the detail
>> again and
>> > > > then hit the save-button you can see in the log-messages 
that the
>> > > > changes are not submitted to the server! When you leave the 
detail
>> open
>> > > > and hit the save-button, the changes are submitted...
>> > >
>> > > The tables have immediate="true" on them, which means that the
>> > > values aren't pushed to the model when you toggle the table.
>> > > Remove immediate="true".
>> > >
>> > > -- Adam
>> > >
>> >
>>
>>
>