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
.. 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
On 9/28/07, Alex Objelean [EMAIL PROTECTED] 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
On 9/27/07, Ryan Holmes [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote:
On 9/27/07, Ryan Holmes [EMAIL PROTECTED] wrote:
I've always
been comfortable with the
On 9/28/07, Eelco Hillenius [EMAIL PROTECTED] 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
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
On 9/28/07, Frank Bille [EMAIL PROTECTED] wrote:
on 9/28/07, Johan Compagner [EMAIL PROTECTED] 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
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.
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
On 9/28/07, Eelco Hillenius [EMAIL PROTECTED] 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
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
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 [EMAIL PROTECTED] wrote:
On 9/28/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
we should *always* put quality first.
And that is why I say we
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 [EMAIL PROTECTED] wrote:
At
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
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:
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
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
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 [EMAIL PROTECTED] wrote:
The '.' is legal where it's being used, the problem
[ 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, '#', '')
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)
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,
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
23 matches
Mail list logo
