Currently wicket guaranties unicity of the ID by appending a incremented
number:
markupId = getId() + page.getAutoIndex();
You will never have two wicket components with the same markupID.
Sam Hough wrote:
>
> What do you do about components in RepeatingView? (with numeric ids)
>
> So do you just make sure all your wicket ids are universally unique? So
> none that are just "form", "label", "button" etc? I quite like using
> "button" if only one within the container...
>
> What if you want to use the same component twice?
>
>
>
> Alex Objelean wrote:
>>
>> Performance on the client side is very important when you are working
>> with very large DOM (complex applications). The responsiveness of the
>> application is very important in this cases.
>>
>> Yes, I'm using ajax. I don't find it as a big drawback to set the
>> outputMarkupId to true when I need explicitly a component to have
>> generated Id.
>>
>>
>> Sam Hough wrote:
>>>
>>> So you use it just because of the performance of the browser DOM? Not
>>> because it has to be unique?
>>>
>>> Are you using Ajax? ie forced to do setOutputMarkupId? We are and that
>>> is probably the biggest reason we are trying to avoid them.
>>>
>>>
>>>
>>>
>>>
>>> Alex Objelean wrote:
>>>>
>>>>
>>>> In my application I extensively use the component generated id to
>>>> perform some DOM updates on the client side, also for client-side
>>>> validation.
>>>>
>>>> Also getting a DOM element by its ID is the fastest method comparing
>>>> with finding it using it's css class.
>>>>
>>>>
>>>>
>>>> Sam Hough wrote:
>>>>>
>>>>> When is the killer case for using id?
>>>>>
>>>>>
>>>>>
>>>>> Alex Objelean wrote:
>>>>>>
>>>>>> My personal opinion is that switching from id to class is not such a
>>>>>> good idea, simply because the ID attributes guaranties (of course you
>>>>>> can create two elements with same ID, but it is not the same as with
>>>>>> class attribute) the unicity of the element, also you can find the
>>>>>> element from js using document.getElementById...
>>>>>>
>>>>>> I hope that this radical change will not be made in the 1.3 release
>>>>>> as it has a great impact on any application developed using the
>>>>>> latest beta3 release. Also I think this issue should be discussed
>>>>>> more between the core developers.
>>>>>>
>>>>>> Alex.
>>>>>>
>>>>>>
>>>>>> Sam Hough wrote:
>>>>>>>
>>>>>>> We are going to stop using ids and move over to class as it make
>>>>>>> re-use easier and avoids a number of wicket problems with ids... The
>>>>>>> HTML monkey is not happy though. He reminds me of the Family Guy
>>>>>>> screaming monkey today.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Alex Objelean wrote:
>>>>>>>>
>>>>>>>> This is about how wicket generates dynamically markupID.
>>>>>>>>
>>>>>>>> I have, for instance, the following markup component:
>>>>>>>>
>>>>>>>> <input wicket:id="quantity.noOfUnits" />
>>>>>>>>
>>>>>>>> The generated markupId for this component looks like the following:
>>>>>>>> quantity.noOfUnits1232 .
>>>>>>>>
>>>>>>>> I suggest to escape any css valid specifiers from the generated
>>>>>>>> markupId, by replacing them with something else (for instance '_'
>>>>>>>> character).
>>>>>>>>
>>>>>>>> The problem appear when I am trying to identify the component by
>>>>>>>> it's id using some js library (like jQuery) and as a consequence
>>>>>>>> the result of this query: $("#quantity.noOfUnits1232") is invalid.
>>>>>>>>
>>>>>>>> Thank you!
>>>>>>>>
>>>>>>>> Alex.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12822124
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
