Yes - this is what would be the best thing to do. Jacob is calling this something like context-sensitive processing or so.
regards, Martin On 11/16/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > One idea I had was that it would be nice if you could jump right to a > specific component without restoring the whole tree. In other words > you have async post for component with id of "foo" and you can grab > that directly out of a session map and perform the full lifecylce (but > just on that component.) > > If the component had children you would process them as well. Just > some random thoughts. I'd be interested in hearing other ideas. > (I'll do some research on the blogs and forums and see what others > have suggested.) > > sean > > On 11/16/05, Adam Winer <[EMAIL PROTECTED]> wrote: > > Martin, > > > > If you look at any postback, the areas that chew up time are: > > > > 1. Recreating the component tree > > 2. Going through the full lifecycle > > 3. Saving the component tree > > 4. Rendering the response > > > > If you want a hyper-efficient async, granular JSF response, you > > have to tackle each of these, both in terms of raw CPU and > > memory allocation (the latter more important when you look > > at multi-user scalability). > > > > Each of these has its own trickiness, and is harder than it > > seems at first. :) I really have to start blogging; each of > > these is like a separate article... > > > > So, yes, optimizing the lifecycle is a good start, but it's not > > a complete solution. > > > > -- Adam > > > > > > > > On 11/16/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > > Sounds promising to me! > > > > > > Even though from the perfomance tests that have been posted to the > > > mailing list a while ago, it doesn't look like going through the > > > lifecycle is the big problem - but rather restoring/saving the state > > > if you use client-side state saving. > > > > > > Adam, can you confirm that from your experience with ADF Faces? > > > > > > regards, > > > > > > Martin > > > > > > On 11/15/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > > Thanks. That confirms what I suspected (as far as being able to have > > > > a custom lifecycle using an init param.) > > > > > > > > So the suggestion would be in MyFaces to create a new custom lifecycle > > > > that included the default lifecycle and other optional steps. With > > > > the right URL or request parameter you would use the nonstandard > > > > phases (or jump around in a non-standard way). Otherwise you would > > > > follow the standard steps only. By default (without the special > > > > servlet context init parameter) you would get the default lifecycle. > > > > Would this work? > > > > > > > > sean > > > > > > > > On 11/15/05, Adam Winer <[EMAIL PROTECTED]> wrote: > > > > > You can configure FacesServlet to have a custom lifecycle using > > > > > a servlet context init parameter. But you can't, say, have two > > > > > FacesServlets each running a different lifecycle - one standard, > > > > > one trimmed for AJAX-ing. That's what JSF 1.2 adds, because > > > > > you can configure the lifecycle ID as a servlet config > > > > > parameter, not just a context init parameter. > > > > > > > > > > -- Adam > > > > > > > > > > On 11/15/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > > > > I think Craig was referring to the *current* ability to configure a > > > > > > custom lifecycle. From the javadocs it looks like this is > > > > > > supported. > > > > > > Can you clarify this some? > > > > > > > > > > > > sean > > > > > > > > > > > > On 11/15/05, Adam Winer <[EMAIL PROTECTED]> wrote: > > > > > > > On 11/15/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > For the type (a) components (where you need the component tree > > > > > > > > and > > > > > > > > model), Craig offered an interesting solution. He was toying > > > > > > > > with the > > > > > > > > idea of a custom lifecylce. I hadn't even realized this was > > > > > > > > possible > > > > > > > > but it sounds interesting. > > > > > > > > > > > > > > > > I posted something on struts-dev asking him for more details. > > > > > > > > Not > > > > > > > > sure if it belongs in MyFaces or Shale but it could be > > > > > > > > worthwhile. > > > > > > > > Perhaps we could modify FacesServlet so that the default > > > > > > > > lifecycle > > > > > > > > still applies but that you can also configure it with a > > > > > > > > specialized > > > > > > > > lifecycle. > > > > > > > > > > > > > > JSF 1.2 offers support for configuring multiple instances > > > > > > > of the FacesServlet with different lifecycles. Jacob's idea, > > > > > > > IIRC. (Craig hasn't been especially involved in the JSF > > > > > > > EG for quite awhile now.) > > > > > > > > > > > > > > -- Adam > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > http://www.irian.at > > > > > > Your JSF powerhouse - > > > JSF Consulting, Development and > > > Courses in English and German > > > > > > Professional Support for Apache MyFaces > > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
