That's fine, I'll wait until tomorrow then. On Jan 14, 2008 2:46 PM, Andreas Andreou <[EMAIL PROTECTED]> wrote: > 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] > >
-- 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]
