Hi! > Can you see how this would fail? > > <html> > <form wicket:id="form1"> > <input wicket:id="input" .../> > </form> > <form wicket:id="form2"> > <input wicket:id="input" .../> > </form> > </html>
That's old-school-wicket ;) This would not be allowed anymore. An application would have to be refactored (using an automated script) into: <html> <form wicket:id="form1"> <input wicket:id="input-1" .../> </form> <form wicket:id="form2"> <input wicket:id="input-X" .../> </form> </html> We would simply change wicket syntax: panels and pages require unique wicket id for all components. > What about repeaters? What about repeaters? Repeaters are generated on-the-fly anyways so they can be definitely computed on-the-fly. > What about if form1 was in BasePage.html and form2 was in HomePage.html > (which extends BasePage.html) - how do we know which input component to > get? The one you called add on in BasePage.java, or the one in > HomePage.java? Oh, we can't differentiate which class you called add from > within. Oh, and you could have meant for the one added in HomePage.java to > replace the one added in BasePage.java. > > How do you propose we do all that? You win some, you lose some. Nobody ever complained that parent and super classes cannot have protected fields with same names. Wicket:ids simply are considered protected-scoped. Maybe it could also be possible to define wicket:id:private which requires hierarcy and wicket:id which is "friendly" visibility etc. When there is a will, there is a way. ** Martin > > -- > Jeremy Thomerson > http://wickettraining.com > *Need a CMS for Wicket? Use Brix! http://brixcms.org* > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
