Operating System: All
Umbrella issue for state management revision in JSF 2.0.
Move all to 1.2
Prepare to delete "spec" subcomponent.
Fix checked in.
Add view expiry issue
>>>>> On Wed, 19 Mar 2008, David M Johnson said:
DJ> I think the goal should be to make JSF applications RESTful by
DJ> default, with proper use of GET and POST, i.e. only use POST when
DJ> application data is changing, not for component state. Another goal
DJ> should be clean, book-markable URLs that only carry path-info and
DJ> parameters needed by the application logic.
DJ> That's easy and the default situation with Rail, Grails, Struts, etc.
DJ> How hard would it be to redesign JSF along those lines? Would it
DJ> require EJB2 -> EJB3 level changes to JSF?
What is the granularity of state management?
attribute, component, sub-tree, other?
For saving, are we using push or pull?
For restoring, are we using push or pull?
MM> Shouldn't we synchronize on whatever scope we invent that is the
MM> view-scope? Only one request may access the view (or its state,
MM> depending on how this is gonna change in implementation after we're
MM> through with 2.0) at a certain point of time, that's it.
AW> That's by far the simplest approach. This does cause major
AW> UI issues if you rely on it for AJAX requests, since one
AW> slow request (server/DB/network) blocks all subsequent requests.
IS> And now I think we should count separately Ajax vs regular requests.
AW> In terms of which? View scope, or state saving?
AW> If the former, I don't see why, if the latter,
AW> absolutely, in fact see:
AW> PPR + State Management: reuse state tokens while PPRing to avoid flushing
AW> It's a big win for state longevity (or for memory use,
AW> if you use it to crank down the size of the state cache).
>>>>> On Fri, 27 Jul 2007 15:47:00 -0700, Igor Shabalov <ishabalov@EXADEL.COM> said:
IS> This is just another reason why we need to separate State from Component
IS> and threat it more granularly. With granular State we will have:
IS> 1. Nice separation between stateless (and there fore thread safe)
IS> portion of component, Request scope (tread local) and again thread safe
IS> state and - finally View Scope portion that must be synchronized.
IS> 2. Locks/synchronization can be used if only required, for example view
IS> can be locked only if some component need to save state till the end of
IS> request, so if some parallel request with partial update of other
IS> portion of same page does not have any statefull part - it will be not
IS> Of course I'm not talking about Data Model concurrency - it's a separate