On 1/15/06, Garner, Shawn <[EMAIL PROTECTED]> wrote:
Page scope is a JSP-only thing, and it would not be appropriate for a JSF component to be required to depend on that ... it would seriously restrict the ability to use non-JSP view technologies for JSF components (for example, the Clay module in Shale, or the Facelets project at Java.Net).
JSTL can deal just fine with request, session, and application scope. Indeed, JSTL and JSP expressions do the same sort of search for existing beans that JSF expressions do.
The reason that MVC-ish webapp frameworks (like Struts and WebWork and Spring MVC and Tapestry and ...) became popular in the first place is the widespread dislike for mixing Java code in JSP pages by the use of scriptlets. While there are limited circumstances where it might actually makes sense, it tempts developers into mixing business logic in their presentation logic -- and makes it much harder to maintain and update the application later.
The point of my comment was that your business logic (say, the event handler for a submit button) should be setting up the variables that the next view will require. If you prefer a style where the setup code belongs to the view, you'll like the ViewController API in Shale[1], where you can use the prerender() method of the backing bean associated with the new view for this sort of thing. (If you are familiar with Tiles, this same role is played by the "Controller" API.) But the key issue is that you should treat the JSP page as a pure view artifact, not mix view and model concepts.
Doesn't request scoping of JSF kind of go against the standard page scoping
of JSTL.
Page scope is a JSP-only thing, and it would not be appropriate for a JSF component to be required to depend on that ... it would seriously restrict the ability to use non-JSP view technologies for JSF components (for example, the Clay module in Shale, or the Facelets project at Java.Net).
JSTL can deal just fine with request, session, and application scope. Indeed, JSTL and JSP expressions do the same sort of search for existing beans that JSF expressions do.
What do you mean this should be done in Java?
The reason that MVC-ish webapp frameworks (like Struts and WebWork and Spring MVC and Tapestry and ...) became popular in the first place is the widespread dislike for mixing Java code in JSP pages by the use of scriptlets. While there are limited circumstances where it might actually makes sense, it tempts developers into mixing business logic in their presentation logic -- and makes it much harder to maintain and update the application later.
The point of my comment was that your business logic (say, the event handler for a submit button) should be setting up the variables that the next view will require. If you prefer a style where the setup code belongs to the view, you'll like the ViewController API in Shale[1], where you can use the prerender() method of the backing bean associated with the new view for this sort of thing. (If you are familiar with Tiles, this same role is played by the "Controller" API.) But the key issue is that you should treat the JSP page as a pure view artifact, not mix view and model concepts.
Shawn
Craig
[1] http://struts.apache.org/struts-shale/features-view-controller.html
