sure, but is that really practical? calling setmarkupid all over the
place is a lot of work and usually discouraged because there's no
guarantee of uniqueness.
I'm going to file an RFE and try to make the case for a well defined,
stable implementation of getMarkupId there, since it's getting OT here.
btw, "seriously suck" was a bad choice of words -- hadn't had my
coffee yet ;)
-Ryan
On Sep 28, 2007, at 10:54 AM, Igor Vaynberg wrote:
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
