> .. my main opposition to this was based on the fact that it was filed as
> a bug.
>
I also initially considered this issue as a feature request, this is the
reason why the topic is called "[RFE] getMarkupId()"... my mistake was to
file this as a bug and not enhancement..
> If you're going to call setOutputMarkupId (true), then don't use invalid
> HTML id chars in your component id's.
>
In the issue description you can see the concrete example of using the
component id. It is not about using invalid HTML id chars. I would never use
the '*' or '>' characters for component id. I used the '.' character because
the component was contained in a form with CompoundPropertyModel attached,
so the '.' had a special meaning in this context: model mapping to a field
of the model object. This is a very convenient method, since I do not have
to manually specify the model for each form component.
But as you see, the main drawback of this example is that I cannot access
the DOM element mapped to wicket component, because the
$("#quantity.unit123") has a different meaning than
document.getElementById('quantity.unit123').
Alex
Ryan Holmes wrote:
>
> Yeah, that's one reason I wanted this issue to get some exposure.
> What's being asked for (and, in fairness, is described in the issue
> although I missed it initially) is completely "CSS selector safe"
> markup id's. So, in your example, at least '>', '.', and '*' would
> have to be substituted because they have special meaning in a CSS
> selector. About half of the remaining chars are not valid in an HTML
> id, but that's a separate issue.
>
> So this is really about the contract of getMarkupId() and what
> constraints it should enforce on the strings it returns. I've always
> been comfortable with the idea that it's a user's responsibility not
> to use invalid HTML id characters in a component id since it's the
> user's choice to call setOutputMarkupId(true) and it's easy to
> understand how component id's relate to markup id's. Of course,
> Wicket should add only very safe characters when it manipulates the
> id for uniqueness, etc. but I'm not sure if it should do more than that.
>
> I don't know about 1.3, but in 1.2 getMarkupId() doesn't promise to
> return a valid HTML id -- much less one without CSS selector chars --
> and it doesn't seem like this has been a problem for many, if any,
> users.
>
> It seems like this issue breaks down into a few specific questions:
>
> 1) Should or does getMarkupId() return valid HTML id's?
>
> 2) Should getMarkupId() return id's that can be used without escaping
> as an element id in a CSS selector?
>
> 3) Does the answer to 2 depend on the answer to 1 or is it reasonable
> to provide convenience for CSS contexts even though validity is not
> guaranteed?
>
> Sorry for all the questions and no answers, but my main opposition to
> this was based on the fact that it was filed as a bug. When
> considered as an enhancement, I can appreciate the convenience. But I
> also think the current behavior (as of 1.2, anyway) has the advantage
> of being very simple. If you're going to call setOutputMarkupId
> (true), then don't use invalid HTML id chars in your component id's.
> And if you need to use markup id's in a CSS selector context, it's
> easy enough to escape them yourself -- either on the client or server.
>
> -Ryan
>
> On Sep 27, 2007, at 2:24 AM, Johan Compagner wrote:
>
>> its not just about the dot
>> it als this starting with an number that we already did fix by
>> testing it
>> and then prepending a letter.
>> I am just curious if there are more of these kinds of things
>>
>> new Component("1_-%$&.,2<>*")
>>
>> what markup id is then generated? Is that one valid?
>> Ofcourse this is a bit stupid example but just as an example..
>>
>> johan
>>
>> On 9/27/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
>>>
>>> On 9/27/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>>>> we shouldn't generate illegal id's no matter what a developer
>>>> gives us
>>> as
>>>> there componentid
>>>> or is that already taken care off? (before this change?)
>>>
>>> It is not illegal to put a dot in a markup id!
>>>
>>> Martijn
>>>
>>> --
>>> Buy Wicket in Action: http://manning.com/dashorst
>>> Apache Wicket 1.3.0-beta3 is released
>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta3/
>>>
>
>
>
--
View this message in context:
http://www.nabble.com/-VOTE--WICKET-995-tf4523748.html#a12935196
Sent from the Wicket - Dev mailing list archive at Nabble.com.
