Hi! We could also make so that "wicket:id" is old-school and "wicket:id:protected" is new-school.
No need to refactor anything. Just pros without any cons. ** Martin 2010/11/5 Martin Makundi <martin.maku...@koodaripalvelut.com>: > 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
