Good point :-) Overall, I think for JSF 2.0, we maybe need to move JSF's controller to pure events-- why are ActionEvents used, but not UpdateEvents?
Then JSF can work as a controller for both model 1 or model 2 such that these events can come from UIComponents, or some other 'view' archetype, such as a config file (struts) or annotations (stripes), etc. So JSF's component model becomes one client of many for coordinating stateful interactions with all of the bells and whistles. To the end developer then, we have a common controller that truley is view agnostic and purely event driven. Use rich UIComponents for some pages, but go model 2 for other types of requests, but all types can be handled by one controller. -- Jacob >[EMAIL PROTECTED] schrieb: >> From experimenting with going stateless in JSF, and Adam's work on state >saving deltas, we allow the view to be created up front with Facelets-- from >file-- fresh on a request. So even without any viewstate passed, you >basically get a snapshot of the same, declarative, tree for processing >updates/validators/actions/etc. >> >Yes, but - if possible - we should not make facelets a requirement. Dont >get me wrong, facelets are great for sure, but Martin pointed out a way >to do the same with jsp (eventually) by early "servlet.forward" to the >jsp page and get access to the view then. (with discard the output - if >any - which should not be if the user is going the mini-controller way) >Later the default servlet.forward take place - if still required :-) > >This "double forward" is only necessary for get requests. > >Not as nice as facelets, but avoids this dependency if the user do not >use them. >--- >Mario >
