You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Ryan Holmes <ry...@hyperstep.com> on 2007/09/26 19:25:38 UTC
[VOTE] WICKET-995
At Igor's request, I'm asking for a vote on https://issues.apache.org/
jira/browse/WICKET-995
The issue has already been fixed, but reopened due to questions and
some opinions against the change. I think the comments on the issue
provide enough background, so here are the choices:
[ ] 1) Keep the change. It provides friendlier HTML id's by
eliminating '.' characters and it's perfectly safe.
[ ] 2) Revert the change. It's not a bug and the "magic" behavior is
unnecessary and/or dangerous.
-Ryan
Re: [VOTE] WICKET-995
Posted by Eelco Hillenius <ee...@gmail.com>.
Tough choice but I lean towards:
[ x ] 1) Keep the change. It provides friendlier HTML id's by
eliminating '.' characters and it's perfectly safe.
[ ] 2) Revert the change. It's not a bug and the "magic" behavior is
unnecessary and/or dangerous.
Eelco
Re: [VOTE] WICKET-995
Posted by Kent Tong <ke...@cpttm.org.mo>.
My non-binding vote:
[x] 1) Keep the change. It provides friendlier HTML id's by
eliminating '.' characters and it's perfectly safe.
[ ] 2) Revert the change. It's not a bug and the "magic" behavior is
unnecessary and/or dangerous.
I would reverse my vote if the change had not been made as the request
here is to work around a bug in another product and that product is not
a critical product for Wicket to function. It just doesn't make sense to
waste time on that.
However, as the change has been made and there is no ill effect, there is
no reason to undo the change either as that would even waste more time,
provided that there is no assumed guarantee that Wicket will take such
good care of JQuery and might revert back to a dot or anything valid in
the future.
--
View this message in context: http://www.nabble.com/-VOTE--WICKET-995-tf4523748.html#a12914042
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [VOTE] WICKET-995
Posted by Alex Objelean <al...@isdc.ro>.
In this case here is my vote:
[X] 1) Keep the change. It provides friendlier HTML id's by
eliminating '.' characters and it's perfectly safe.
[ ] 2) Revert the change. It's not a bug and the "magic" behavior is
unnecessary and/or dangerous.
igor.vaynberg wrote:
>
> anyone can participate, their votes are nonbinding - but they do give us
> an
> indication which way the community is leaning
>
> -igor
>
--
View this message in context: http://www.nabble.com/-VOTE--WICKET-995-tf4523748.html#a12907072
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [VOTE] WICKET-995
Posted by Igor Vaynberg <ig...@gmail.com>.
anyone can participate, their votes are nonbinding - but they do give us an
indication which way the community is leaning
-igor
On 9/26/07, Alex Objelean <al...@isdc.ro> wrote:
>
>
> That is exactly what the JIRA issue states (substitute all special
> selector
> characters). The implementation is up to the assignee of the task. Also, I
> do not think that any non wicket-core-developer should participate on the
> vote. Anyway, you know my choice :)...
>
>
> Ryan Holmes wrote:
> >
> >
> >> [ x] 2) Revert the change. It's not a bug and the "magic" behavior
> >> is unnecessary and/or dangerous.
> >
> > (non-binding)
> >
> > I can understand the convenience factor, but I'm worried about
> > opening a can of worms. I mean, why not substitute all special CSS
> > selector characters (e.g. space, '#', '>') instead of just '.'?
> >
> > -Ryan
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-VOTE--WICKET-995-tf4523748.html#a12906725
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: [VOTE] WICKET-995
Posted by Alex Objelean <al...@isdc.ro>.
That is exactly what the JIRA issue states (substitute all special selector
characters). The implementation is up to the assignee of the task. Also, I
do not think that any non wicket-core-developer should participate on the
vote. Anyway, you know my choice :)...
Ryan Holmes wrote:
>
>
>> [ x] 2) Revert the change. It's not a bug and the "magic" behavior
>> is unnecessary and/or dangerous.
>
> (non-binding)
>
> I can understand the convenience factor, but I'm worried about
> opening a can of worms. I mean, why not substitute all special CSS
> selector characters (e.g. space, '#', '>') instead of just '.'?
>
> -Ryan
>
>
--
View this message in context: http://www.nabble.com/-VOTE--WICKET-995-tf4523748.html#a12906725
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [VOTE] WICKET-995
Posted by Ryan Holmes <ry...@hyperstep.com>.
> [ x] 2) Revert the change. It's not a bug and the "magic" behavior
> is unnecessary and/or dangerous.
(non-binding)
I can understand the convenience factor, but I'm worried about
opening a can of worms. I mean, why not substitute all special CSS
selector characters (e.g. space, '#', '>') instead of just '.'?
-Ryan
Re: [VOTE] WICKET-995
Posted by Johan Compagner <jc...@gmail.com>.
What do you mean with depend on the id generation? in what way?
it is not stable anyway right now anymore,
johan
On 9/28/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> On 9/28/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > we should *always* put quality first.
>
> And that is why I say we shouldn't have put the damned fix in in the
> first place, because it doesn't increase our quality, but introduces
> risks for our current user base that may depend on the id generation.
>
> But since the blasted thing is already in, I don't veto it, but have a
> *VERY* strong preference it be pulled out, if there are more
> committers that feel the same way.
>
> 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/
>
Re: [VOTE] WICKET-995
Posted by Martijn Dashorst <ma...@gmail.com>.
On 9/28/07, Eelco Hillenius <ee...@gmail.com> wrote:
> we should *always* put quality first.
And that is why I say we shouldn't have put the damned fix in in the
first place, because it doesn't increase our quality, but introduces
risks for our current user base that may depend on the id generation.
But since the blasted thing is already in, I don't veto it, but have a
*VERY* strong preference it be pulled out, if there are more
committers that feel the same way.
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/
Re: [VOTE] WICKET-995
Posted by Eelco Hillenius <ee...@gmail.com>.
> And shipping the damned release *IS* important and *VERY* necessary,
> or are we forgetting that we have still several users on a particular
> branch with a constructor change and generics? So instead of working
> around a couple of javascript frameworks' bugs we could fix bugs in
> our code.
Both things are important. The people on the branch with constructor
change and generics, yeah we should keep pushing to get to a final
release faster, I agree. But it is exactly like I predicted before we
started reverting isn't it? It just takes a long time, and we should
*always* put quality first.
Eelco
Re: [VOTE] WICKET-995
Posted by Martijn Dashorst <ma...@gmail.com>.
On 9/28/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > Well, let me put *my* pragmatic hat on, and state that we better ship
> > our final release, instead of playing super hero and fix bugs in other
> > frameworks by applying workarounds in our code.
>
> Imho, that's pragmatic when it comes to our project management, not
> when it comes to fixing problems users have.
This particular problem lies with JQuery and other JS frameworks.
There are enough problems our users have with Wicket internal bugs
before we need to make the rest of the world a better place.
And shipping the damned release *IS* important and *VERY* necessary,
or are we forgetting that we have still several users on a particular
branch with a constructor change and generics? So instead of working
around a couple of javascript frameworks' bugs we could fix bugs in
our code.
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/
Re: [VOTE] WICKET-995
Posted by Eelco Hillenius <ee...@gmail.com>.
On 9/28/07, Martijn Dashorst <ma...@gmail.com> wrote:
> On 9/28/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > I'm inclined to say 0.9 for option 2, as working around bugs does seem
> > > like a stopgap measure.
> >
> > Well, if it fixes enough problems, whether the fault is with us or it
> > isn't, I'm for 'fixing' and keeping a pragmatic hat on.
>
> Well, let me put *my* pragmatic hat on, and state that we better ship
> our final release, instead of playing super hero and fix bugs in other
> frameworks by applying workarounds in our code.
Imho, that's pragmatic when it comes to our project management, not
when it comes to fixing problems users have.
Eelco
Re: [VOTE] WICKET-995
Posted by Martijn Dashorst <ma...@gmail.com>.
On 9/28/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > I'm inclined to say 0.9 for option 2, as working around bugs does seem
> > like a stopgap measure.
>
> Well, if it fixes enough problems, whether the fault is with us or it
> isn't, I'm for 'fixing' and keeping a pragmatic hat on.
Well, let me put *my* pragmatic hat on, and state that we better ship
our final release, instead of playing super hero and fix bugs in other
frameworks by applying workarounds in our code.
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/
Re: [VOTE] WICKET-995
Posted by Eelco Hillenius <ee...@gmail.com>.
> I'm inclined to say 0.9 for option 2, as working around bugs does seem
> like a stopgap measure.
Well, if it fixes enough problems, whether the fault is with us or it
isn't, I'm for 'fixing' and keeping a pragmatic hat on.
Eelco
Re: [VOTE] WICKET-995
Posted by Martijn Dashorst <ma...@gmail.com>.
hmm, you're sending mixed signals :) so you're 0.9 for option two I presume.
It is hard to say, I'm not sure if this will break stuff of people
that depend on the old behavior, and are not jquery users. I just
tested this with problem with prototype.js, and that one also breaks
the dot notation in their javascript css selector method ($$).
However, I am positive that the javascript libraries are at fault
here: in that they don't support the \. notation correctly (safari
does the right thing with stylesheets though!).
I'm inclined to say 0.9 for option 2, as working around bugs does seem
like a stopgap measure.
Martijn
<html>
<head>
<style type="text/css">
div {
height : 100px;
width : 100px;
}
#foo.bar {
background-color : red;
}
#foo\.bar {
background-color : blue;
}
</style>
</head>
<body>
<div id="foo" class="bar"></div>
<div id="foo.bar"></div>
</body>
</html>
This shows what you'd expect (in safari) a red and blue box.
Re: [VOTE] WICKET-995
Posted by Gwyn Evans <gw...@gmail.com>.
On Wednesday, September 26, 2007, 6:25:38 PM, Ryan <ry...@hyperstep.com> wrote:
> At Igor's request, I'm asking for a vote on https://issues.apache.org/
> jira/browse/WICKET-995
[-0.9] 2) Revert the change. It's not a bug and the "magic" behavior is
unnecessary and/or dangerous.
At the moment I don't believe that we've seen an example where it's
actually dangerous, so not quite -1, but it does appears to me that
we're adding code to work around a bug/missing feature in jQuery.
While I've nothing against jQuery, that's a step beyond where I'm
comfortable, especially if we've not raised the issue with them to see
if they can fix it.
/Gwyn
Re: [VOTE] WICKET-995
Posted by Johan Compagner <jc...@gmail.com>.
And we already do change the id because we are auto prepending a page
counter...
That already will break stuff when people are moving from 1.2 to 1.3 (i know
all about that... ;( )
johan
On 9/27/07, Gwyn Evans <gw...@gmail.com> wrote:
>
> The '.' is legal where it's being used, the problem appears to be that
> some JavaScript libraries don't correctly parse it but instead do
> something different.
>
> On the one hand, this is just the autogenerated ids, as far as we
> can see at the moment, it's a 'safe' fix and (I think) anyone relying
> on the old behaviour has other options/is taking a risk, while on the
> other, it's adding 'magic' to work around third-party bugs.
>
> /Gwyn
>
> On Thursday, September 27, 2007, 9:58:47 AM, Johan <jc...@gmail.com>
> 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?)
>
> > So you keep the change on my end if that also fixes the really illegal
> stuff
> > anyway
>
> > johan
>
>
>
> > On 9/26/07, Ryan Holmes <ry...@hyperstep.com> wrote:
> >>
> >> At Igor's request, I'm asking for a vote on https://issues.apache.org/
> >> jira/browse/WICKET-995
> >>
> >> The issue has already been fixed, but reopened due to questions and
> >> some opinions against the change. I think the comments on the issue
> >> provide enough background, so here are the choices:
> >>
> >> [ ] 1) Keep the change. It provides friendlier HTML id's by
> >> eliminating '.' characters and it's perfectly safe.
> >> [ ] 2) Revert the change. It's not a bug and the "magic" behavior is
> >> unnecessary and/or dangerous.
> >>
> >>
> >> -Ryan
> >>
> >>
>
>
>
> /Gwyn
>
>
Re: [VOTE] WICKET-995
Posted by Gwyn Evans <gw...@gmail.com>.
The '.' is legal where it's being used, the problem appears to be that
some JavaScript libraries don't correctly parse it but instead do
something different.
On the one hand, this is just the autogenerated ids, as far as we
can see at the moment, it's a 'safe' fix and (I think) anyone relying
on the old behaviour has other options/is taking a risk, while on the
other, it's adding 'magic' to work around third-party bugs.
/Gwyn
On Thursday, September 27, 2007, 9:58:47 AM, Johan <jc...@gmail.com> 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?)
> So you keep the change on my end if that also fixes the really illegal stuff
> anyway
> johan
> On 9/26/07, Ryan Holmes <ry...@hyperstep.com> wrote:
>>
>> At Igor's request, I'm asking for a vote on https://issues.apache.org/
>> jira/browse/WICKET-995
>>
>> The issue has already been fixed, but reopened due to questions and
>> some opinions against the change. I think the comments on the issue
>> provide enough background, so here are the choices:
>>
>> [ ] 1) Keep the change. It provides friendlier HTML id's by
>> eliminating '.' characters and it's perfectly safe.
>> [ ] 2) Revert the change. It's not a bug and the "magic" behavior is
>> unnecessary and/or dangerous.
>>
>>
>> -Ryan
>>
>>
/Gwyn
Re: [VOTE] WICKET-995
Posted by Ryan Holmes <ry...@hyperstep.com>.
sure, but is that really practical? calling setmarkupid all over the
place is a lot of work and usually discouraged because there's no
guarantee of uniqueness.
I'm going to file an RFE and try to make the case for a well defined,
stable implementation of getMarkupId there, since it's getting OT here.
btw, "seriously suck" was a bad choice of words -- hadn't had my
coffee yet ;)
-Ryan
On Sep 28, 2007, at 10:54 AM, Igor Vaynberg wrote:
> its not meant to be stable, like i said the only contract is that
> it returns
> something unique. how that is generated is up to the internals. if
> you want
> stable ids for testing or wahtever other purpose then call
> setmarkupid()
> yourself.
>
> -igor
>
>
> On 9/28/07, Ryan Holmes <ry...@hyperstep.com> wrote:
>>
>> All other components *after* or all other components *inside*? If
>> it's all components *after* then markup id generation has changed
>> radically since 1.2 and Wicket-generated markup id's really can't be
>> used for automated testing, which would seriously suck.
>>
>> -Ryan
>>
>>
>> On Sep 28, 2007, at 2:10 AM, Johan Compagner wrote:
>>
>>> The id's are a bit random already.. If you add a component
>>> somewhere in the
>>> page
>>> then all other components after that do have a changed markupid.
>>>
>>> johan
>>>
>>>
>>>
>>> On 9/28/07, Ryan Holmes <ry...@hyperstep.com> wrote:
>>>>
>>>> On Sep 28, 2007, at 12:01 AM, Igor Vaynberg wrote:
>>>>
>>>>> i think this is where the problem stems for you. markupid and
>>>>> componentid
>>>>> are not really meant to be tightly coupled. the only contract on
>>>>> markupid is
>>>>> that it returns a unique id. for the most part we have been trying
>>>>> to reuse
>>>>> componentid in some shape or form because it makes debugging
>>>>> easier, but i
>>>>> can totally see an optimization that is enabled in production mode
>>>>> where
>>>>> markup ids are generated to minimize their length. "a2e", "ox",
>>>>> etc.
>>>>>
>>>>> -igor
>>>>
>>>> I see. In that case, you would use whatever character set is
>>>> convenient for the user so why not do that now? I guess you don't
>>>> look at the substitution of special CSS chars as a change in
>>>> getMarkupId's contract, but just a convenience in the current
>>>> implementation that could change at any time.
>>>>
>>>> However, I think a well-defined, stable implementation of
>>>> getMarkupId
>>>> is necessary to support automated UI testing. It's fine if the
>>>> recipe
>>>> changes over time, and alternate implementations sound like a cool
>>>> idea, but I don't see how you can maintain a large set of tests
>>>> against a web framework with essentially random HTML id's. Or am I
>>>> missing something?
>>>>
>>>> -Ryan
>>>>
>>
>>
Re: [VOTE] WICKET-995
Posted by Igor Vaynberg <ig...@gmail.com>.
its not meant to be stable, like i said the only contract is that it returns
something unique. how that is generated is up to the internals. if you want
stable ids for testing or wahtever other purpose then call setmarkupid()
yourself.
-igor
On 9/28/07, Ryan Holmes <ry...@hyperstep.com> wrote:
>
> All other components *after* or all other components *inside*? If
> it's all components *after* then markup id generation has changed
> radically since 1.2 and Wicket-generated markup id's really can't be
> used for automated testing, which would seriously suck.
>
> -Ryan
>
>
> On Sep 28, 2007, at 2:10 AM, Johan Compagner wrote:
>
> > The id's are a bit random already.. If you add a component
> > somewhere in the
> > page
> > then all other components after that do have a changed markupid.
> >
> > johan
> >
> >
> >
> > On 9/28/07, Ryan Holmes <ry...@hyperstep.com> wrote:
> >>
> >> On Sep 28, 2007, at 12:01 AM, Igor Vaynberg wrote:
> >>
> >>> i think this is where the problem stems for you. markupid and
> >>> componentid
> >>> are not really meant to be tightly coupled. the only contract on
> >>> markupid is
> >>> that it returns a unique id. for the most part we have been trying
> >>> to reuse
> >>> componentid in some shape or form because it makes debugging
> >>> easier, but i
> >>> can totally see an optimization that is enabled in production mode
> >>> where
> >>> markup ids are generated to minimize their length. "a2e", "ox", etc.
> >>>
> >>> -igor
> >>
> >> I see. In that case, you would use whatever character set is
> >> convenient for the user so why not do that now? I guess you don't
> >> look at the substitution of special CSS chars as a change in
> >> getMarkupId's contract, but just a convenience in the current
> >> implementation that could change at any time.
> >>
> >> However, I think a well-defined, stable implementation of getMarkupId
> >> is necessary to support automated UI testing. It's fine if the recipe
> >> changes over time, and alternate implementations sound like a cool
> >> idea, but I don't see how you can maintain a large set of tests
> >> against a web framework with essentially random HTML id's. Or am I
> >> missing something?
> >>
> >> -Ryan
> >>
>
>
Re: [VOTE] WICKET-995
Posted by Ryan Holmes <ry...@hyperstep.com>.
All other components *after* or all other components *inside*? If
it's all components *after* then markup id generation has changed
radically since 1.2 and Wicket-generated markup id's really can't be
used for automated testing, which would seriously suck.
-Ryan
On Sep 28, 2007, at 2:10 AM, Johan Compagner wrote:
> The id's are a bit random already.. If you add a component
> somewhere in the
> page
> then all other components after that do have a changed markupid.
>
> johan
>
>
>
> On 9/28/07, Ryan Holmes <ry...@hyperstep.com> wrote:
>>
>> On Sep 28, 2007, at 12:01 AM, Igor Vaynberg wrote:
>>
>>> i think this is where the problem stems for you. markupid and
>>> componentid
>>> are not really meant to be tightly coupled. the only contract on
>>> markupid is
>>> that it returns a unique id. for the most part we have been trying
>>> to reuse
>>> componentid in some shape or form because it makes debugging
>>> easier, but i
>>> can totally see an optimization that is enabled in production mode
>>> where
>>> markup ids are generated to minimize their length. "a2e", "ox", etc.
>>>
>>> -igor
>>
>> I see. In that case, you would use whatever character set is
>> convenient for the user so why not do that now? I guess you don't
>> look at the substitution of special CSS chars as a change in
>> getMarkupId's contract, but just a convenience in the current
>> implementation that could change at any time.
>>
>> However, I think a well-defined, stable implementation of getMarkupId
>> is necessary to support automated UI testing. It's fine if the recipe
>> changes over time, and alternate implementations sound like a cool
>> idea, but I don't see how you can maintain a large set of tests
>> against a web framework with essentially random HTML id's. Or am I
>> missing something?
>>
>> -Ryan
>>
Re: [VOTE] WICKET-995
Posted by Johan Compagner <jc...@gmail.com>.
The id's are a bit random already.. If you add a component somewhere in the
page
then all other components after that do have a changed markupid.
johan
On 9/28/07, Ryan Holmes <ry...@hyperstep.com> wrote:
>
> On Sep 28, 2007, at 12:01 AM, Igor Vaynberg wrote:
>
> > i think this is where the problem stems for you. markupid and
> > componentid
> > are not really meant to be tightly coupled. the only contract on
> > markupid is
> > that it returns a unique id. for the most part we have been trying
> > to reuse
> > componentid in some shape or form because it makes debugging
> > easier, but i
> > can totally see an optimization that is enabled in production mode
> > where
> > markup ids are generated to minimize their length. "a2e", "ox", etc.
> >
> > -igor
>
> I see. In that case, you would use whatever character set is
> convenient for the user so why not do that now? I guess you don't
> look at the substitution of special CSS chars as a change in
> getMarkupId's contract, but just a convenience in the current
> implementation that could change at any time.
>
> However, I think a well-defined, stable implementation of getMarkupId
> is necessary to support automated UI testing. It's fine if the recipe
> changes over time, and alternate implementations sound like a cool
> idea, but I don't see how you can maintain a large set of tests
> against a web framework with essentially random HTML id's. Or am I
> missing something?
>
> -Ryan
>
Re: [VOTE] WICKET-995
Posted by Ryan Holmes <ry...@hyperstep.com>.
On Sep 28, 2007, at 12:01 AM, Igor Vaynberg wrote:
> i think this is where the problem stems for you. markupid and
> componentid
> are not really meant to be tightly coupled. the only contract on
> markupid is
> that it returns a unique id. for the most part we have been trying
> to reuse
> componentid in some shape or form because it makes debugging
> easier, but i
> can totally see an optimization that is enabled in production mode
> where
> markup ids are generated to minimize their length. "a2e", "ox", etc.
>
> -igor
I see. In that case, you would use whatever character set is
convenient for the user so why not do that now? I guess you don't
look at the substitution of special CSS chars as a change in
getMarkupId's contract, but just a convenience in the current
implementation that could change at any time.
However, I think a well-defined, stable implementation of getMarkupId
is necessary to support automated UI testing. It's fine if the recipe
changes over time, and alternate implementations sound like a cool
idea, but I don't see how you can maintain a large set of tests
against a web framework with essentially random HTML id's. Or am I
missing something?
-Ryan
Re: [VOTE] WICKET-995
Posted by Alex Objelean <al...@isdc.ro>.
I like this idea.. :)
In wicket 1.2.x branch, when markup id mirrored the component hierarchy, the
generated DOM was huge due to long id names
(page_body_panel_tab_form_component_quantity_unit)... I was very happy to
see a change in 1.3.x branch. Minimizing it even more, seems to be a great
idea.
Alex
igor.vaynberg wrote:
>
> On 9/27/07, Ryan Holmes <ry...@hyperstep.com> wrote:
>>
>> 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.
>
>
> i think this is where the problem stems for you. markupid and componentid
> are not really meant to be tightly coupled. the only contract on markupid
> is
> that it returns a unique id. for the most part we have been trying to
> reuse
> componentid in some shape or form because it makes debugging easier, but i
> can totally see an optimization that is enabled in production mode where
> markup ids are generated to minimize their length. "a2e", "ox", etc.
>
> -igor
>
>
--
View this message in context: http://www.nabble.com/-VOTE--WICKET-995-tf4523748.html#a12936497
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [VOTE] WICKET-995
Posted by Gerolf Seitz <ge...@gmail.com>.
On 9/28/07, Frank Bille <fr...@apache.org> wrote:
>
> on 9/28/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> > but thats easy then
> >
> > getMarkupId()
> > {
> > return "id" + pageCounter++;
> > }
> >
> > And maybe have the switch that in development mode we do what we do now?
> >
>
> For my sake we could do that always. :-)
>
> Frank
>
i'd vote for that (if it were in the original vote).
if people still want to use the wicket:id as a base for html ids,
we could "generify" the markupId generation with some kind of
IMarkupIdGenerator or IMarkupIdStrategy which could be registered in the
application.
but that would probably be overkill.
gerolf
Re: [VOTE] WICKET-995
Posted by Frank Bille <fr...@apache.org>.
on 9/28/07, Johan Compagner <jc...@gmail.com> wrote:
>
> but thats easy then
>
> getMarkupId()
> {
> return "id" + pageCounter++;
> }
>
> And maybe have the switch that in development mode we do what we do now?
>
For my sake we could do that always. :-)
Frank
Re: [VOTE] WICKET-995
Posted by Johan Compagner <jc...@gmail.com>.
but thats easy then
getMarkupId()
{
return "id" + pageCounter++;
}
And maybe have the switch that in development mode we do what we do now?
johan
On 9/28/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> On 9/27/07, Ryan Holmes <ry...@hyperstep.com> wrote:
> >
> > 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.
>
>
> i think this is where the problem stems for you. markupid and componentid
> are not really meant to be tightly coupled. the only contract on markupid
> is
> that it returns a unique id. for the most part we have been trying to
> reuse
> componentid in some shape or form because it makes debugging easier, but i
> can totally see an optimization that is enabled in production mode where
> markup ids are generated to minimize their length. "a2e", "ox", etc.
>
> -igor
>
Re: [VOTE] WICKET-995
Posted by Igor Vaynberg <ig...@gmail.com>.
On 9/27/07, Ryan Holmes <ry...@hyperstep.com> wrote:
>
> 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.
i think this is where the problem stems for you. markupid and componentid
are not really meant to be tightly coupled. the only contract on markupid is
that it returns a unique id. for the most part we have been trying to reuse
componentid in some shape or form because it makes debugging easier, but i
can totally see an optimization that is enabled in production mode where
markup ids are generated to minimize their length. "a2e", "ox", etc.
-igor
Re: [VOTE] WICKET-995
Posted by Alex Objelean <al...@isdc.ro>.
I completely agree with you. But what do you suggest:
parse on the client-side generated markup id and escape this kind of
characters or treat the special case by using document.getElementById
instead of $(), or maybe just give up discussing about this issue?
Martijn Dashorst wrote:
>
> On 9/28/07, Alex Objelean <al...@isdc.ro> wrote:
>> 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').
>
> As already noted about a zillion times: there is a bug in the
> javascript libraries: this should work:
> $("#quantity\.unit123") == document.getElementById('quantity.unit123')
>
> 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#a12935347
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [VOTE] WICKET-995
Posted by Martijn Dashorst <ma...@gmail.com>.
On 9/28/07, Alex Objelean <al...@isdc.ro> wrote:
> 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').
As already noted about a zillion times: there is a bug in the
javascript libraries: this should work:
$("#quantity\.unit123") == document.getElementById('quantity.unit123')
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/
Re: [VOTE] WICKET-995
Posted by Alex Objelean <al...@isdc.ro>.
> .. 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 <ma...@gmail.com> wrote:
>>>
>>> On 9/27/07, Johan Compagner <jc...@gmail.com> 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.
Re: [VOTE] WICKET-995
Posted by Ryan Holmes <ry...@hyperstep.com>.
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 <ma...@gmail.com> wrote:
>>
>> On 9/27/07, Johan Compagner <jc...@gmail.com> 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/
>>
Re: [VOTE] WICKET-995
Posted by Johan Compagner <jc...@gmail.com>.
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 <ma...@gmail.com> wrote:
>
> On 9/27/07, Johan Compagner <jc...@gmail.com> 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/
>
Re: [VOTE] WICKET-995
Posted by Martijn Dashorst <ma...@gmail.com>.
On 9/27/07, Johan Compagner <jc...@gmail.com> 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/
Re: [VOTE] WICKET-995
Posted by Johan Compagner <jc...@gmail.com>.
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?)
So you keep the change on my end if that also fixes the really illegal stuff
anyway
johan
On 9/26/07, Ryan Holmes <ry...@hyperstep.com> wrote:
>
> At Igor's request, I'm asking for a vote on https://issues.apache.org/
> jira/browse/WICKET-995
>
> The issue has already been fixed, but reopened due to questions and
> some opinions against the change. I think the comments on the issue
> provide enough background, so here are the choices:
>
> [ ] 1) Keep the change. It provides friendlier HTML id's by
> eliminating '.' characters and it's perfectly safe.
> [ ] 2) Revert the change. It's not a bug and the "magic" behavior is
> unnecessary and/or dangerous.
>
>
> -Ryan
>
>