but most of the time the ListView is the component that needs to be wrapped.
What are the others ?

So then it is only when you have listviews in listviews.

But how would you auto wrap a listivew? What would you do if you had this:

<table>
<tr wicket:id="repeater">
.. some td with components
</tr>
</table>

would you then make it:

<table>
<span id="unique">
<tr wicket:id="repeater">
.. some td with components
</tr>
...
</span>
</table>

is that legal xhtml?

johan

On 3/17/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
indeed we do, but when you use repeaters/panels it is hard to have a hardcoded id that is unique :)

-Igor



On 3/17/06, Johan Compagner < [EMAIL PROTECTED]> wrote:
didn't we now have a feature that we don't have to add the component on the wicket side?
so you can just do:

<span id="wrapper_53">
   ...
</span>

and in the rerender component you just give the id it should replace and the real component
I thought this was in by request of martijn.

johan



On 3/17/06, Nathan Hamblen <[EMAIL PROTECTED] > wrote:
But if the magic is not happening without a user asking for it (since it
turns out that's not possible anyway) are you guys still subtracting? I
mean, it's a lot easier to write stylesheets that don't affect spans
than it is to...

<span wicket:id="wrapper_53">
....
</span>

WebMarkupContainer wrapper53 =add(new
        WebMarkupContainer("wrapper_53");
add(wrapper53.setMarkupId(true));
warpper53.add(....

In a page with very much Ajax in it, typing "WebMarkupContainer" starts
to get old fast. And it's error prone. I forget to to add() that
uninteresting container to the page almost every time.

I'm just suggesting that we let people abbreviate all that to
component.useAjaxContainer (true) or something of that nature, at their
own risk of breaking an overzealous css rule.

Nathan

On Fri, 2006-03-17 at 20:07 +0100, Matej Knopp wrote:
> -1 As well. Even span can break layout very easily.
>
> And one more question. What's wrong with forms? List views can't be
> replaced without containers, that's fine, but what's the problem with forms?
>
> -Matej
>
> Martijn Dashorst wrote:
> > I'm -1 on this one.
> >
> > This will break layout for web pages. Most if not all web designers take
> > special care to layout things, and magically adding a span/div to the
> > markup is against the previewability principle.
> >
> > Martijn
> >
> >
> > On 3/17/06, *Igor Vaynberg* <[EMAIL PROTECTED]
> > <mailto: [EMAIL PROTECTED]>> wrote:
> >
> >     it might be possible to do that, but it will require some changes to
> >     the api and i dont have time to look into this right now. please add
> >     an rfe. also please add these notes:
> >
> >     if we make behaviors be able to output markup before and after the
> >     component it is attached to renders then most ajax behaviors can
> >     output a simple <span class="wicket-ajax-span" id="uniqueid"> around
> >     the component they are attached to making it very easy to update any
> >     component w/out having to add an extra webmarkup container around it
> >     by rerendering the entire component and not just its body.
> >
> >     -Igor
> >
> >
> >
> >     On 3/17/06, * Nathan Hamblen* < [EMAIL PROTECTED]
> >     <mailto:[EMAIL PROTECTED]>> wrote:
> >
> >         Another one is, probably, that certain components (ListViews,
> >         Forms...)
> >         can't be set as Ajax targets. And as for those components that
> >         can be
> >         targeted, their own attributes (like a TextArea's value) aren't
> >         updated,
> >         only their body contents. So in fact you have to wrap almost
> >         anything
> >         you want to target in a container span or div.
> >
> >         This was unexpected for me, though I can see why it works that
> >         way. Now
> >         I just add these containers without thinking about it. But couldn't
> >         Wicket be doing that grunt work for me? It could just wrap every
> >         Ajax
> >         target with a made-up span by default, non-destructively as far
> >         as I can
> >         tell. That would also save users the trouble of remembering to
> >         setOutputMarkupId(true).
> >
> >         note: I think the implementation is already super-great; this is
> >         just an
> >         idea.
> >
> >         Nathan
> >
> >
> >         On Fri, 2006-03-17 at 03:37 -0800, Ayodeji Aladejebi wrote:
> >         >  To all Wicket Users that may be having _javascript_ errors
> >         indicating
> >         >  'Object Expected' from browser most times..please after you
> >         have done
> >         >  what you are expected to do..perform this simple check:
> >         >
> >         >  Look into your Web.xml and confirm that the context reference
> >         of the
> >         >  WicketServlet is /app/* and not /app
> >         >
> >         >  this gave me a lot of problems with all Ajax functionality in
> >         Wicket
> >         >  so dont fall into my former pit :)
> >         >
> >         >  Thanks
> >
> >
> >
> >
> >         -------------------------------------------------------
> >         This SF.Net email is sponsored by xPML, a groundbreaking
> >         scripting language
> >         that extends applications into web and mobile media. Attend the
> >         live webcast
> >         and join the prime developer group breaking into this new coding
> >         territory!
> >         http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> >         < http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 >
> >         _______________________________________________
> >         Wicket-user mailing list
> >         Wicket-user@lists.sourceforge.net
> >         <mailto:Wicket-user@lists.sourceforge.net>
> >         https://lists.sourceforge.net/lists/listinfo/wicket-user
> >         <https://lists.sourceforge.net/lists/listinfo/wicket-user >
> >
> >
> >
> >
> >
> > --
> > Wicket 1.2 - Write AJAX applications without writing _javascript_
> > http://wicketframework.org
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



Reply via email to