>>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.
I would use a java method from a submit button on the previous page. However there is no previous page in this circomstance. This page is the first page from a post of encrypted data from an external customer website. I'm still determining how I'm going to decrypt and run the first time setups when they post the data (right now I"m just getting the views and navigation working). Shale seemed to be well suited for that with the remoting. But since Shale doesn't seem to run right on JRun I'm going back to straight JSF and am unsure how to do this. Shawn -----Original Message----- From: [EMAIL PROTECTED] To: MyFaces Discussion Sent: 1/15/2006 11:25 PM Subject: Re: commandLink On 1/15/06, Garner, Shawn < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: 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 <http://struts.apache.org/struts-shale/features-view-controller.html> **************************************************************************** This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. ****************************************************************************
