no, requestcycle wont work. markup ids have to be unique across requests - for the lifecycle of the page.
clustering is also something i didnt think about... -igor On Feb 12, 2008 10:49 AM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > The request cycle sounds like a good place to put such a counter. Then the > counter is request relative, and synchronized by default for the request. > Martijn > > > On 2/12/08, Ryan Sonnek <[EMAIL PROTECTED]> wrote: > > > > I'm definitely not against the idea, but I would caution introducing > > an application wide ID generator. This would introduce a *single* > > synchronization point for component creation which *could* introduce a > > performance bottleneck. > > > > Only way to find out is to try, but this is just a word of caution. =) > > > > On Feb 12, 2008 12:42 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > > > one of the nagging things on the lists is that markup id is not > > > available until render time, this gets a lot of users hung up. the > > > problem is that we use a counter inside the page to generate the > > > unique id. what if instead we use a static counter, that will make > > > markup ids unique across pages also. the only problem is that it will > > > make the id counter increment faster, but with a Long we wont run out > > > any time soon. we should also keep the id string as short as possible, > > > maybe encode the integer using [0-9a-zA-Z] instead of just [0-9], or > > > even to make it faster encode it into hex... > > > > > > if no objections are raised i will make the change...will be nice to > > > have a major improvement to go along with 1.3.2 anyways > > > > > > -igor > > > > > > > > > -- > Buy Wicket in Action: http://manning.com/dashorst > Apache Wicket 1.3.1 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1 >
