> 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.
Yep, it just does formId:componentId everywhere... why the need to honor the original id? clientId or peekClientId just works > -) 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. Since it's configurable, why not just do an EnhancedFormSupport and make it the default... If it works ok, we can then remoce/deprecate MultipleFormSupport > 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 there's still a problem with that approach - imagine the first form initially hidden and then rendered on an ajax request... since second hasn't already rendered, idAllocator will give ids that already exist in the document... And i'm sure there are variations of this problem floating around. MultipleFormSupport doesn't solve this case either - what we use is a further subclass that just stores itself in the current cycle. This allows a custom NamespaceForm component to grab that instance and configure its prefix to a used defined value (usually the id of the entity to be processed) It's important that NamespaceForm sets the prefix in prepareForRender - but that's all there is to it. -- 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]
