Ques 56. Is it possible to create the elements of a page(jsp) dynamically based on the results of a data base query, when using struts framework?
If you are talking about rendering a report, then sure. The Action iteracts with the business layer/data access objects to acquire the data, and then passes it to the presentation page bundled up as a JavaBean or a collection of JavaBeans. The JSP tags (and other systems) all use reflection, so you can use whatever JavaBean you like.
If you are talking about creating a dynamic data-entry form, then "not so much".
Struts 1.1 supports map-backed ActionForms, but the page still needs to know what input fields are going to be needed. For a truly dynamic input form, I guess the key would be some type of tag that took a map and then generated a column of input fields. (Wouldn't work for everyone, since a lot of forms must be designed just so.) For extra credit, the entry names could (optionally) be resource keys that were used to find the label text.
Text fields would be easy. Others would need some type of JavaBean with properties to tell the tag what to output. A bit of work, but obviously doable.
Of course, you'd probably want to validate the form before passing it back to the database. I imagine it's possible to use the validator in a non-declarative way, but I don't know anyone whose doing that. If you can do a db query to get the information about the form, I imagine you could also do a query to get the information about validations for the form. It would probably be easier to write your own engine than adopt the validator. (It's not really that complicated to do.)
People often ask about "dynamic input forms", but most of us just can't get our head around the use case. It's hard to understand what you do with the dynamic data when it comes back. Most application don't allow you to input or update an arbitrary (e.g. dynamic) set of fields.
Ques 57. Both JSF and Struts will continue to exist for a while. The Struts community is aware of JSF and is positioning itself to have strong support for JSF. See What about JSTL and JavaServer faces?
From a tools perspective, if you look at the support for JSF versus Struts in WebSphere Studio, the Struts tools are focused around the controller aspects. The Web Diagram editor helps build your Struts configuration and the wizards/editors build Struts artifacts. The JSF tools are geared towards building pages, and in essence, hide the JSF framework from you. Expect WebSphere Studio to support both frameworks for a while. As JSF matures, expect to see some of the controller aspects in JSF to become toolable.
Ques 58. Can you compare the advantages and disadvantages of JSF vs. Struts. Both now, and from what you may know of futures, how and if JSF will evolve into a superior technology vs. Struts? Include how WSAD plays into the comparison if it will help differentiate the two.
This is a very popular question these days. In general, JSF is still fairly new and will take time to fully mature. However, I see JSF being able to accomplish everything Struts can, plus more. Struts evolved out of necessity. It was created by developers who were tired of coding the same logic again and again. JSF emerged both from necessity and competition.
Struts has several benefits:
* Struts is a mature and proven framework. It has been around for a few years and deployed successfully on many projects. The WebSphere Application Server admin console is a Struts application.
* Struts uses the Front Controller and Command patterns and can handle sophisticated controller logic.
* In addition to the core controller function, it has many add-on benefits such as layouts with Tiles, declarative exception handling, and internationalization.
There are disadvantages:
* Struts is very JSP-centric and takes other frameworks to adapt to other view technologies.
* Although Struts has a rich tag library, it is still geared towards helping the controller aspect of development and does not give a sense that you are dealing with components on a page. Therefore, it is not as toolable from a view perspective.
* Struts requires knowledge of Java?. Its goal was to aid Java developers, but not to hide Java. It does not hide details of the Java language to Web developers that well.
* ActionForms are linked programmatically to the Struts framework. Therefore, to decouple the model, you need to write transfer code or use utilities to move data from Action Forms to the Model on input.
JSF is an evolution of a few frameworks, including Struts. The creator of Struts, Craig McClanahan, is one of the JSF specification leads. Therefore, it is not by accident to see some overlap between Struts and JSF. However, one of JSF's major goals is to help J2EE Web applications to be easily developed using RAD tools. As such, it introduces a rich component model. JSF has several advantages:
* JSF is a specification from SunŽ and will be included in future versions of the J2EE specification. All major vendors are pledging strong support for JSF.
* JSF uses the Page Controller Pattern and therefore aids in Page rich applications. Components can respond to event from components on a page.
* JSF has a well-defined request lifecycle allowing for plugability at different levels.
* One powerful example of plugability is building your own render toolkit. The ability to separate the rendering portion from the controller portion of the framework allows for wonderful opportunities of extensibility. Component providers can write their own toolkits to render different markup languages, such as XML or WML. In addition, the render toolkit is not tied to JSP.
* Because JSF has a rich component model, it favors a RAD style of development. I can now build my Web pages using drag and drop technology. In addition, JSF gives me a way to link visual components to back model components without breaking the layering.
JSF has disadvantages:
* JSF is still quite new and evolving. It will take some time to see successful deployments and wide usage. In addition, as vendors write components, they may not do everything you want them to.
* JSF by hand is not easier than Struts. Its goal was more oriented to RAD. Those who prefer to do things by hand (for example, the vi type guy who does not like IDEs) may find Struts easier to develop.
* Struts navigation may be a bit more flexible and adhere to more complex controller logic.
Ques 59. Multiple Sub-applications
One of the shortcomings in Struts 1.0 is manageability of the configuration file (commonly known as struts-config.xml) when the development of the application involves a sizable team. This problem arises because a Struts-based application must run under one controller servlet, the ActionServlet, and the ActionServlet can use only one struts-config.xml. It is not an issue when the project is relatively small and the team consists of a couple of developers; however, when the project size becomes significant and the project involves a large number of developers, maintaining all the mapping information in a single file becomes increasingly problematic.
Struts 1.1 solves this problem nicely by introducing multiple sub-applications. In Struts 1.1, each sub-application has its own struts-config.xml file. A large Struts-based application can thus be easily partitioned into largely independent modules, i.e. sub-applications, and each sub-team can maintain their struts-config.xml independently.
The sub-application scheme is a natural extension of the servlet context mapping scheme of the URI paths used by servlet containers. According to the Servlet standard, when the servlet container receives a request with a URL, the servlet container will try to match the prefix of the URI path to a deployed web-application in the container. What Struts 1.1 does is it maps the second prefix of the path to a sub-application. In effect, this prefix mapping scheme creates another level of namespace for each sub-application. For example, for the URI,
http://some-host.com/myApp/module2/editSubscription.do
/myApp is the context path for a web-application called "myApp" and /module2 is the sub-app prefix for a Struts sub-application called "module2".
Ques 60. DynaBean and BeanUtils
Another major complaint usually heard amongst Struts 1.0 users is the extensive effort involved in writing the FormBean (a.k.a. ActionForm) classes.
Struts provides two-way automatic population between HTML forms and Java objects, the FormBeans. To take advantage of this however, you have to write one FormBean per HTML form. (In some use cases, a FormBean can actually be shared between multiple HTML forms. But those are specific cases.) Struts' FormBean standard follows faithfully the verbose JavaBean standard to define and access properties. Besides, to encourage a maintainable architecture, Struts enforces a pattern such that it is very difficult to 'reuse' a model-layer object (e.g. a ValueObject from the EJB tier) as a FormBean. Combining all these factors, a developer has to spend a significant amount of time to write tedious getters/setters for all the FormBean classes.
Struts 1.1 offers an alternative, Dynamic ActionForms, which are based on DynaBeans. Simply put, DynaBeans are type-safe name-value pairs (think HashMaps) but behave like normal JavaBeans with the help of the BeanUtils library. (Both the DynaBeans and the BeanUtils library were found to be useful and generic enough that they have been 'promoted' into Jakarta's Commons project.) With Dynamic ActionForms, instead of coding the tedious setters/getters, developers can declare the required properties in the struts-config.xml files. Struts will instantiate and initialize Dynamic ActionForm objects with the appropriate metadata. From then onwards, The Dynamic ActionForm instance is treated as if it is an ordinary JavaBean by Struts and the BeanUtils library.
