Re: [Trinidad] Detailstamp facet problem

2007-07-03 Thread 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

Re: [Trinidad] Detailstamp facet problem

2007-07-03 Thread Adam Winer
On 7/3/07, Henk Vanhoe [EMAIL PROTECTED] 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

Re: [Trinidad] Detailstamp facet problem

2007-06-27 Thread Henk Vanhoe
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

Re: [Trinidad] Detailstamp facet problem

2007-06-27 Thread Adam Winer
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? --

Re: [Trinidad] Detailstamp facet problem

2007-06-26 Thread Adam Winer
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

Re: [Trinidad] Detailstamp facet problem

2007-06-25 Thread Adam Winer
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

Re: [Trinidad] Detailstamp facet problem

2007-06-25 Thread Adam Winer
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

Re: [Trinidad] Detailstamp facet problem

2007-06-25 Thread Adam Winer
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,

Re: [Trinidad] Detailstamp facet problem

2007-06-22 Thread Henk Vanhoe
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

Re: [Trinidad] Detailstamp facet problem

2007-05-24 Thread Henk Vanhoe
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'

[Trinidad] Detailstamp facet problem

2007-05-18 Thread Henk Vanhoe
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