That's good news... I won't be able to take a look before tomorrow morning though (that's +12H)
On Jan 14, 2008 8:54 PM, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > 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] > > -- Andreas Andreou - [EMAIL PROTECTED] - http://blog.andyhot.gr Tapestry / Tacos developer Open Source / JEE Consulting --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
