Just to be pedantic even in your odd/even example that could work with
classes since an element can have more than one class...

I think the performance problem for the browser trying to find an element by
class is the bigger problem. Although in many cases events are just attached
to elements that happen to have a particular class.

Quite often HTML monkeys (not ours of course) get carried away with ids and
use them to apply a particular behaviour rather than identifying a unique
element.

Wicket shifts a lot of the Ajax stuff away from the HTML monkey for things
like updating elements so it may be more natural to ask them to just attach
behaviours to elements we mark with a particular class. In that way we don't
have to worry about re-use, we may be able to mix and match styles and
client side effects etc.

I am definitely not suggesting that wicket doesn't update/use ids to mark
elements just that we are planning to rely less on them being known before
runtime. So CSS etc should be more class rather than id heavy.



Maris Orbidans-2 wrote:
> 
> 
> I use ajax as well, but I don't understand what's the problem with 
> setOutputMarkupId ?
> 
> In any case I am sure that forcing unique class attributes will create 
> much bigger problem.  Almost any non trivial web design uses identical 
> class values in many places.  Sometimes CSS class is used just to
> specify background color or something that is applied to many html tags. 
> Are you saying that it's going to be impossible ?   I am afraid that 
> many developers (including me) won't be able to use wicket anymore.
>  
> Maris
> 
>> 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.
>>>>>>>
>>>>>>>             
>>>>>>           
>>>>>         
>>>>       
>>>     
>>
>>   
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-RFE--getMarkupId%28%29-tf4493344.html#a12855924
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to