its not meant to be stable, like i said the only contract is that it returns something unique. how that is generated is up to the internals. if you want stable ids for testing or wahtever other purpose then call setmarkupid() yourself.
-igor On 9/28/07, Ryan Holmes <[EMAIL PROTECTED]> wrote: > > All other components *after* or all other components *inside*? If > it's all components *after* then markup id generation has changed > radically since 1.2 and Wicket-generated markup id's really can't be > used for automated testing, which would seriously suck. > > -Ryan > > > On Sep 28, 2007, at 2:10 AM, Johan Compagner wrote: > > > The id's are a bit random already.. If you add a component > > somewhere in the > > page > > then all other components after that do have a changed markupid. > > > > johan > > > > > > > > On 9/28/07, Ryan Holmes <[EMAIL PROTECTED]> wrote: > >> > >> On Sep 28, 2007, at 12:01 AM, Igor Vaynberg wrote: > >> > >>> i think this is where the problem stems for you. markupid and > >>> componentid > >>> are not really meant to be tightly coupled. the only contract on > >>> markupid is > >>> that it returns a unique id. for the most part we have been trying > >>> to reuse > >>> componentid in some shape or form because it makes debugging > >>> easier, but i > >>> can totally see an optimization that is enabled in production mode > >>> where > >>> markup ids are generated to minimize their length. "a2e", "ox", etc. > >>> > >>> -igor > >> > >> I see. In that case, you would use whatever character set is > >> convenient for the user so why not do that now? I guess you don't > >> look at the substitution of special CSS chars as a change in > >> getMarkupId's contract, but just a convenience in the current > >> implementation that could change at any time. > >> > >> However, I think a well-defined, stable implementation of getMarkupId > >> is necessary to support automated UI testing. It's fine if the recipe > >> changes over time, and alternate implementations sound like a cool > >> idea, but I don't see how you can maintain a large set of tests > >> against a web framework with essentially random HTML id's. Or am I > >> missing something? > >> > >> -Ryan > >> > >
