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

Reply via email to