I am with Adam on this.  The JSF spec didn't consider AJAX, I'm sure because it was designed before Google started shaking things up, but now that it's hear and it appears to be hear to stay, the spec has to keep up. 

Using the PhaseListener like we are doing now, we decode before Apply Request Values phase.  Can we not just do the lifecycle on the affected components and bypass the rest of the lifecycle for the everything else?

Travis


On 11/15/05, Adam Winer <[EMAIL PROTECTED]> wrote:
On 11/14/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
> On 11/14/05, Adam Winer <[EMAIL PROTECTED]> wrote:
> > On 11/14/05, Sean Schofield < [EMAIL PROTECTED]> wrote:
> > > > Remember - the JSF framework was an outcome of seeing  the necessity
> > > > of componentization, state saving, etc. Why should that be any
> > > > different for AJAX components?
> > >
> > > Because it may be overkill in some instances.  I don't think an Ajax
> > > component that goes through the entire JSF lifecycle with every
> > > keystroke will scale very well.
> >
> > Certainly not - but that's just about what we can do today.
> > If this could scale, you've got more options.
>
> But for right now we need something other then complete JSF lifecycle
> for certain ajax components.  So what do we do about that in the here
> and now?

Fair enough - with JSF 1.1 (and JSF 1.2, for that matter), AJAX
postback back through the component tree is somewhere between
slower than ideal and molasses-slow.  But it's my opinion that
bypassing JSF is a workaround for limitations in JSF, not a
desirable path in and of itself.  And so its the job of the EG
and the JSF community (like MyFaces) to figure out how we
can fix JSF to make it better for processing AJAX requests.

-- Adam

Reply via email to