If you are playing with Scala, and don't want to use the
instantiationListener because not all of your components are to be
ajaxified, you can then do:

object field1 extends TextField("field1") with AjaxReady
object field2 extends TextField("field2") with AjaxReady
object field3 extends TextField("field3") with AjaxReady

Or

var field1 = new TextField("field1) with AjaxReady

And here's the trait:

trait AjaxReady {
  self: MarkupContainer
  override def onInitialize() {
    super.onInitialize();
    setOutputMarkupId(true);
    setOutputMarkupPlaceholderTag(true);
  }
}

*Bruno Borges*
(21) 7672-7099
*www.brunoborges.com*



On Tue, Sep 20, 2011 at 1:23 PM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote:

> On Tue, Sep 20, 2011 at 12:53 AM, Korbinian Bachl - privat
> <korbinian.ba...@whiskyworld.de> wrote:
> > tetsu, ever tried to:
> >
> > - get an AjaxRequestTarget in a component that was not designed by ajax
> in
> > mind?
>
> AjaxRequestTarget.get()
>
> >
> > - tried to ajaxify a table-row in a dataTable component?
>
> new datatable() { new item() { return super.item().setoutputmarkupid(true);
> }
>
> > - tried ajax with repeaters?
>
> target.addcomponent(repeater.getparent());
>
> > - tried to interact with a modal window from inside in case you have a
> pure
> > non-ajax page within it?
>
> window.opener.<whatever modal func you need>
>
> > of even
> >
> > - got tired with the verbose .setOut... .setMark... true?
>
> use instantiation listener to enable it on everything
>
> > - wondered why my ajaxified component got more lines of code then the
> rest
> > of the page?
>
> no, i dont wonder about *your* ajaxified components :)
>
> -igor
>
>
> >
> >
> >
> >
> > Am 19.09.11 19:20, schrieb tetsuo:
> >>
> >> What is so broken about the current ajax in Wicket, that requires such
> >> rewrite?
> >>
> >>
> >>
> >> On Mon, Sep 19, 2011 at 1:11 PM, Igor
> >> Vaynberg<igor.vaynb...@gmail.com>wrote:
> >>
> >>> staged approach is fine, however its step 2 only that will cause
> >>> migration headaches, so this is just delaying the inevitable...
> >>>
> >>> -igor
> >>>
> >>>
> >>> On Mon, Sep 19, 2011 at 8:29 AM, Martin Grigorov<mgrigo...@apache.org>
> >>> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> In the recent ticket changes by Igor I mentioned few comments that
> >>>> Ajax will be re-written for Wicket.next (1.6, 3.0, 6.0 - whatever we
> >>>> call it).
> >>>>
> >>>> I want to share my experience with trying to re-vive Matej's work at
> >>>> [1],
> >>>
> >>> [2].
> >>>>
> >>>> The changes there are a bit drastic (maybe because the task hasn't
> >>>> been finished and the API breaks not cleaned) and knowing how Ajax
> >>>> heavy are the applications I've worked on I think it will be quite a
> >>>> work to migrate the apps from 1.5 to Wicket.next.
> >>>> I also tried to introduce wicket-ajax.jar with the new impl and keep
> >>>> the old one for transition but that wasn't easy too.
> >>>>
> >>>> So I want to propose a two step approach:
> >>>> 1) introduce some JavaScript library for Wicket.next and improve
> >>>> wicket-xyz.js files by using it
> >>>> 2) improve/reimplement Wicket Ajax for Wicket.next+1
> >>>>
> >>>>
> >>>> martin-g
> >>>>
> >>>> 1.
> >>>
> >>>
> >>>
> http://svn.apache.org/viewvc/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/
> >>>>
> >>>> 2. https://github.com/martin-g/wicket/tree/ajax2
> >>>>
> >>>
> >>
> >
>

Reply via email to