You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Adam Winer <aw...@gmail.com> on 2007/08/22 07:38:50 UTC
[TRINIDAD] 1.0.3: new PPR features
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
Re: [TRINIDAD] 1.0.3: new PPR features
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi,
> 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.
Nice feature, this API.
running it up front the replacement, to skip (for instance) might be
the right choice.
.M
>
> Cheers,
> Adam Winer
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [TRINIDAD] 1.0.3: new PPR features
Posted by Simon Lessard <si...@gmail.com>.
Hello Francisco,
Release 1.0.2 includes real AJAX already. For now, new features are always
mirrored in both JSF 1.1 and 1.2, matching with the last release number
digit. i.e. features in 1.0.2 can be also found in 1.2.2.
Regards,
~ Simon
On 8/22/07, Francisco Passos <fr...@gmail.com> 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 < andrew.rw.robinson@gmail.com> wrote:
> >
> > Sounds great Adam
> >
> > Any idea on the time line of a 1.0.3 release?
> >
> > On 8/21/07, Adam Winer <aw...@gmail.com> 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
> > >
> >
>
>
Re: [TRINIDAD] 1.0.3: new PPR features
Posted by Matthias Wessendorf <ma...@apache.org>.
Hi,
102 release does.
1.2.2 (for JSF 1.2) as well
-M
On 8/22/07, Francisco Passos <fr...@gmail.com> 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 < andrew.rw.robinson@gmail.com> wrote:
> > Sounds great Adam
> >
> > Any idea on the time line of a 1.0.3 release?
> >
> > On 8/21/07, Adam Winer <aw...@gmail.com> 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
Re: [TRINIDAD] 1.0.3: new PPR features
Posted by Francisco Passos <fr...@gmail.com>.
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 <an...@gmail.com> wrote:
>
> Sounds great Adam
>
> Any idea on the time line of a 1.0.3 release?
>
> On 8/21/07, Adam Winer <aw...@gmail.com> 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
> >
>
Re: [TRINIDAD] 1.0.3: new PPR features
Posted by Matthias Wessendorf <ma...@apache.org>.
currently we run the 1.2.2
some more days/weeks after 1.2.2, to test 1.0.3 I think..
On 8/22/07, Andrew Robinson <an...@gmail.com> wrote:
> Sounds great Adam
>
> Any idea on the time line of a 1.0.3 release?
>
> On 8/21/07, Adam Winer <aw...@gmail.com> 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
Re: [TRINIDAD] 1.0.3: new PPR features
Posted by Andrew Robinson <an...@gmail.com>.
Sounds great Adam
Any idea on the time line of a 1.0.3 release?
On 8/21/07, Adam Winer <aw...@gmail.com> 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
>