You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martijn Dashorst <ma...@gmail.com> on 2007/03/26 11:48:00 UTC
Make getMarkupId() more intelligent in 1.x
The current implementation of getMarkupId() is pretty dumb. It doesn't
check if the user already has put a markup identifier in the page.
This does not play nicely with page based, custom written javascript.
I have several components of which I perfectly know that their id is
unique, and reference them from javascript in the markup. Now if I
attach a wicket ajax behavior to the component, I suddenly loose the
markup identifier because Wicket insists on generating a unique one
for me.
Can we at least check if the component already has a markup attribute
'id', and if so, leave it alone?
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org
Re: Make getMarkupId() more intelligent in 1.x
Posted by Martijn Dashorst <ma...@gmail.com>.
I also found the commit that disabled the getAttributes().getId()
check, it is from 2/13/06. But I fail to see a discussion on @dev
relating to this.
Martijn
On 3/26/07, Martijn Dashorst <ma...@gmail.com> wrote:
> I found one discussion:
>
> http://mail-archives.apache.org/mod_mbox/incubator-wicket-dev/200610.mbox/%3C23eb48360610060840i67431e8ey94d0bb7ad682dec9@mail.gmail.com%3E
>
> Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org
Re: Make getMarkupId() more intelligent in 1.x
Posted by Martijn Dashorst <ma...@gmail.com>.
I found one discussion:
http://mail-archives.apache.org/mod_mbox/incubator-wicket-dev/200610.mbox/%3C23eb48360610060840i67431e8ey94d0bb7ad682dec9@mail.gmail.com%3E
Martijn
On 3/26/07, Matej Knopp <ma...@gmail.com> wrote:
> Well, I do agree with you on this one. I wonder if there was other
> reason for why it is like it is right now. IIRC there was something
> with markup parsing but i'm not sure.
>
> -Matej
>
> On 3/26/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > On 3/26/07, Matej Knopp <ma...@gmail.com> wrote:
> > > IIRC the behavior used to be like that. But then someone decided that
> > > it is too fragile if you put your component into a repeater...
> >
> > But that is the choice of the user, not the framework. Now you make it
> > completely impossible to write stable javascript quickly, and you have
> > to resort to filtering your page with markup id's... Creating a lot of
> > extra work, just for a case that is completely manageable and
> > explainable.
> >
> > Martijn
> >
> > --
> > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > Join the wicket community at irc.freenode.net: ##wicket
> > Wicket 1.2.5 will keep your server alive. Download Wicket now!
> > http://wicketframework.org
> >
>
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org
Re: Make getMarkupId() more intelligent in 1.x
Posted by Igor Vaynberg <ig...@gmail.com>.
let me explain some of my thoughts on this.
once of the cons of not having the constructor refactor is that you cannot
call getmarkupid() at construction time because it is not yet known. my
original thought was to make the markupid be the id of the component
concatenated with some counter. that is why it is implemented the way it is
- it no longer depends on the full path of the component. of course at some
point i got off track and added getpage().getautoindex() for that counter
which of course broke the above. i just now noticed it, that needs to be
replaced with some circular static counter.
so we really have a choice here
support hardcoded ids or support the getmarkupid() at construction time to
make linking javascript components easier.
both will require a change to how the current system works.
-igor
On 3/26/07, Caleb Land <re...@gmail.com> wrote:
>
> I commented on this in 2.0, and it was fixed to support hardcoding ids:
>
>
> http://www.nabble.com/HTML-ids-in-2.0-SNAPHOT-are-being-generated-even-when-hardcoded-t2805481.html
>
> It certainly makes life easier to allow hardcoding ids.
>
> On 3/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > Was it 2.0 only?
> >
> > Eelco
> >
> > On 3/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > This surprises me too. I would have sworn we supported that, and it
> > > strikes me as a very useful feature.
> > >
> > > Eelco
> > >
> > >
> > > On 3/26/07, Matej Knopp <ma...@gmail.com> wrote:
> > > > Well, I do agree with you on this one. I wonder if there was other
> > > > reason for why it is like it is right now. IIRC there was something
> > > > with markup parsing but i'm not sure.
> > > >
> > > > -Matej
> > > >
> > > > On 3/26/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > > > > On 3/26/07, Matej Knopp <ma...@gmail.com> wrote:
> > > > > > IIRC the behavior used to be like that. But then someone decided
> > that
> > > > > > it is too fragile if you put your component into a repeater...
> > > > >
> > > > > But that is the choice of the user, not the framework. Now you
> make
> > it
> > > > > completely impossible to write stable javascript quickly, and you
> > have
> > > > > to resort to filtering your page with markup id's... Creating a
> lot
> > of
> > > > > extra work, just for a case that is completely manageable and
> > > > > explainable.
> > > > >
> > > > > Martijn
> > > > >
> > > > > --
> > > > > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > > > > Join the wicket community at irc.freenode.net: ##wicket
> > > > > Wicket 1.2.5 will keep your server alive. Download Wicket now!
> > > > > http://wicketframework.org
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Caleb Land
> (RedHatDude@gmail.com)
>
Re: Make getMarkupId() more intelligent in 1.x
Posted by Caleb Land <re...@gmail.com>.
I commented on this in 2.0, and it was fixed to support hardcoding ids:
http://www.nabble.com/HTML-ids-in-2.0-SNAPHOT-are-being-generated-even-when-hardcoded-t2805481.html
It certainly makes life easier to allow hardcoding ids.
On 3/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> Was it 2.0 only?
>
> Eelco
>
> On 3/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > This surprises me too. I would have sworn we supported that, and it
> > strikes me as a very useful feature.
> >
> > Eelco
> >
> >
> > On 3/26/07, Matej Knopp <ma...@gmail.com> wrote:
> > > Well, I do agree with you on this one. I wonder if there was other
> > > reason for why it is like it is right now. IIRC there was something
> > > with markup parsing but i'm not sure.
> > >
> > > -Matej
> > >
> > > On 3/26/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > > > On 3/26/07, Matej Knopp <ma...@gmail.com> wrote:
> > > > > IIRC the behavior used to be like that. But then someone decided
> that
> > > > > it is too fragile if you put your component into a repeater...
> > > >
> > > > But that is the choice of the user, not the framework. Now you make
> it
> > > > completely impossible to write stable javascript quickly, and you
> have
> > > > to resort to filtering your page with markup id's... Creating a lot
> of
> > > > extra work, just for a case that is completely manageable and
> > > > explainable.
> > > >
> > > > Martijn
> > > >
> > > > --
> > > > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > > > Join the wicket community at irc.freenode.net: ##wicket
> > > > Wicket 1.2.5 will keep your server alive. Download Wicket now!
> > > > http://wicketframework.org
> > > >
> > >
> >
>
--
Caleb Land
(RedHatDude@gmail.com)
Re: Make getMarkupId() more intelligent in 1.x
Posted by Eelco Hillenius <ee...@gmail.com>.
Was it 2.0 only?
Eelco
On 3/26/07, Eelco Hillenius <ee...@gmail.com> wrote:
> This surprises me too. I would have sworn we supported that, and it
> strikes me as a very useful feature.
>
> Eelco
>
>
> On 3/26/07, Matej Knopp <ma...@gmail.com> wrote:
> > Well, I do agree with you on this one. I wonder if there was other
> > reason for why it is like it is right now. IIRC there was something
> > with markup parsing but i'm not sure.
> >
> > -Matej
> >
> > On 3/26/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > > On 3/26/07, Matej Knopp <ma...@gmail.com> wrote:
> > > > IIRC the behavior used to be like that. But then someone decided that
> > > > it is too fragile if you put your component into a repeater...
> > >
> > > But that is the choice of the user, not the framework. Now you make it
> > > completely impossible to write stable javascript quickly, and you have
> > > to resort to filtering your page with markup id's... Creating a lot of
> > > extra work, just for a case that is completely manageable and
> > > explainable.
> > >
> > > Martijn
> > >
> > > --
> > > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > > Join the wicket community at irc.freenode.net: ##wicket
> > > Wicket 1.2.5 will keep your server alive. Download Wicket now!
> > > http://wicketframework.org
> > >
> >
>
Re: Make getMarkupId() more intelligent in 1.x
Posted by Eelco Hillenius <ee...@gmail.com>.
This surprises me too. I would have sworn we supported that, and it
strikes me as a very useful feature.
Eelco
On 3/26/07, Matej Knopp <ma...@gmail.com> wrote:
> Well, I do agree with you on this one. I wonder if there was other
> reason for why it is like it is right now. IIRC there was something
> with markup parsing but i'm not sure.
>
> -Matej
>
> On 3/26/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > On 3/26/07, Matej Knopp <ma...@gmail.com> wrote:
> > > IIRC the behavior used to be like that. But then someone decided that
> > > it is too fragile if you put your component into a repeater...
> >
> > But that is the choice of the user, not the framework. Now you make it
> > completely impossible to write stable javascript quickly, and you have
> > to resort to filtering your page with markup id's... Creating a lot of
> > extra work, just for a case that is completely manageable and
> > explainable.
> >
> > Martijn
> >
> > --
> > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > Join the wicket community at irc.freenode.net: ##wicket
> > Wicket 1.2.5 will keep your server alive. Download Wicket now!
> > http://wicketframework.org
> >
>
Re: Make getMarkupId() more intelligent in 1.x
Posted by Matej Knopp <ma...@gmail.com>.
Well, I do agree with you on this one. I wonder if there was other
reason for why it is like it is right now. IIRC there was something
with markup parsing but i'm not sure.
-Matej
On 3/26/07, Martijn Dashorst <ma...@gmail.com> wrote:
> On 3/26/07, Matej Knopp <ma...@gmail.com> wrote:
> > IIRC the behavior used to be like that. But then someone decided that
> > it is too fragile if you put your component into a repeater...
>
> But that is the choice of the user, not the framework. Now you make it
> completely impossible to write stable javascript quickly, and you have
> to resort to filtering your page with markup id's... Creating a lot of
> extra work, just for a case that is completely manageable and
> explainable.
>
> Martijn
>
> --
> Learn Wicket at ApacheCon Europe: http://apachecon.com
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.5 will keep your server alive. Download Wicket now!
> http://wicketframework.org
>
Re: Make getMarkupId() more intelligent in 1.x
Posted by Martijn Dashorst <ma...@gmail.com>.
On 3/26/07, Matej Knopp <ma...@gmail.com> wrote:
> IIRC the behavior used to be like that. But then someone decided that
> it is too fragile if you put your component into a repeater...
But that is the choice of the user, not the framework. Now you make it
completely impossible to write stable javascript quickly, and you have
to resort to filtering your page with markup id's... Creating a lot of
extra work, just for a case that is completely manageable and
explainable.
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org
Re: Make getMarkupId() more intelligent in 1.x
Posted by Matej Knopp <ma...@gmail.com>.
IIRC the behavior used to be like that. But then someone decided that
it is too fragile if you put your component into a repeater...
-Matej
On 3/26/07, Martijn Dashorst <ma...@gmail.com> wrote:
> The current implementation of getMarkupId() is pretty dumb. It doesn't
> check if the user already has put a markup identifier in the page.
>
> This does not play nicely with page based, custom written javascript.
> I have several components of which I perfectly know that their id is
> unique, and reference them from javascript in the markup. Now if I
> attach a wicket ajax behavior to the component, I suddenly loose the
> markup identifier because Wicket insists on generating a unique one
> for me.
>
> Can we at least check if the component already has a markup attribute
> 'id', and if so, leave it alone?
>
> Martijn
>
> --
> Learn Wicket at ApacheCon Europe: http://apachecon.com
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.5 will keep your server alive. Download Wicket now!
> http://wicketframework.org
>
Re: Make getMarkupId() more intelligent in 1.x
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Martijn Dashorst:
> Can we at least check if the component already has a markup
> attribute 'id', and if so, leave it alone?
+1
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Make getMarkupId() more intelligent in 1.x
Posted by Martijn Dashorst <ma...@gmail.com>.
On 3/26/07, Johan Compagner <jc...@gmail.com> wrote:
> Why cant you work with static id's when you do override getMarkupId?
>
> If you do that and then return:
>
> return getMarkupAttributes().get("id")
>
> then that should work fine
Then I have to create custom components for all components where I
attach this behavior to. That is intrusive and cumbersome.
For now I have subclassed AjaxFormComponentUpdatingBehavior and
overwritten everything Wicket does:
public abstract class IridiumAjaxFormComponentUpdatingBehavior extends
AjaxFormComponentUpdatingBehavior
{
public IridiumAjaxFormComponentUpdatingBehavior(String event)
{
super(event);
}
@Override
protected void onBind()
{
// expliciet super.onBind uitgezet, deze zet namelijk
standaard de output markup
// id op true. Dit clasht met eigen geschreven javascript in
de pagina. Gebruikers
// moeten zelf setOutputMarkupId aanzetten op de component.
if (!(getComponent() instanceof FormComponent))
{
throw new WicketRuntimeException("Behavior "
+ getClass().getName() + " can only be added to an
isntance of a FormComponent");
}
}
@Override
protected void onComponentTag(final ComponentTag tag)
{
// zorg ervoor dat we de markup id pushen als deze niet in de
markup gezet is.
String id = getComponent().getMarkupAttributes().getString("id");
if (id == null)
{
id = getComponent().getMarkupId();
tag.put("id", id);
}
super.onComponentTag(tag);
// only add the event handler when the component is enabled.
if (this.getComponent().isEnabled())
{
tag.put(getEvent(), getMyEventHandler(id));
}
}
/**
* @see wicket.ajax.AjaxEventBehavior#getEventHandler()
*/
private CharSequence getMyEventHandler(String id)
{
return getCallbackScript(new
AppendingStringBuffer("wicketAjaxPost('").append(
getCallbackUrl()).append(
"', wicketSerialize(document.getElementById('" + id +
"'))"), null, null);
}
}
Martijn
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org
Re: Make getMarkupId() more intelligent in 1.x
Posted by Johan Compagner <jc...@gmail.com>.
Why cant you work with static id's when you do override getMarkupId?
If you do that and then return:
return getMarkupAttributes().get("id")
then that should work fine
johan
On 3/26/07, Martijn Dashorst <ma...@gmail.com> wrote:
>
> I can see the reasons where the problems stem with repeaters, and that
> is a valid usecase. However, not all components are created inside
> repeaters, and writing javascript for a particular page is a common
> usecase as well. We need to find some middle ground here.
>
> The problem I have is that the current setup requires you to override
> getMarkupId() on all components that have a static id. However, this
> does not play nicely with behaviors that want to bind to the
> component, these set the flag to autogenerate (which is nice if you
> don't write your own javascript). Overriding the onBind on the
> behavior still doesn't work, because the onComponentTag calls
> getMarkupId(), which autogenerates when the MARKUP_ID_KEY meta data
> key is not set.
>
> It is impossible to set the metadata from the behavior, as
> MARKUP_ID_KEY is private, thus making it impossible for Wicket ajax to
> work with static markup id's.
>
> Martijn
>
> On 3/26/07, Martijn Dashorst <ma...@gmail.com> wrote:
> > The current implementation of getMarkupId() is pretty dumb. It doesn't
> > check if the user already has put a markup identifier in the page.
> >
> > This does not play nicely with page based, custom written javascript.
> > I have several components of which I perfectly know that their id is
> > unique, and reference them from javascript in the markup. Now if I
> > attach a wicket ajax behavior to the component, I suddenly loose the
> > markup identifier because Wicket insists on generating a unique one
> > for me.
> >
> > Can we at least check if the component already has a markup attribute
> > 'id', and if so, leave it alone?
> >
> > Martijn
> >
> > --
> > Learn Wicket at ApacheCon Europe: http://apachecon.com
> > Join the wicket community at irc.freenode.net: ##wicket
> > Wicket 1.2.5 will keep your server alive. Download Wicket now!
> > http://wicketframework.org
> >
>
>
> --
> Learn Wicket at ApacheCon Europe: http://apachecon.com
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.5 will keep your server alive. Download Wicket now!
> http://wicketframework.org
>
Re: Make getMarkupId() more intelligent in 1.x
Posted by Martijn Dashorst <ma...@gmail.com>.
I can see the reasons where the problems stem with repeaters, and that
is a valid usecase. However, not all components are created inside
repeaters, and writing javascript for a particular page is a common
usecase as well. We need to find some middle ground here.
The problem I have is that the current setup requires you to override
getMarkupId() on all components that have a static id. However, this
does not play nicely with behaviors that want to bind to the
component, these set the flag to autogenerate (which is nice if you
don't write your own javascript). Overriding the onBind on the
behavior still doesn't work, because the onComponentTag calls
getMarkupId(), which autogenerates when the MARKUP_ID_KEY meta data
key is not set.
It is impossible to set the metadata from the behavior, as
MARKUP_ID_KEY is private, thus making it impossible for Wicket ajax to
work with static markup id's.
Martijn
On 3/26/07, Martijn Dashorst <ma...@gmail.com> wrote:
> The current implementation of getMarkupId() is pretty dumb. It doesn't
> check if the user already has put a markup identifier in the page.
>
> This does not play nicely with page based, custom written javascript.
> I have several components of which I perfectly know that their id is
> unique, and reference them from javascript in the markup. Now if I
> attach a wicket ajax behavior to the component, I suddenly loose the
> markup identifier because Wicket insists on generating a unique one
> for me.
>
> Can we at least check if the component already has a markup attribute
> 'id', and if so, leave it alone?
>
> Martijn
>
> --
> Learn Wicket at ApacheCon Europe: http://apachecon.com
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.5 will keep your server alive. Download Wicket now!
> http://wicketframework.org
>
--
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org