Oh, right, because that code isn't run before rendering. That also
prevents any kind of "by default" functionality since there's no way for
a component to know in advance that it's going to be an Ajax target. So,
I'll just file the RFE under "would be nice, needs creative
implementation."
Nathan
On Fri, 2006-03-17 at 09:43 -0800, Igor Vaynberg wrote:
> note: the component cannot be added via a target. it has to be there
> in the html when the page renders fully.
>
> -Igor
>
>
> On 3/17/06, Nathan Hamblen <[EMAIL PROTECTED]> wrote:
> I wouldn't suggest using a div, but spans are usually
> transparent to the
> layout. The only side effect I can see is if someone has a
> global style
> on spans (which would be pretty weird) or a selector on one
> like
> "div#myDiv span {color: red}" (still pretty weird, but I do it
> occasionally to skip defining a class or id on that span).
>
> It's a valid point though. I'll put in the RFE, but with the
> default
> behavior to be decided later. The magic could be triggered
> with a call
> like target.addWrappedComponent (c) or target.wrapComponent(c)
> or even
> target.addComponent(c.getWrapper()) so the structural markup
> change is
> explicit in the code.
>
> Nathan
>
> On Fri, 2006-03-17 at 18:01 +0100, 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]> 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]>
> 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
> >
> _______________________________________________
> > Wicket-user mailing list
> > [email protected]
> >
> 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
> _______________________________________________
> Wicket-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
