Hi,
102 release does.
1.2.2 (for JSF 1.2) as well
-M
On 8/22/07, Francisco Passos <[EMAIL PROTECTED]> wrote:
> Excellent!
>
> Will 1.0.3 include real AJAX like 1.2.1? Or AJAX is not intented to be a
> part of the JSF 1.1 branch?
>
>
> On 8/22/07, Andrew Robinson < [EMAIL PROTECTED]> wrote:
> > Sounds great Adam
> >
> > Any idea on the time line of a 1.0.3 release?
> >
> > On 8/21/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > > Just added:
> > >
> > > - PPR should be a good bit more efficient, as most input + output
> > > components will not render anything unless they are being PPR'd,
> > > and tables, trees, treeTables, navigationPanes and trains
> > > will be entirely skipped unless they or one of their contents
> > > is being PPR'd.
> > >
> > > Until now, PPR rendered everything and a ResponseWriter trimmed
> > > out what shouldn't be rendered. That's still the case in part, but
> > > we can now entirely skip some branches of the UIComponent hierarchy.
> > > (The client validation code had to be somewhat overhauled to make
> > > this possible.)
> > >
> > > - A new "addDomReplaceListener()" method provides notification
> > > of DOM changes from PPR. A trivial example is:
> > >
> > > function notePpr(oldDom, newDom)
> > > {
> > > console.log("old", oldDom);
> > > console.log("new", newDom);
> > > }
> > >
> > > TrPage.getInstance().addDomReplaceListener(notePpr);
> > >
> > > ... which logs to Firebug any DOM elements that have been
> > > added or removed.
> > >
> > > Feedback we need: currently, this API is called *after*
> > > the DOM replacement has happened, and gives you no
> > > way of preventing or overriding the DOM replacement. I'm
> > > far from convinced that's the right choice: it might be better
> > > to run this before replacement and allow this function to "return
> > > false;", in which case no replacement would happen.
> > >
> > > Cheers,
> > > Adam Winer
> > >
> >
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
