You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by gomera <se...@gmail.com> on 2008/03/06 19:03:46 UTC
Re: getMarkupId doesn't return the id from the markup
Sorry man, but your recommendation is not valid at all. An ID selector is
much more important than a class selector and it is used for different
things.
Changing the HTML just because Wicket throws away my ids it is something
very frustrating and doing this from Java is not an option.
My workaround: Still using 1.2.6 until it is fixed :,(
igor.vaynberg wrote:
>
> my recommendation has always been to let wicket generate the ids.
>
> the css argument is invalid imho because you can just as easily use a
> class
> instead of id
>
--
View this message in context: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tp11277169p15879983.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: getMarkupId doesn't return the id from the markup
Posted by Igor Vaynberg <ig...@gmail.com>.
umm, so what exactly happens if i create a component that uses id.
then someone takes it and decides to put two instances of it in the
page.... they get an error, and that makes my component unusable to
them?
-igor
On Sat, Mar 8, 2008 at 12:24 PM, John Patterson <jd...@gmail.com> wrote:
> I realise that until code is submitted this is just theory but...
>
>
> On 8 Mar 2008, at 17:12, Johan Compagner wrote:
>
> > and if such an exception is thrown then what?
>
> Crash. Error page. The standard. It is an error and invalid to use
> duplicate ids on one page.
>
>
> > then you have to set them all by hand?
> > If by such a thing that in development you have a repeater or what
> > ever that
> > doesnt generate yet
> > the second same id, but because of other larger data in production
> > there is
> > then suddenly in production
> > an exception is thrown? That would be horrible.
>
>
> Of course you can never be 100 percent certain that testing will
> reveal every bug. But a NPE is just as likely to escape into
> production. If the user specifies an id it is because they need to
> use it in Javascript or CSS and that will clearly not work as
> expected if, due to a programming error, they create duplicate ids.
> Fail fast is a good thing.
>
> Wicket would strongly recommend using class="" instead of id=""
> wherever possible for exactly those reasons. But if the developer
> cannot avoid using id wicket should let them.
>
Re: getMarkupId doesn't return the id from the markup
Posted by John Patterson <jd...@gmail.com>.
I realise that until code is submitted this is just theory but...
On 8 Mar 2008, at 17:12, Johan Compagner wrote:
> and if such an exception is thrown then what?
Crash. Error page. The standard. It is an error and invalid to use
duplicate ids on one page.
> then you have to set them all by hand?
> If by such a thing that in development you have a repeater or what
> ever that
> doesnt generate yet
> the second same id, but because of other larger data in production
> there is
> then suddenly in production
> an exception is thrown? That would be horrible.
Of course you can never be 100 percent certain that testing will
reveal every bug. But a NPE is just as likely to escape into
production. If the user specifies an id it is because they need to
use it in Javascript or CSS and that will clearly not work as
expected if, due to a programming error, they create duplicate ids.
Fail fast is a good thing.
Wicket would strongly recommend using class="" instead of id=""
wherever possible for exactly those reasons. But if the developer
cannot avoid using id wicket should let them.
Re: getMarkupId doesn't return the id from the markup
Posted by Johan Compagner <jc...@gmail.com>.
and if such an exception is thrown then what?
then you have to set them all by hand?
If by such a thing that in development you have a repeater or what ever that
doesnt generate yet
the second same id, but because of other larger data in production there is
then suddenly in production
an exception is thrown? That would be horrible.
johan
On Sat, Mar 8, 2008 at 7:10 AM, John Patterson <jd...@gmail.com> wrote:
>
> On 7 Mar 2008, at 23:52, Igor Vaynberg wrote:
> >>
> >> 100% agree. But you still should come with a solution that covers
> >> that
> >> without touching the IDs of the components on the page that
> >> clearly won't
> >> run into that issue.
>
> I think the ideal behaviour would be if Wicket always used the markup
> id from the html if one is specified and threw an exception if the id
> was used twice. But I don't know what problems exist in implementing
> this.
>
Re: getMarkupId doesn't return the id from the markup
Posted by Matej Knopp <ma...@gmail.com>.
Yes there are. Unfortunately due to current markup parsing
implementation we can only read the component tag during the rendering
process, which is way to late, as we often need the component id
sooner than that.
-Matej
On Sat, Mar 8, 2008 at 7:10 AM, John Patterson <jd...@gmail.com> wrote:
>
> On 7 Mar 2008, at 23:52, Igor Vaynberg wrote:
> >>
> >> 100% agree. But you still should come with a solution that covers
> >> that
> >> without touching the IDs of the components on the page that
> >> clearly won't
> >> run into that issue.
>
> I think the ideal behaviour would be if Wicket always used the markup
> id from the html if one is specified and threw an exception if the id
> was used twice. But I don't know what problems exist in implementing
> this.
>
--
Resizable and reorderable grid components.
http://www.inmethod.com
Re: getMarkupId doesn't return the id from the markup
Posted by John Patterson <jd...@gmail.com>.
On 7 Mar 2008, at 23:52, Igor Vaynberg wrote:
>>
>> 100% agree. But you still should come with a solution that covers
>> that
>> without touching the IDs of the components on the page that
>> clearly won't
>> run into that issue.
I think the ideal behaviour would be if Wicket always used the markup
id from the html if one is specified and threw an exception if the id
was used twice. But I don't know what problems exist in implementing
this.
Re: getMarkupId doesn't return the id from the markup
Posted by Igor Vaynberg <ig...@gmail.com>.
On Fri, Mar 7, 2008 at 3:46 AM, JP Saraceno
<ju...@teracode.com> wrote:
>
> 100% agree. But you still should come with a solution that covers that
> without touching the IDs of the components on the page that clearly won't
> run into that issue.
we are all ears...we have thought about this long and hard, but maybe
we are too close and missed something. ideas and patches are always
welcome.
-igor
>
> Actually, that was in fact what Wicket did until the fix for
> http://issues.apache.org/jira/browse/WICKET-694 and until Form, Button and
> other classes started to have setOutputMarkupId(true) in their constructors.
>
>
>
>
> igor.vaynberg wrote:
> >
> > i do understand that. however, html ids were created using thinking
> > that the entire html document is generated by a monolithic generator.
> > when you use a component oriented framework as a generator for html
> > something that is unique across the entire document becomes difficult
> > because each component works in isolation - that is where the power of
> > these component oriented frameworks comes from.
> >
>
> --
> View this message in context: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tp11277169p15891177.html
>
>
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: getMarkupId doesn't return the id from the markup
Posted by JP Saraceno <ju...@teracode.com>.
100% agree. But you still should come with a solution that covers that
without touching the IDs of the components on the page that clearly won't
run into that issue.
Actually, that was in fact what Wicket did until the fix for
http://issues.apache.org/jira/browse/WICKET-694 and until Form, Button and
other classes started to have setOutputMarkupId(true) in their constructors.
igor.vaynberg wrote:
>
> i do understand that. however, html ids were created using thinking
> that the entire html document is generated by a monolithic generator.
> when you use a component oriented framework as a generator for html
> something that is unique across the entire document becomes difficult
> because each component works in isolation - that is where the power of
> these component oriented frameworks comes from.
>
--
View this message in context: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tp11277169p15891177.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: getMarkupId doesn't return the id from the markup
Posted by Igor Vaynberg <ig...@gmail.com>.
On Fri, Mar 7, 2008 at 3:27 AM, juan.pablo.coen.mitrani
<fo...@gmail.com> wrote:
> igor.vaynberg wrote:
> >
> > wicket does not take ownership of id attributes by default, you have
> > to explicitly call setoutputmarkupid(true) on the component.
> >
> > [...]
>
> >
> > not true, see above. and i am not aware of any change in
> > policy...wicket still doesnt touch anything by default
> >
>
> In fact, in Wicket 1.3.1 some components, like Form and Button, call
> setOutputMarkupId(true) in their constructors (so it is not easily
> overridable for all instances) and this was not like that in the previous
> version that I was using (1.2.6).
well, 1.2.6 doesnt support nested forms, doesnt support setting the
default submit button for the form, doesnt support submitlink, etc.
you see where im heading with this? these changes dont just happen
because we feel like it. that said, we are looking at a way to reduce
this at least for the Button/SubmitLink....
-igor
>
> -----
> Juan Pablo Coen Mitrani
> --
> View this message in context: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tp11277169p15891162.html
>
>
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: getMarkupId doesn't return the id from the markup
Posted by "juan.pablo.coen.mitrani" <fo...@gmail.com>.
igor.vaynberg wrote:
>
> wicket does not take ownership of id attributes by default, you have
> to explicitly call setoutputmarkupid(true) on the component.
>
> [...]
>
> not true, see above. and i am not aware of any change in
> policy...wicket still doesnt touch anything by default
>
In fact, in Wicket 1.3.1 some components, like Form and Button, call
setOutputMarkupId(true) in their constructors (so it is not easily
overridable for all instances) and this was not like that in the previous
version that I was using (1.2.6).
-----
Juan Pablo Coen Mitrani
--
View this message in context: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tp11277169p15891162.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: getMarkupId doesn't return the id from the markup
Posted by Igor Vaynberg <ig...@gmail.com>.
On Thu, Mar 6, 2008 at 1:33 PM, JP Saraceno
<ju...@teracode.com> wrote:
> Having wicket taking ownership of the IDs by default makes very hard to do
> stuff outside wicket control (like css/javascript work, but also Selenium
> web testing for example). That reminds me a lot to the things I dislike the
> most about the .NET framework.
wicket does not take ownership of id attributes by default, you have
to explicitly call setoutputmarkupid(true) on the component.
> One can have many technologies working over the HTML in a web dev scenario,
> and all of them will rely on the ability to do id-based stuff. Not
> understanding this is not understanding web development IMHO.
i do understand that. however, html ids were created using thinking
that the entire html document is generated by a monolithic generator.
when you use a component oriented framework as a generator for html
something that is unique across the entire document becomes difficult
because each component works in isolation - that is where the power of
these component oriented frameworks comes from.
so if i write a panel that has this markup:
<wicket:panel>
<div wicket:id="foo" id="bar">content</div>
<a href="#" onclick="document.getElementById("foo").hide();"/>
</wicket:panel>
it all works great. now what happens when i put two of these panels
into my component hierarchy?
or maybe i use two third party components that happen to use the same
hardcoded markup id?
usecases for calling setoutputmarkupid(true) have to do with you
having to attach some dynamic client-side behavior to these
components, so taking over the id - which is the only way to uniquely
identify a node in html seems reasonable to me. you cant have cake and
eat it too.
> CSS id selectors are very different than class ones, both conceptually and
> in practice (i.e. the way browsers handle it).
yes, and this is suggested as a workaround, not as a better alternative.
> You should also consider migration path, as this change can make entire
> applications to break, and there seems not to be a solution that doesn't
> involve writing a line of code for every component that you were relying on
> its id attribute.
we have never recommended relying on id attributes once you call
setoutputmarkupid(true), in fact we have recommended against this all
along.
> The change on this policy seems derived from an implementation issue rather
> than a framework concept.
not true, see above. and i am not aware of any change in
policy...wicket still doesnt touch anything by default
> Namely, if repeaters and composites are an issue, then what I think would be
> the best behaviour is to take the id attribute on the markup and *in those
> cases* apply a policy to avoid duplication. Such a policy should be more
> meaningful than an autogenerated id from a counter, and maybe even
> overridable.
>
> For example, if I have "foobar" on a repeater template, it will be nice to
> generate "foobar_x" ids with "x" the containerID + iteration index. That's a
> useful Id that can be used to do javascript stuff.
yeah, sounds great on paper...would you mind coming up with a patch?
and if you try, dont forget that one of the most common usecases that
gets our users to complain and that we have recently fixed is this:
TextField tf=new TextField("foo");
add(tf);
tf.setOutputMarkupId(true);
String id=tf.getMarkupId(); // <== this has to return what will be in the markup
add(new SomeJavascriptBehavior(id));
-igor
>
>
> igor.vaynberg wrote:
> >
> > in component frameworks it is very difficult to use ids because
> > components are reused and composited, and managing all those ids by
> > hand will be very tedious and you will still probably end up with
> > duplicate ones in the produced html.
> >
>
> --
> View this message in context: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tp11277169p15884377.html
>
>
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
ist
Re: getMarkupId doesn't return the id from the markup
Posted by JP Saraceno <ju...@teracode.com>.
Sure. But I think there's a way a to come up with a good solution for that
case also (e.g. a counter of how many instances of that specific panel you
have).
Johan Compagner wrote:
>
> it is not just repeaters
> its also panels, if i put 2 date picker panels for example on the form
> then
> that panel has html that also can have the same id
>
--
View this message in context: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tp11277169p15891165.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: getMarkupId doesn't return the id from the markup
Posted by Johan Compagner <jc...@gmail.com>.
it is not just repeaters
its also panels, if i put 2 date picker panels for example on the form then
that panel has html that also can have the same id
also the markup id is not really know until the first render so that is also
a bit of a problem (you cant call getMarkupId() somewhere in
your constructor code because then the markup id cant be get yet)
wicket doesnt replace just all the ids only if we have to use it (in ajax
behaviors)
johan
On Thu, Mar 6, 2008 at 10:33 PM, JP Saraceno <
juan.pablo.saraceno@teracode.com> wrote:
>
> One of the reasons that made me choose wicket was actually his ability to
> be
> non-intrusive of the HTML. Actually I think I remember J. Locke saying
> that
> the very motivation behind having a special wicket-id attribute instead of
> using directly the HTML id attribute was not to mess with it.
>
> Having wicket taking ownership of the IDs by default makes very hard to do
> stuff outside wicket control (like css/javascript work, but also Selenium
> web testing for example). That reminds me a lot to the things I dislike
> the
> most about the .NET framework.
>
> One can have many technologies working over the HTML in a web dev
> scenario,
> and all of them will rely on the ability to do id-based stuff. Not
> understanding this is not understanding web development IMHO.
>
> CSS id selectors are very different than class ones, both conceptually and
> in practice (i.e. the way browsers handle it).
>
> You should also consider migration path, as this change can make entire
> applications to break, and there seems not to be a solution that doesn't
> involve writing a line of code for every component that you were relying
> on
> its id attribute.
>
> The change on this policy seems derived from an implementation issue
> rather
> than a framework concept.
>
> Namely, if repeaters and composites are an issue, then what I think would
> be
> the best behaviour is to take the id attribute on the markup and *in those
> cases* apply a policy to avoid duplication. Such a policy should be more
> meaningful than an autogenerated id from a counter, and maybe even
> overridable.
>
> For example, if I have "foobar" on a repeater template, it will be nice to
> generate "foobar_x" ids with "x" the containerID + iteration index. That's
> a
> useful Id that can be used to do javascript stuff.
>
>
>
>
> igor.vaynberg wrote:
> >
> > in component frameworks it is very difficult to use ids because
> > components are reused and composited, and managing all those ids by
> > hand will be very tedious and you will still probably end up with
> > duplicate ones in the produced html.
> >
>
> --
> View this message in context:
> http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tp11277169p15884377.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com<http://nabble.com/>
> .
>
>
Re: getMarkupId doesn't return the id from the markup
Posted by JP Saraceno <ju...@teracode.com>.
One of the reasons that made me choose wicket was actually his ability to be
non-intrusive of the HTML. Actually I think I remember J. Locke saying that
the very motivation behind having a special wicket-id attribute instead of
using directly the HTML id attribute was not to mess with it.
Having wicket taking ownership of the IDs by default makes very hard to do
stuff outside wicket control (like css/javascript work, but also Selenium
web testing for example). That reminds me a lot to the things I dislike the
most about the .NET framework.
One can have many technologies working over the HTML in a web dev scenario,
and all of them will rely on the ability to do id-based stuff. Not
understanding this is not understanding web development IMHO.
CSS id selectors are very different than class ones, both conceptually and
in practice (i.e. the way browsers handle it).
You should also consider migration path, as this change can make entire
applications to break, and there seems not to be a solution that doesn't
involve writing a line of code for every component that you were relying on
its id attribute.
The change on this policy seems derived from an implementation issue rather
than a framework concept.
Namely, if repeaters and composites are an issue, then what I think would be
the best behaviour is to take the id attribute on the markup and *in those
cases* apply a policy to avoid duplication. Such a policy should be more
meaningful than an autogenerated id from a counter, and maybe even
overridable.
For example, if I have "foobar" on a repeater template, it will be nice to
generate "foobar_x" ids with "x" the containerID + iteration index. That's a
useful Id that can be used to do javascript stuff.
igor.vaynberg wrote:
>
> in component frameworks it is very difficult to use ids because
> components are reused and composited, and managing all those ids by
> hand will be very tedious and you will still probably end up with
> duplicate ones in the produced html.
>
--
View this message in context: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tp11277169p15884377.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: getMarkupId doesn't return the id from the markup
Posted by Igor Vaynberg <ig...@gmail.com>.
well, ive given my opinion and you have given yours.
in component frameworks it is very difficult to use ids because
components are reused and composited, and managing all those ids by
hand will be very tedious and you will still probably end up with
duplicate ones in the produced html.
we do, however, support component.setmarkupid() that lets you set your own...
-igor
On Thu, Mar 6, 2008 at 10:03 AM, gomera <se...@gmail.com> wrote:
>
> Sorry man, but your recommendation is not valid at all. An ID selector is
> much more important than a class selector and it is used for different
> things.
>
> Changing the HTML just because Wicket throws away my ids it is something
> very frustrating and doing this from Java is not an option.
>
> My workaround: Still using 1.2.6 until it is fixed :,(
>
>
>
> igor.vaynberg wrote:
> >
> > my recommendation has always been to let wicket generate the ids.
> >
> > the css argument is invalid imho because you can just as easily use a
> > class
> > instead of id
> >
>
> --
> View this message in context: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tp11277169p15879983.html
>
>
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>