You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Eelco Hillenius <ee...@gmail.com> on 2007/06/24 20:30:28 UTC
getMarkupId doesn't return the id from the markup
Yep, you read that right. I just found out that if you explicitly
define an id attribute on your component, getMarkupId still just
returns a generated one. This suprises me; I'm pretty sure we always
agreed that if an explicit id is provided in the markup, that should
be used. See the date picker in wicket-examples/forminput for example:
it doesn't work now because the id is set to "dateProperty" but
getMarkupId, which is used by the date picker, returns
"dateProperty1".
The fix is easy[1], but results in a failing unit test. Imho, that
unit test is just too fragile, and I'm thinking about implementing a
quick fix for it and submit this change. But I wanted to check here
first in case I'm overlooking something.
Eelco
[1]
Index: /Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java
===================================================================
--- /Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java (revision
550266)
+++ /Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java (working
copy)
@@ -1181,10 +1181,13 @@
/**
* Retrieves id by which this component is represented within the markup.
+ * This is either the id attribute if it is set explicitly in the markup, or
+ * a generated id.
* <p>
* The point of this function is to generate a unique id to make it easy to
* locate this component in the generated markup for post-wicket processing
- * such as javascript or an xslt transform.
+ * such as javascript or an xslt transform in case no explicit id was set
+ * yet.
* <p>
* Note: This method should only be called after the component or its parent
* have been added to the page.
@@ -1204,7 +1207,13 @@
+ "to find the page it is supposed to operate in before you can call "
+ "this method (Component#getMarkupId)");
}
- markupId = getId() + page.getAutoIndex();
+ // try to read from markup
+ markupId = getMarkupAttributes().getString("id");
+ if (markupId == null)
+ {
+ // if not in the markup, generate one
+ markupId = getId() + page.getAutoIndex();
+ }
setMetaData(MARKUP_ID_KEY, markupId);
}
return markupId;
Re: getMarkupId doesn't return the id from the markup
Posted by Igor Vaynberg <ig...@gmail.com>.
i dont feel strongly about it anymore. a lot of people seem to want to shoot
themselves in the foot, and i am inclined to let them.
-igor
On 6/24/07, Matej Knopp <ma...@gmail.com> wrote:
>
> I believe the current behavior is intentional. Igor seemed to feel
> quite strongly about not using markup id specified in template. The
> reason is that it's not unique and it behaves wrongly in repeaters or
> when you put the component to page twice.
>
> I'd actually prefer wicket to preserve specified attribute because it
> can be handy in cauple of cases. But that's just my opinion.
>
> -Matej
>
> On 6/24/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > On 6/24/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > > I think everyone ran into it at one time... I know I did. Last time I
> > > think Igor threw some issues with repeaters into the mix, and then the
> > > discussion went dead.
> >
> > For all I know, it worked in 2.0. I remember testing it specifically.
> > I'm just surprised it doesn't work the same in 1.3. Did we forget to
> > backport it maybe? The name of the method is a pretty clear indication
> > what we had in mind with it, right?
> >
> > FYI, I tested all of the examples of wicket-examples, including the
> > ajax and repeater tests, and they worked fine. The unit test that
> > fails is RadioGroupTest#testFormProcessing but that is because the
> > page tested isn't backed up by the proper markup (it uses
> > org.apache.wicket.protocol.http.MockPage which doesn't have any of the
> > components that are added in that test). So the test is faulty here.
> >
> > Eelco
> >
>
Re: getMarkupId doesn't return the id from the markup
Posted by Jonathan Locke <jo...@gmail.com>.
me too.
i haven't read this entire thread yet, but at the risk of being redundant,
maybe repeaters could explicitly check that the id is not specified and
throw an exception if it is? we might need to provide a hook for this...
not sure what the best way is. something as simple as a tagging interface
checked during id generation would work (implements IAutomaticMarkupId),
although i don't love the use of tagging.
Matej Knopp-2 wrote:
>
> I believe the current behavior is intentional. Igor seemed to feel
> quite strongly about not using markup id specified in template. The
> reason is that it's not unique and it behaves wrongly in repeaters or
> when you put the component to page twice.
>
> I'd actually prefer wicket to preserve specified attribute because it
> can be handy in cauple of cases. But that's just my opinion.
>
> -Matej
>
> On 6/24/07, Eelco Hillenius <ee...@gmail.com> wrote:
>> On 6/24/07, Martijn Dashorst <ma...@gmail.com> wrote:
>> > I think everyone ran into it at one time... I know I did. Last time I
>> > think Igor threw some issues with repeaters into the mix, and then the
>> > discussion went dead.
>>
>> For all I know, it worked in 2.0. I remember testing it specifically.
>> I'm just surprised it doesn't work the same in 1.3. Did we forget to
>> backport it maybe? The name of the method is a pretty clear indication
>> what we had in mind with it, right?
>>
>> FYI, I tested all of the examples of wicket-examples, including the
>> ajax and repeater tests, and they worked fine. The unit test that
>> fails is RadioGroupTest#testFormProcessing but that is because the
>> page tested isn't backed up by the proper markup (it uses
>> org.apache.wicket.protocol.http.MockPage which doesn't have any of the
>> components that are added in that test). So the test is faulty here.
>>
>> Eelco
>>
>
>
--
View this message in context: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tp11277169p15882346.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: getMarkupId doesn't return the id from the markup
Posted by Matej Knopp <ma...@gmail.com>.
With javascript all you need is a simple label, which you attach to
<script> tag and output
"mymarkupid = " + component.getMarkupId();
and later in page you can use mymarkupid as the id.
There are serious issues with preserving markup id, most of them are
related to markup processing, as we don't have straignt 1:1
component<->markup mapping - because of borders and transparent
resolvers. Thus the actual component markup is known only in render
phase, which might be too late, as other components depending on
component markup id might have been already rendered.
-Matej
On 9/6/07, Igor Vaynberg <ig...@gmail.com> 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
>
> the javascript does carry some weight. if the javascript is inlined/static
> and in the page then yeah, it sucks that wicket would change the attribute,
> that is why we have a setmarkupid() that lets you override it. if you use it
> it is then up to you to make sure the id you set is unique.
>
> personally i keep my js snippets in .js files and use texttemplate with
> variable replacement to stick them into head. that way all my needed ids are
> just variables whose value i collect before outputting the javascript.
>
> -igor
>
>
> On 9/6/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> > the wicketid doesn't have to be unique only if you are setting that id
> > right
> > into the markupid yourself.
> > if not then wicket makes them unique (if we didn't do that THEN wicket ids
> > should be unique)
> >
> > The 2.0 way we just can't do because we don't know it early enough now
> > only
> > in onBeforeRender
> > igor did try some things out i believe
> >
> > But what would be nice if we try to get it from the html. But if you call
> > it
> > in your code to soon then we generate one.
> > But even if we take it from the html then still if the component is reused
> > we have a problem because it is not unique
> >
> > johan
> >
> >
> > On 9/6/07, Sam Hough <sa...@redspr.com> wrote:
> > >
> > >
> > > Guess the worst thing is that Wicket ids now have to be unique within
> > the
> > > whole page not just the parent component...
> > >
> > > The behaviour they had in 2.0 does seem better.
> > > --
> > > View this message in context:
> > >
> > http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tf3972925.html#a12525262
> > > 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>.
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 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.
>
>
Re: getMarkupId doesn't return the id from the markup
Posted by gomera <se...@gmail.com>.
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>.
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
the javascript does carry some weight. if the javascript is inlined/static
and in the page then yeah, it sucks that wicket would change the attribute,
that is why we have a setmarkupid() that lets you override it. if you use it
it is then up to you to make sure the id you set is unique.
personally i keep my js snippets in .js files and use texttemplate with
variable replacement to stick them into head. that way all my needed ids are
just variables whose value i collect before outputting the javascript.
-igor
On 9/6/07, Johan Compagner <jc...@gmail.com> wrote:
>
> the wicketid doesn't have to be unique only if you are setting that id
> right
> into the markupid yourself.
> if not then wicket makes them unique (if we didn't do that THEN wicket ids
> should be unique)
>
> The 2.0 way we just can't do because we don't know it early enough now
> only
> in onBeforeRender
> igor did try some things out i believe
>
> But what would be nice if we try to get it from the html. But if you call
> it
> in your code to soon then we generate one.
> But even if we take it from the html then still if the component is reused
> we have a problem because it is not unique
>
> johan
>
>
> On 9/6/07, Sam Hough <sa...@redspr.com> wrote:
> >
> >
> > Guess the worst thing is that Wicket ids now have to be unique within
> the
> > whole page not just the parent component...
> >
> > The behaviour they had in 2.0 does seem better.
> > --
> > View this message in context:
> >
> http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tf3972925.html#a12525262
> > 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>.
the wicketid doesn't have to be unique only if you are setting that id right
into the markupid yourself.
if not then wicket makes them unique (if we didn't do that THEN wicket ids
should be unique)
The 2.0 way we just can't do because we don't know it early enough now only
in onBeforeRender
igor did try some things out i believe
But what would be nice if we try to get it from the html. But if you call it
in your code to soon then we generate one.
But even if we take it from the html then still if the component is reused
we have a problem because it is not unique
johan
On 9/6/07, Sam Hough <sa...@redspr.com> wrote:
>
>
> Guess the worst thing is that Wicket ids now have to be unique within the
> whole page not just the parent component...
>
> The behaviour they had in 2.0 does seem better.
> --
> View this message in context:
> http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tf3972925.html#a12525262
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: getMarkupId doesn't return the id from the markup
Posted by Sam Hough <sa...@redspr.com>.
Guess the worst thing is that Wicket ids now have to be unique within the
whole page not just the parent component...
The behaviour they had in 2.0 does seem better.
--
View this message in context: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tf3972925.html#a12525262
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: getMarkupId doesn't return the id from the markup
Posted by Watter <ma...@welchkin.net>.
Sam Hough wrote:
>
> I was hunting around for this an hour ago after our HTML/JS/CSS guy
> complained that I had broken everything. We have our own base classes so
> in the constructor I've done:
> Some(String id) {
> super(id);
> setMarkupId(id);
> setOutputMarkupId(true);
> }
>
Thanks! Such an obvious thing to do. It didn't even occur to me. Clearly,
this isn't ideal as it forces me to manually keep these ID strings in sync
between my code and the template, but it will suffice as a workaround.
Thanks again!
--
View this message in context: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tf3972925.html#a12525162
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: getMarkupId doesn't return the id from the markup
Posted by Sam Hough <sa...@redspr.com>.
I was hunting around for this an hour ago after our HTML/JS/CSS guy
complained that I had broken everything. We have our own base classes so in
the constructor I've done:
Some(String id) {
super(id);
setMarkupId(id);
setOutputMarkupId(true);
}
So it will nuke the id set normally in the HTML so not really in the spirit
of Wicket. I can't decide if we should remove them (so just have <div
wicket:id="asd">) but that really not in the spirit of Wicket. Not great as
it is but want wicket and markup id the same anyway...
Nobody has complained for a few minutes...
Watter wrote:
>
>
> Eelco Hillenius wrote:
>>
>> On 6/25/07, Matej Knopp <ma...@gmail.com> wrote:
>>> I think reasonable behavior would be to generate markup id when
>>> invoked from constructor (instead of failing getting one from markup).
>>> However, I'm affraid the complications you have are caused by the fact
>>> the the component hasn't been rendered already, so it doesn't know
>>> it's markup position. At least we had similiar problems with 1.2,
>>> iirc.
>>
>> Yeah, I'm afraid of that too. And I understand that for some
>> components the markup position can only be known at runtime, right? Is
>> there any way anyone can think of how we could bind in an efficient
>> way before rendering?
>>
>
> I've read a number of threads on this subject and I'm still at something
> of a loss. I'm happy to accept that you guys are a 1000x better at
> framework building than I am and if you say that there are serious
> difficulties in implementing this, I can readily accept that.
>
> But what's the work around?
>
> There are at least two EXTREMELY common situations where as an application
> developer I need to be able to explicitly define an ID for an HTML
> element:
>
> 1) For CSS identification.
>
> 2) When I add javascript snippets to a page that interact with other
> elements.
>
> As it stands, I can't currently count on Wicket to leave my explicitly
> defined ID's alone. It's a little disconcerting to specify an ID in my
> template and have my rendered page not work as expected, only to find that
> when I look at the source in the browser, the ID has been dynamically
> modified.
>
> I guess I can learn to live with this behavior, but I'd love some advice
> on how to handle the use cases I mentioned above. Surely I'm not the only
> one running into those kinds of things.
>
>
>
--
View this message in context: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tf3972925.html#a12524622
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: getMarkupId doesn't return the id from the markup
Posted by Watter <ma...@welchkin.net>.
Eelco Hillenius wrote:
>
> On 6/25/07, Matej Knopp <ma...@gmail.com> wrote:
>> I think reasonable behavior would be to generate markup id when
>> invoked from constructor (instead of failing getting one from markup).
>> However, I'm affraid the complications you have are caused by the fact
>> the the component hasn't been rendered already, so it doesn't know
>> it's markup position. At least we had similiar problems with 1.2,
>> iirc.
>
> Yeah, I'm afraid of that too. And I understand that for some
> components the markup position can only be known at runtime, right? Is
> there any way anyone can think of how we could bind in an efficient
> way before rendering?
>
I've read a number of threads on this subject and I'm still at something of
a loss. I'm happy to accept that you guys are a 1000x better at framework
building than I am and if you say that there are serious difficulties in
implementing this, I can readily accept that.
But what's the work around?
There are at least two EXTREMELY common situations where as an application
developer I need to be able to explicitly define an ID for an HTML element:
1) For CSS identification.
2) When I add javascript snippets to a page that interact with other
elements.
As it stands, I can't currently count on Wicket to leave my explicitly
defined ID's alone. It's a little disconcerting to specify an ID in my
template and have my rendered page not work as expected, only to find that
when I look at the source in the browser, the ID has been dynamically
modified.
I guess I can learn to live with this behavior, but I'd love some advice on
how to handle the use cases I mentioned above. Surely I'm not the only one
running into those kinds of things.
--
View this message in context: http://www.nabble.com/getMarkupId-doesn%27t-return-the-id-from-the-markup-tf3972925.html#a12524564
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: getMarkupId doesn't return the id from the markup
Posted by Eelco Hillenius <ee...@gmail.com>.
On 6/25/07, Matej Knopp <ma...@gmail.com> wrote:
> I think reasonable behavior would be to generate markup id when
> invoked from constructor (instead of failing getting one from markup).
> However, I'm affraid the complications you have are caused by the fact
> the the component hasn't been rendered already, so it doesn't know
> it's markup position. At least we had similiar problems with 1.2,
> iirc.
Yeah, I'm afraid of that too. And I understand that for some
components the markup position can only be known at runtime, right? Is
there any way anyone can think of how we could bind in an efficient
way before rendering?
Eelco
Re: getMarkupId doesn't return the id from the markup
Posted by Matej Knopp <ma...@gmail.com>.
I think reasonable behavior would be to generate markup id when
invoked from constructor (instead of failing getting one from markup).
However, I'm affraid the complications you have are caused by the fact
the the component hasn't been rendered already, so it doesn't know
it's markup position. At least we had similiar problems with 1.2,
iirc.
-Matej
On 6/25/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > i can think of one, getMarkupId() can't really be called in the constructor
> > phase (as we could do in 2.0)
> > (it now can but then you really have to make sure how you construct your
> > objects you have to setup the hierachy up until the page as soon as
> > possible)
>
> Yeah, even now the component has to be able reach the page it is
> attached to to work. I thought/ hoped that being attached to the page
> would be good enough for the markup loading as well.
>
> Eelco
>
Re: getMarkupId doesn't return the id from the markup
Posted by Eelco Hillenius <ee...@gmail.com>.
> i can think of one, getMarkupId() can't really be called in the constructor
> phase (as we could do in 2.0)
> (it now can but then you really have to make sure how you construct your
> objects you have to setup the hierachy up until the page as soon as
> possible)
Yeah, even now the component has to be able reach the page it is
attached to to work. I thought/ hoped that being attached to the page
would be good enough for the markup loading as well.
Eelco
Re: getMarkupId doesn't return the id from the markup
Posted by Johan Compagner <jc...@gmail.com>.
i can think of one, getMarkupId() can't really be called in the constructor
phase (as we could do in 2.0)
(it now can but then you really have to make sure how you construct your
objects you have to setup the hierachy up until the page as soon as
possible)
johan
On 6/25/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> What are the side effects?
>
> We have been down this road too many times and we keep forgetting them
> (or ignoring until we can't bare them) I'd hate to not fix this one
> once and for all.
>
> Martijn
>
> --
> BREAKING NEWS: Wicket joins the Apache Software Foundation as Apache
> Wicket
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.6 contains a very important fix. Download Wicket now!
> http://wicketframework.org
>
Re: getMarkupId doesn't return the id from the markup
Posted by Eelco Hillenius <ee...@gmail.com>.
On 6/25/07, Martijn Dashorst <ma...@gmail.com> wrote:
> What are the side effects?
Jonathan had problems:
http://www.nabble.com/Unable-to-find-the-markup-for-the-component-tf3976741.html
and
the project I'm working on got some exceptions from the test site this
morning as well. For instance:
org.apache.wicket.WicketRuntimeException: Unable to find the markup
for the component. That may be due to transparent containers or
components implementing IComponentResolver: [MarkupContainer
[Component id = text, page =
ts4.web.wicket.page.workspace.ComponentPage, path =
1:content:reply-form:form:text.KeepAliveTextArea, isVisible = true,
isVersioned = false]]
at
org.apache.wicket.MarkupFragmentFinder.find(MarkupFragmentFinder.java:111)
at
org.apache.wicket.Component.getMarkupAttributes(Component.java:1176)
at org.apache.wicket.Component.getMarkupId(Component.java:1211)
at
org.apache.wicket.ajax.AbstractAjaxTimerBehavior.getPreconditionScript(AbstractAjaxTimerBehavior.java:96)
at
org.apache.wicket.ajax.AbstractDefaultAjaxBehavior.generateCallbackScript(AbstractDefaultAjaxBehavior.java:161)
at
org.apache.wicket.ajax.AbstractAjaxTimerBehavior.getCallbackScript(AbstractAjaxTimerBehavior.java:84)
at
org.apache.wicket.ajax.AbstractAjaxTimerBehavior.getJsTimeoutCall(AbstractAjaxTimerBehavior.java:78)
at
org.apache.wicket.ajax.AbstractAjaxTimerBehavior.renderHead(AbstractAjaxTimerBehavior.java:66)
at org.apache.wicket.Component.renderHead(Component.java:2182)
at
org.apache.wicket.markup.html.internal.HtmlHeaderContainer$1.component(HtmlHeaderContainer.java:209)
at
org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:820)
at
org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:835)
at
org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:835)
at
org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:835)
at
org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:860)
at
org.apache.wicket.markup.html.internal.HtmlHeaderContainer.renderHeaderSections(HtmlHeaderContainer.java:200)
at
org.apache.wicket.markup.html.internal.HtmlHeaderContainer.onComponentTagBody(HtmlHeaderContainer.java:134)
at
org.apache.wicket.Component.renderComponent(Component.java:2104)
at
org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1294)
at org.apache.wicket.Component.render(Component.java:1931)
at org.apache.wicket.Component.render(Component.java:1894)
at
org.apache.wicket.MarkupContainer.autoAdd(MarkupContainer.java:223)
at
org.apache.wicket.markup.resolver.HtmlHeaderResolver.resolve(HtmlHeaderResolver.java:81)
at
org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1206)
Unfortunately, I'm a bit too busy at this time to figure out what
exactly the problem is, but I left the issue open. It seems hard to
fix without having a construct like our 2.0 adventure had.
> We have been down this road too many times and we keep forgetting them
> (or ignoring until we can't bare them) I'd hate to not fix this one
> once and for all.
Me too. Maybe Juergen/ someone else has a good idea?
Eelco
Re: getMarkupId doesn't return the id from the markup
Posted by Martijn Dashorst <ma...@gmail.com>.
What are the side effects?
We have been down this road too many times and we keep forgetting them
(or ignoring until we can't bare them) I'd hate to not fix this one
once and for all.
Martijn
--
BREAKING NEWS: Wicket joins the Apache Software Foundation as Apache Wicket
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org
Re: getMarkupId doesn't return the id from the markup
Posted by Eelco Hillenius <ee...@gmail.com>.
Unfortunately, the fix for
http://issues.apache.org/jira/browse/WICKET-694 had some side effects
I didn't come across when testing :(
It's a bloody shame, but it seems that already too much code assumes
it can call getMarkupId where it shouldn't. I'm leaving the bug open,
but at this time I have no idea on how to fix it.
Eelco
On 6/24/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > I believe the current behavior is intentional. Igor seemed to feel
> > quite strongly about not using markup id specified in template. The
> > reason is that it's not unique and it behaves wrongly in repeaters or
> > when you put the component to page twice.
>
> I remember having this discussion a very long time ago, but I though
> we decided that even though there is some danger in it, it is the
> responsibility of the user. Which is the right thing imo.
>
> > I'd actually prefer wicket to preserve specified attribute because it
> > can be handy in cauple of cases. But that's just my opinion.
>
> The thing is that we call this method getMarkupId, but it only returns
> the id you can find in the markup when you *don't* provide one
> explicitly (and tell the component to write it's id). Even if you set
> setOutputMarkupId(true), Wicket won't override the id in the markup,
> which of course has the effect that any Javascript refering to the id
> - like the datepicker does - does not work.
>
> So we currently have the situation that if you set the id explictly,
> stuff won't work anyway, and we have a method name that doesn't do
> what the name hints (for it's current behavior it should be called
> something like getGeneratedMarkupId).
>
> Eelco
>
Re: getMarkupId doesn't return the id from the markup
Posted by Eelco Hillenius <ee...@gmail.com>.
> I believe the current behavior is intentional. Igor seemed to feel
> quite strongly about not using markup id specified in template. The
> reason is that it's not unique and it behaves wrongly in repeaters or
> when you put the component to page twice.
I remember having this discussion a very long time ago, but I though
we decided that even though there is some danger in it, it is the
responsibility of the user. Which is the right thing imo.
> I'd actually prefer wicket to preserve specified attribute because it
> can be handy in cauple of cases. But that's just my opinion.
The thing is that we call this method getMarkupId, but it only returns
the id you can find in the markup when you *don't* provide one
explicitly (and tell the component to write it's id). Even if you set
setOutputMarkupId(true), Wicket won't override the id in the markup,
which of course has the effect that any Javascript refering to the id
- like the datepicker does - does not work.
So we currently have the situation that if you set the id explictly,
stuff won't work anyway, and we have a method name that doesn't do
what the name hints (for it's current behavior it should be called
something like getGeneratedMarkupId).
Eelco
Re: getMarkupId doesn't return the id from the markup
Posted by Matej Knopp <ma...@gmail.com>.
I believe the current behavior is intentional. Igor seemed to feel
quite strongly about not using markup id specified in template. The
reason is that it's not unique and it behaves wrongly in repeaters or
when you put the component to page twice.
I'd actually prefer wicket to preserve specified attribute because it
can be handy in cauple of cases. But that's just my opinion.
-Matej
On 6/24/07, Eelco Hillenius <ee...@gmail.com> wrote:
> On 6/24/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > I think everyone ran into it at one time... I know I did. Last time I
> > think Igor threw some issues with repeaters into the mix, and then the
> > discussion went dead.
>
> For all I know, it worked in 2.0. I remember testing it specifically.
> I'm just surprised it doesn't work the same in 1.3. Did we forget to
> backport it maybe? The name of the method is a pretty clear indication
> what we had in mind with it, right?
>
> FYI, I tested all of the examples of wicket-examples, including the
> ajax and repeater tests, and they worked fine. The unit test that
> fails is RadioGroupTest#testFormProcessing but that is because the
> page tested isn't backed up by the proper markup (it uses
> org.apache.wicket.protocol.http.MockPage which doesn't have any of the
> components that are added in that test). So the test is faulty here.
>
> Eelco
>
Re: getMarkupId doesn't return the id from the markup
Posted by Eelco Hillenius <ee...@gmail.com>.
On 6/24/07, Martijn Dashorst <ma...@gmail.com> wrote:
> I think everyone ran into it at one time... I know I did. Last time I
> think Igor threw some issues with repeaters into the mix, and then the
> discussion went dead.
For all I know, it worked in 2.0. I remember testing it specifically.
I'm just surprised it doesn't work the same in 1.3. Did we forget to
backport it maybe? The name of the method is a pretty clear indication
what we had in mind with it, right?
FYI, I tested all of the examples of wicket-examples, including the
ajax and repeater tests, and they worked fine. The unit test that
fails is RadioGroupTest#testFormProcessing but that is because the
page tested isn't backed up by the proper markup (it uses
org.apache.wicket.protocol.http.MockPage which doesn't have any of the
components that are added in that test). So the test is faulty here.
Eelco
Re: getMarkupId doesn't return the id from the markup
Posted by Martijn Dashorst <ma...@gmail.com>.
I think everyone ran into it at one time... I know I did. Last time I
think Igor threw some issues with repeaters into the mix, and then the
discussion went dead.
Martijn
On 6/24/07, Eelco Hillenius <ee...@gmail.com> wrote:
> Yep, you read that right. I just found out that if you explicitly
> define an id attribute on your component, getMarkupId still just
> returns a generated one. This suprises me; I'm pretty sure we always
> agreed that if an explicit id is provided in the markup, that should
> be used. See the date picker in wicket-examples/forminput for example:
> it doesn't work now because the id is set to "dateProperty" but
> getMarkupId, which is used by the date picker, returns
> "dateProperty1".
>
> The fix is easy[1], but results in a failing unit test. Imho, that
> unit test is just too fragile, and I'm thinking about implementing a
> quick fix for it and submit this change. But I wanted to check here
> first in case I'm overlooking something.
>
> Eelco
>
> [1]
> Index: /Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java
> ===================================================================
> --- /Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java (revision
> 550266)
> +++ /Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/Component.java (working
> copy)
> @@ -1181,10 +1181,13 @@
>
> /**
> * Retrieves id by which this component is represented within the markup.
> + * This is either the id attribute if it is set explicitly in the markup, or
> + * a generated id.
> * <p>
> * The point of this function is to generate a unique id to make it easy to
> * locate this component in the generated markup for post-wicket processing
> - * such as javascript or an xslt transform.
> + * such as javascript or an xslt transform in case no explicit id was set
> + * yet.
> * <p>
> * Note: This method should only be called after the component or its parent
> * have been added to the page.
> @@ -1204,7 +1207,13 @@
> + "to find the page it is supposed to operate in before you can call "
> + "this method (Component#getMarkupId)");
> }
> - markupId = getId() + page.getAutoIndex();
> + // try to read from markup
> + markupId = getMarkupAttributes().getString("id");
> + if (markupId == null)
> + {
> + // if not in the markup, generate one
> + markupId = getId() + page.getAutoIndex();
> + }
> setMetaData(MARKUP_ID_KEY, markupId);
> }
> return markupId;
>
--
BREAKING NEWS: Wicket joins the Apache Software Foundation as Apache Wicket
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org