.. 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
Done (wicketstuff-misc moved under trunk).
/david
PS prefix subject with the name of wicketstuff project (eg :
[wicketstuff-jquery] ), it'll be easier to filter message.
David Bernard wrote:
Daniele,
wicketstuff-misc was added to a wrong location (under wicketstuff
instead of
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
13 matches
Mail list logo
