Hi, I found out that tr:iterator expects it's children List to remain always the same, bc StampStates are indexed by position in children collection. However this is not always true, during postback request UIInstruction components generated by facelets are dropped from children collection (I think this might be because they are not saved in the viewstate, maybe webflow and it's serialization mechanism has something to do with this).
Is this bug of Trinidad or is problem somewhere else? Maybe it would be better if StampStates were indexed by component Id rather then by position? Any input much appreciated. Thanks Tibor On Tue, Mar 8, 2011 at 23:49, Tibor Blénessy <blene...@gmail.com> wrote: > Hello, > > I am having troubles with tr:iterator component. We are using tr:iterator > to dynamically create form elements (there are several labels and text > inputs for each item in the collection). However transition to next page > ends with ClassCastException that HtmlScript cannot be cast to > EditableValueHolder. This cast happens in restoreRowState method of EVHState > class. It seems to me that StampStates are somehow mismatched during save > and restore calls, and that HtmlScript component pickups wrong StampState > from the map (there should be no stamp state for HtmlScript afaik, but there > is instance of EVHState with corresponding key, I was unable to track how > this instance of EVHState gets created, but it is in the map even before the > first call to the saveStampState method for that request). > > We are using Trinidad 1.2.13, I found issue TRINIDAD-2047 in jira which > seemed to be related to the issue, so I build current 1.2.x branch, but > problem remains the same (althought 2047 helped a bit, bc stampstate map now > doesnt contain null values in key1 of DualKey class ). > > I understand that's quite difficult to help with such a vague description, > however it's quite difficult to simulate the issue in some simple scenario. > I would be gratefull if somehow could explain how StampStates are supposed > to work, bc code looks quite messy. > > We also use Spring Webflow 2.0 and Myfaces implementation 1.2.10 if it > could be of any relevance. > > Thanks > > Tibor Blenessy > > >
