Help your brothers and sisters- Suggestions for improving this JSF example
Eventually I want to turn this small example into a walk through lesson/tutorial. Before I get to that point, I could really use the help of those that know what they are talking about to look over this example and provide suggestions on how to fix it up. Since I'm new to JSF/MyFaces, I'm sure there are some things that could be done better. This won't be the final look and feel of the site, it's just for working through the suggestions and improvements on this example.. http://www.reumann.net/reumann/jsf/jsf_employees/ You can click on the source code of most of the files from the left menu frame or you could download the source, war, whatever. Let's not put all those answers you gave to my noob questions go in vain:) -- Rick
Re: Help your brothers and sisters- Suggestions for improving this JSF example
Looks quite good, but one thing struck me... Your structure is very Struts like, which is not really needed. >extends AbstractViewController you wont need that in JSF unless you have something really important down there, which you have to reuse also you wont need to think in actions and forms (beans) like you do in struts, everything is a backing bean. A divided MVC approach is very viable, but you also can use a simplified combined model controller approach. Sun uses this strategy in their studio creator to enable a Visual basic like handling of the backend code. Rick Reumann wrote: Eventually I want to turn this small example into a walk through lesson/tutorial. Before I get to that point, I could really use the help of those that know what they are talking about to look over this example and provide suggestions on how to fix it up. Since I'm new to JSF/MyFaces, I'm sure there are some things that could be done better. This won't be the final look and feel of the site, it's just for working through the suggestions and improvements on this example.. http://www.reumann.net/reumann/jsf/jsf_employees/ You can click on the source code of most of the files from the left menu frame or you could download the source, war, whatever. Let's not put all those answers you gave to my noob questions go in vain:)
Re: Help your brothers and sisters- Suggestions for improving this JSF example
Ah I just googled, the AbstractViewController is Shale, that explains a lot ;-)... Craig if you read this, I thought that one point of JSF was to get rid of the Form-Action division of struts towards a more generalized approach? Does the AbstractViewController do something special in Shale or is it simply a class to ease the transition from Struts and enforce MVC? Werner Werner Punz wrote: Looks quite good, but one thing struck me... Your structure is very Struts like, which is not really needed. >extends AbstractViewController you wont need that in JSF unless you have something really important down there, which you have to reuse also you wont need to think in actions and forms (beans) like you do in struts, everything is a backing bean. A divided MVC approach is very viable, but you also can use a simplified combined model controller approach. Sun uses this strategy in their studio creator to enable a Visual basic like handling of the backend code. Rick Reumann wrote: Eventually I want to turn this small example into a walk through lesson/tutorial. Before I get to that point, I could really use the help of those that know what they are talking about to look over this example and provide suggestions on how to fix it up. Since I'm new to JSF/MyFaces, I'm sure there are some things that could be done better. This won't be the final look and feel of the site, it's just for working through the suggestions and improvements on this example.. http://www.reumann.net/reumann/jsf/jsf_employees/ You can click on the source code of most of the files from the left menu frame or you could download the source, war, whatever. Let's not put all those answers you gave to my noob questions go in vain:)
Re: Help your brothers and sisters- Suggestions for improving this JSF example
I believe it's needed in order to get the various methods called within the JSF life-cycle... such as the use of prerender. >From the Shale http://struts.apache.org/shale/features.html#view Each backing bean that implements ViewController will support a boolean property postback, which will be set to true if this view is the one that is processing a form submit previously rendered by the same page, or false if this view was newly navigated to. The property will be set before any of the lifecycle methods described below are called, so that application logic may perform conditional tasks based on this state. As part of the standard JavaServer Faces managed beans processing, any elements in the configuration file, that are nested inside the element for this backing bean, will also be processed when a new bean instance is created. You can use either literal values or value binding expressions to customize properties on your backing bean class. Fans of Dependency Injection will see that the managed beans facility provides support for such a framework, using Setter Injection as the mechanism for injecting dependencies. In addition, the following lifecycle events are called, by the framework, at certain points in the JavaServer Faces request processing lifecycle: init() - Called immediately after the view that this backing bean is associated with is created. (Technically, it happens when ViewManager.createView() is called.) For a postback, this happens during the Restore View phase of the request processing lifecycle, once it ha been determined which view should be restored. If your application navigates from one page to another, the init() method of the second page will be called as part of the NavigationHandler.handleNavigation() processing. Use this method to acquire resources that you will need, no matter whether this is a postback request, a rendering request, or both. preprocess() - Called after the Restore View phase has been completed, but before Apply Request Values phase starts, only for the view that will be processing the postback. Use this method to acquire resources (such as database connections) that you will need to process the postback. prerender() - Called immediately before the Render Response phase that actually causes the view to be rendered. This method will only be called for the view that is actually rendered (the current view if you are redisplaying, or the new view if you perform navigation). Use this method to acquire resources (such as database connections, or performing queries) that you will need if this view is the one to be rendered. NOTE - when portlet support is integrated, all of the portlets on the current page will receive this event. destroy() - If init() was ever called for a ViewController, then it is guaranteed that destroy() will be called as well. Use this method to release any resources acquired during an earlier event handler. On 9/15/05, Werner Punz <[EMAIL PROTECTED]> wrote: Ah I just googled, the AbstractViewController is Shale,that explains a lot ;-)...Craig if you read this, I thought that one point of JSF wasto get rid of the Form-Action division of struts towards a more generalized approach?Does the AbstractViewController do something special in Shale oris it simply a class to ease the transition from Strutsand enforce MVC?WernerWerner Punz wrote:> Looks quite good, > but one thing struck me...> Your structure is very Struts like, which is not really needed.>> >extends AbstractViewController>> you wont need that in JSF unless you have something really > important down there, which you have to reuse>> also you wont need to think in actions and forms (beans)> like you do in struts, everything is a backing bean.> A divided MVC approach is very viable, but > you also can use a simplified combined model controller approach.> Sun uses this strategy in their studio creator> to enable a Visual basic like handling of the backend code.>>> > Rick Reumann wrote:>>> Eventually I want to turn this small example into a walk through>> lesson/tutorial. Before I get to that point, I could really use the>> help of those that know what they are talking about to look over this >> example and provide suggestions on how to fix it up. Since I'm new to>> JSF/MyFaces, I'm sure there are some things that could be done better. This won't be the final look and f
Re: Help your brothers and sisters- Suggestions for improving this JSF example
On 9/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I believe it's needed in order to get the various methods called within the JSF life-cycle... such as the use of prerender. >From the Shale http://struts.apache.org/shale/features.html#view Rick's got it right ... AbstractViewController is primarily about enabling support for the extra lifecycle callbacks -- something that you'd do with annotations in Beehive or Struts Ti (and is essentially the strategy EJB3 is using to get rid of the requirement to implement specific platform APIs), where they declare JDK 1.5 as the base platform. Since I want Shale to work on JDK 1.4 I don't get to use that kind of capabiity. A couple of other notes: * Use of "extends AbstractViewController" or "implements ViewController" is entirely optional ... pure JSF backing beans will still work in a Shale based application, but you won't get the benefit of the extra lifecycle callbacks. * AbstractViewController also includes a host of other utility methods that can make programming a backing bean easier. Craig
