I've finally been bitten by this bug and would like to work on a fix "now". Some background on the problem in question can be found in https://issues.apache.org/jira/browse/TAPESTRY-1278 and https://issues.apache.org/jira/browse/TAPESTRY-1274.
My only problem with the current MultipleFormSupport implementation is that it would unnecessarily lengthen generated client id values and almost never be able to honor the original component ID specified for a component. It would also require enough Selenium test changes on my current project to make it almost unbearable to deal with. I would like to propose that we: -) Remove MultipleFormSupport (or mark it as deprecated if it's too late) and handle this issue directly once in the core FormSupport implementation. -) Use the same basic logic that MultipleFormSupport implements but instead of prefixing ids with form id values use the knowledge of existing forms in the render cycle to re-create the internal state of IdAllocator such that it is seeded in exactly the same state as that used by previous forms so ID generation noise is kept as minimal as possible. For example, the following form layout: <form jwcid="[EMAIL PROTECTED]"><input jwcid="[EMAIL PROTECTED]" /></form> <form jwcid="[EMAIL PROTECTED]"><input jwcid="[EMAIL PROTECTED]" /></form> would result in a more predictable html output of: <form name="first" id="first"><input type="text" name="name" id="name" /></form> <form name="second" id="second"><input type="text" name="name_0" id="name_0" /></form> I think this is what Andy wanted to move towards doing already but I wanted to bring it up for discussion as I need to solve the problem now-ish. -- 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]
