You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Henk Vanhoe <He...@kava.be> on 2007/05/18 16:33:19 UTC
[Trinidad] Detailstamp facet problem
Hi,
I am using an editable table inside a detailstamp facet. The data in the
table comes from a request-scoped managed bean. As I want to avoid
session scoped beans, I use the tomahawk savestate tag to save the state
of my beans. Everything works fine, except that when I change something
in this table and subsequently hide the table, my changes are not
submitted (when I leave the detail expanded there is no problem). In my
web.xml file I'm using the following options:
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
<context-param>
<param-name>org.apache.myfaces.trinidad.CLIENT_STATE_METHOD</param-name>
<param-value>token</param-value>
</context-param>
<context-param>
<param-name>
org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE
</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>
org.apache.myfaces.trinidad.CACHE_VIEW_ROOT
</param-name>
<param-value>true</param-value>
</context-param>
I also noticed that when I change the
org.apache.myfaces.trinidad.CLIENT_STATE_METHOD to 'all' instead of
'token', this problem goes away. Is this a bug?
Regards,
Henk
Re: [Trinidad] Detailstamp facet problem
Posted by 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
> >> >> > >
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
>
>
>
Re: [Trinidad] Detailstamp facet problem
Posted by 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
Posted by Adam Winer <aw...@gmail.com>.
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
Posted by Henk Vanhoe <He...@kava.be>.
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
Posted by Adam Winer <aw...@gmail.com>.
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
Posted by Adam Winer <aw...@gmail.com>.
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
Posted by Adam Winer <aw...@gmail.com>.
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
Posted by Adam Winer <aw...@gmail.com>.
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
Posted by Henk Vanhoe <He...@kava.be>.
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". 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...
Regards,
Henk
Henk Vanhoe wrote:
> I have tested this problem again with the latest trinidad from the svn
> repository, and now the test results are a little bit different...
>
> When I use CLIENT_STATE_METHOD 'all', it doesn't work anymore and I'm
> having this exception message (without stacktrace) when I click on a
> 'Show detail' link:
>
> [ValueBindingImpl] Exception while determining read-only state of
> value-binding : #{adres.gemeente}
>
> When I use CLIENT_STATE_METHOD 'token', everything works fine, but
> only when I don't use immediate="true" with the containing table! If I
> use immediate="true", any time I collapse the detail, I lose my
> changes when I submit. Is this the normal behaviour of the table
> component?
>
> But if we don't use the immediate attribute, each time someone clicks
> on the 'hide' or 'show' link, all inputfields are validated, which is
> not the behaviour we want to have...
>
> Regards,
> Henk
>
> Henk Vanhoe wrote:
>> Hi,
>>
>> I am using an editable table inside a detailstamp facet. The data in
>> the table comes from a request-scoped managed bean. As I want to
>> avoid session scoped beans, I use the tomahawk savestate tag to save
>> the state of my beans. Everything works fine, except that when I
>> change something in this table and subsequently hide the table, my
>> changes are not submitted (when I leave the detail expanded there is
>> no problem). In my web.xml file I'm using the following options:
>>
>> <context-param>
>> <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
>> <param-value>client</param-value>
>> </context-param>
>>
>> <context-param>
>>
>> <param-name>org.apache.myfaces.trinidad.CLIENT_STATE_METHOD</param-name>
>> <param-value>token</param-value>
>> </context-param>
>> <context-param>
>> <param-name>
>> org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE
>> </param-name>
>> <param-value>true</param-value>
>> </context-param>
>>
>> <context-param>
>> <param-name>
>> org.apache.myfaces.trinidad.CACHE_VIEW_ROOT
>> </param-name>
>> <param-value>true</param-value>
>> </context-param>
>>
>> I also noticed that when I change the
>> org.apache.myfaces.trinidad.CLIENT_STATE_METHOD to 'all' instead of
>> 'token', this problem goes away. Is this a bug?
>>
>> Regards,
>> Henk
>>
>
>
Re: [Trinidad] Detailstamp facet problem
Posted by Henk Vanhoe <He...@kava.be>.
I have tested this problem again with the latest trinidad from the svn
repository, and now the test results are a little bit different...
When I use CLIENT_STATE_METHOD 'all', it doesn't work anymore and I'm
having this exception message (without stacktrace) when I click on a
'Show detail' link:
[ValueBindingImpl] Exception while determining read-only state of
value-binding : #{adres.gemeente}
When I use CLIENT_STATE_METHOD 'token', everything works fine, but only
when I don't use immediate="true" with the containing table! If I use
immediate="true", any time I collapse the detail, I lose my changes when
I submit. Is this the normal behaviour of the table component?
But if we don't use the immediate attribute, each time someone clicks on
the 'hide' or 'show' link, all inputfields are validated, which is not
the behaviour we want to have...
Regards,
Henk
Henk Vanhoe wrote:
> Hi,
>
> I am using an editable table inside a detailstamp facet. The data in
> the table comes from a request-scoped managed bean. As I want to avoid
> session scoped beans, I use the tomahawk savestate tag to save the
> state of my beans. Everything works fine, except that when I change
> something in this table and subsequently hide the table, my changes
> are not submitted (when I leave the detail expanded there is no
> problem). In my web.xml file I'm using the following options:
>
> <context-param>
> <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
> <param-value>client</param-value>
> </context-param>
>
> <context-param>
>
> <param-name>org.apache.myfaces.trinidad.CLIENT_STATE_METHOD</param-name>
> <param-value>token</param-value>
> </context-param>
> <context-param>
> <param-name>
> org.apache.myfaces.trinidad.USE_APPLICATION_VIEW_CACHE
> </param-name>
> <param-value>true</param-value>
> </context-param>
>
> <context-param>
> <param-name>
> org.apache.myfaces.trinidad.CACHE_VIEW_ROOT
> </param-name>
> <param-value>true</param-value>
> </context-param>
>
> I also noticed that when I change the
> org.apache.myfaces.trinidad.CLIENT_STATE_METHOD to 'all' instead of
> 'token', this problem goes away. Is this a bug?
>
> Regards,
> Henk
>