Let's say we have the following scenario: 1) Billy works on a very large team (say 100+ developers) on a Tapestry project
2) The team has a huge component library, and it's hard to look up every component's internal structure. Rather, the team reads the documentation and uses it (much like Tapestry components). 3) There is a @TextField based component called "foo" that Billy wants to use. 4) Billy drops "foo" component into the form on his page and it works great. 5) But, Billy also needs "bar" component (let's assume it's also @TextField based) which he grabs and drops into his form as well. So far all works great and Billy's amazed how easy things are!. 6) As improbable as it may seem, both "foo" and "bar" internally named their @TextField "tough". 7) Because Billy dropped "foo" before "bar" Tapestry will keep "foo" field intact, but rename "bar" field from "tough" to "tough_0". Billy is unaware of this because he didn't bother to view html source for the generated page. 8) Next, Billy wants to grab List<IFieldTracking> from getDelegate().getFieldTrackings(), and he intends to find IFieldTracking for "bar" by its name "tough". 9) Billy's code returns a valid instance of IFieldTracking, but to his suprise it's for "foo", not "bar". Confused, he's asking for help... Is there a better way to control something like this? What happens is each component has a set of validators, and a delegate of its own, because each component can fully validate itself as long as the host form provides the "master" delegate which gets populated on form submit. Querrying master delegate by component's field name can lead to problems if two components have the same field name. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
