Re: [Trinidad] Detailstamp facet problem

[Henk Vanhoe <He...@kava.be>]

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 <He...@kava.be> 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 <aw...@gmail.com> wrote:
>> >> OK, the detailStamp bug is fixed.
>> >>
>> >>
>> >> -- Adam
>> >>
>> >>
>> >> On 6/25/07, Adam Winer <aw...@gmail.com> 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 <aw...@gmail.com> wrote:
>> >> > > On 6/22/07, Henk Vanhoe <He...@kava.be> 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
>> >> > >
>> >> >
>> >>
>> >>
>> >
>>
>>
>

Re: [Trinidad] Detailstamp facet problem

[Adam Winer <aw...@gmail.com>]

On 7/3/07, Henk Vanhoe <He...@kava.be> wrote:
> 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.

... except that then you get validation errors for components
that are hidden.

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

IMO, that type of validation should be form level, not field level.

-- Adam

>
> 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 <He...@kava.be> 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 <aw...@gmail.com> wrote:
> >> >> OK, the detailStamp bug is fixed.
> >> >>
> >> >>
> >> >> -- Adam
> >> >>
> >> >>
> >> >> On 6/25/07, Adam Winer <aw...@gmail.com> 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 <aw...@gmail.com> wrote:
> >> >> > > On 6/22/07, Henk Vanhoe <He...@kava.be> 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
> >> >> > >
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
>