I've finished my initial cut at a fix for https://issues.apache.org/jira/browse/TAPESTRY-1278 and https://issues.apache.org/jira/browse/TAPESTRY-1274 in the new branch (MultipleFormIDGeneration).
If anyone who care could take a look at this and voice any concerns before I merge to trunk it would be appreciated. The proposed solution discussed in the previous thread ended up being what was implemented. The logistics of it are: -) FormSupport no longer uses its own IdAllocator to allocate form element ids, it uses the IRequestCycle.getUniqueId() like everyone else. -) Just before doing any form rendering, FormSupport asks the IRequestCycle for an encoded state string of the current IdAllocator state - which is persisted in to a new hidden form input field, "seedids". This chunk of data is compressed && Base64 encoded. -) During a rewind the first thing FormSupport does is re-initialize IRequestCycle's IdAllocator instance using the submitted id seed that was persisted during the form render. This is what makes it all work. After that everything should be in exactly the same state as when the form rendered the last time. I also went ahead and completely removed any traces of FormSupportFactory from the codebase. My reasoning for this change was: -) There is no clear use for this abstraction anymore. If anyone can explain what current functionality needs this to exist I'd be more than happy to discuss it - but just having it in there "just in case" doesn't seem like a clear winning argument. -) If on the off chance anyone was actually using FormSupportFactory outside of Tapestry core they'd be screwed anyways (or likely) as the internal logistics of how FormSupportImpl works has changed enough to make breaking changes in this area likely already. I'm guessing that we probably have no users using this service right now anyways, or at least have very few. So, everything works now and the problem is solved. No form component should get rendered with the same id as any other anymore and all should be well. If I don't hear any protests I'll probably merge to trunk and make a new snapshot release later today. -- Jesse Kuhnert Tapestry / OGNL / Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
