You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Adam Winer <aw...@gmail.com> on 2006/09/22 23:09:16 UTC
Suggested LifecycleRenderer improvement
Trinidad has a LifecycleRenderer, which is an interface that can be
implemented by a Renderer to let the renderer take over handling
processDecodes(), processUpdates(), processValidators(). This
is a big improvement if you have a smart DHTML table that lets
you scroll around the whole content arbitrarily, but you don't want to
actually decode huge numbers of rows.
But it's kind of a pain when you only sometimes want to hook in;
it'd be very handy to let these APIs return true/false, where
false means "I didn't handle it, just do the default".
Any objections?
-- Adam
Re: Suggested LifecycleRenderer improvement
Posted by Simon Lessard <si...@gmail.com>.
+1
On 9/23/06, Matthias Wessendorf <ma...@apache.org> wrote:
>
> interesting!
>
> +1
>
> On 9/23/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> > +1
> > will help solve problems with trees,tables and other stamping
> components,
> > since now the same logic that
> > walks the tree on encode can do the same walk for decode,validate and
> > update.
> >
> > --arjuna
> >
> > On 9/22/06, Gabrielle Crawford <ga...@oracle.com> wrote:
> > >
> > >
> > >
> > > Adam Winer wrote:
> > >
> > > > Trinidad has a LifecycleRenderer, which is an interface that can be
> > > > implemented by a Renderer to let the renderer take over handling
> > > > processDecodes(), processUpdates(), processValidators(). This
> > > > is a big improvement if you have a smart DHTML table that lets
> > > > you scroll around the whole content arbitrarily, but you don't want
> to
> > > > actually decode huge numbers of rows.
> > > >
> > > > But it's kind of a pain when you only sometimes want to hook in;
> > > > it'd be very handy to let these APIs return true/false, where
> > > > false means "I didn't handle it, just do the default".
> > > >
> > > > Any objections?
> > >
> > > Sounds mighty fine. +1.
> > >
> > > Thanks,
> > >
> > > Gabrielle
> > >
> > > >
> > > > -- Adam
> > > >
> > >
> > >
> >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
Re: Suggested LifecycleRenderer improvement
Posted by Matthias Wessendorf <ma...@apache.org>.
interesting!
+1
On 9/23/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> +1
> will help solve problems with trees,tables and other stamping components,
> since now the same logic that
> walks the tree on encode can do the same walk for decode,validate and
> update.
>
> --arjuna
>
> On 9/22/06, Gabrielle Crawford <ga...@oracle.com> wrote:
> >
> >
> >
> > Adam Winer wrote:
> >
> > > Trinidad has a LifecycleRenderer, which is an interface that can be
> > > implemented by a Renderer to let the renderer take over handling
> > > processDecodes(), processUpdates(), processValidators(). This
> > > is a big improvement if you have a smart DHTML table that lets
> > > you scroll around the whole content arbitrarily, but you don't want to
> > > actually decode huge numbers of rows.
> > >
> > > But it's kind of a pain when you only sometimes want to hook in;
> > > it'd be very handy to let these APIs return true/false, where
> > > false means "I didn't handle it, just do the default".
> > >
> > > Any objections?
> >
> > Sounds mighty fine. +1.
> >
> > Thanks,
> >
> > Gabrielle
> >
> > >
> > > -- Adam
> > >
> >
> >
>
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Suggested LifecycleRenderer improvement
Posted by Arjuna Wijeyekoon <ar...@gmail.com>.
+1
will help solve problems with trees,tables and other stamping components,
since now the same logic that
walks the tree on encode can do the same walk for decode,validate and
update.
--arjuna
On 9/22/06, Gabrielle Crawford <ga...@oracle.com> wrote:
>
>
>
> Adam Winer wrote:
>
> > Trinidad has a LifecycleRenderer, which is an interface that can be
> > implemented by a Renderer to let the renderer take over handling
> > processDecodes(), processUpdates(), processValidators(). This
> > is a big improvement if you have a smart DHTML table that lets
> > you scroll around the whole content arbitrarily, but you don't want to
> > actually decode huge numbers of rows.
> >
> > But it's kind of a pain when you only sometimes want to hook in;
> > it'd be very handy to let these APIs return true/false, where
> > false means "I didn't handle it, just do the default".
> >
> > Any objections?
>
> Sounds mighty fine. +1.
>
> Thanks,
>
> Gabrielle
>
> >
> > -- Adam
> >
>
>
Re: Suggested LifecycleRenderer improvement
Posted by Gabrielle Crawford <ga...@oracle.com>.
Adam Winer wrote:
> Trinidad has a LifecycleRenderer, which is an interface that can be
> implemented by a Renderer to let the renderer take over handling
> processDecodes(), processUpdates(), processValidators(). This
> is a big improvement if you have a smart DHTML table that lets
> you scroll around the whole content arbitrarily, but you don't want to
> actually decode huge numbers of rows.
>
> But it's kind of a pain when you only sometimes want to hook in;
> it'd be very handy to let these APIs return true/false, where
> false means "I didn't handle it, just do the default".
>
> Any objections?
Sounds mighty fine. +1.
Thanks,
Gabrielle
>
> -- Adam
>