From 642549a1e7605eee20480c5600ce0eae742f005f Mon Sep 17 00:00:00 2001 From: Sam Brannen Date: Sat, 24 Oct 2009 17:04:08 +0000 Subject: [PATCH] Polishing the web integration sections of the reference manual. --- .../src/web-integration.xml | 57 ++++++++++--------- 1 file changed, 29 insertions(+), 28 deletions(-) diff --git a/spring-framework-reference/src/web-integration.xml b/spring-framework-reference/src/web-integration.xml index bb4d39dd11..f03be4da32 100644 --- a/spring-framework-reference/src/web-integration.xml +++ b/spring-framework-reference/src/web-integration.xml @@ -39,7 +39,7 @@ details of integrating your favorite web framework with Spring. One thing that is often commented upon by developers coming to Java from other languages is the seeming super-abundance of web frameworks available in - Java... there are indeed a great number of web frameworks in the Java + Java. There are indeed a great number of web frameworks in the Java space; in fact there are far too many to cover with any semblance of detail in a single chapter. This chapter thus picks four of the more popular web frameworks in Java, starting with the Spring configuration @@ -63,15 +63,15 @@ Common configuration Before diving into the integration specifics of each supported web - framework, let us first take a look at the Spring configuration that + framework, let us first take a look at the Spring configuration that is not specific to any one web framework. (This section is equally applicable to Spring's own web framework, Spring MVC.) One of the concepts (for want of a better word) espoused by (Spring's) lightweight application model is that of a layered architecture. Remember that in a 'classic' layered architecture, the web - layer is but one of many layers... it serves as one of the entry points - into a server side application, and it delegates to service objects + layer is but one of many layers; it serves as one of the entry points + into a server side application and it delegates to service objects (facades) defined in a service layer to satisfy business specific (and presentation-technology agnostic) use cases. In Spring, these service objects, any other business-specific objects, data access objects, etc. @@ -82,7 +82,7 @@ a Spring container (a WebApplicationContext) that contains all of the 'business beans' in one's application. - Onto specifics... all that one need do is to declare a On to specifics: all that one need do is to declare a ContextLoaderListener in the standard Java EE servlet web.xml file of one's web application, and add a contextConfigLocation @@ -117,7 +117,7 @@ to load. Once the context files are loaded, Spring creates a WebApplicationContext object based on the bean definitions and stores it in the - ServletContext of one's web application. + ServletContext of the web application. All Java web frameworks are built on top of the Servlet API, and so one can use the following code snippet to get access to this 'business @@ -141,7 +141,7 @@ Once you have a reference to the WebApplicationContext, you can retrieve beans by - their name or type. Most developers retrieve beans by name, then cast them + their name or type. Most developers retrieve beans by name and then cast them to one of their implemented interfaces. Fortunately, most of the frameworks in this section have simpler @@ -209,7 +209,7 @@ The DelegatingVariableResolver will first delegate value lookups to the default resolver of the underlying JSF - implementation, and then to Spring's 'business context' + implementation and then to Spring's 'business context' WebApplicationContext. This allows one to easily inject dependencies into one's JSF-managed beans. @@ -235,7 +235,7 @@ SpringBeanVariableResolver is a variant of DelegatingVariableResolver. It delegates to the Spring's 'business context' WebApplicationContext - first, then to the default resolver of the + first and then to the default resolver of the underlying JSF implementation. This is useful in particular when using request/session-scoped beans with special Spring resolution rules, e.g. Spring FactoryBean @@ -541,10 +541,10 @@ The recommended strategy is to use the approach that best suits your project. Subclassing makes your code more readable, and you know - exactly how your dependencies are resolved. However, using the - ContextLoaderPlugin allow you to easily add new + exactly how your dependencies are resolved. In contrast, using the + ContextLoaderPlugin allows you to easily add new dependencies in your context XML file. Either way, Spring provides some - nice options for integrating the two frameworks. + nice options for integrating with Struts. @@ -566,8 +566,9 @@ WebWork is (in the opinion of this author) a very clean, elegant web - framework. Its architecture and key concepts are not only very easy to - understand, it has a rich tag library, nicely decoupled validation, and it + framework. Its architecture and key concepts are very easy to + understand, and the framework also has a rich tag library as well as + nicely decoupled validation. It is (again, in the opinion of this author) quite easy to be productive in next to no time at all (the documentation and tutorials are pretty good too). @@ -577,17 +578,17 @@ IoC container to manage Webwork Actions, handle the "wiring" of business objects, etc. Prior to WebWork version 2.2, WebWork used its own proprietary IoC container (and provided integration points so that one - could integrate an IoC container such as Springs into the mix). However, + could integrate an IoC container such as Spring's into the mix). However, as of WebWork version 2.2, the default IoC container that is used within WebWork is Spring. This is obviously great news if one is a Spring developer, because it means that one is immediately - familiar with the basics of IoC configuration, idioms and suchlike within + familiar with the basics of IoC configuration, idioms, and suchlike within WebWork. - Now in the interests of adhering to the DRY (Dont Repeat Yourself) - principle, it would be foolish to writeup the Spring-WebWork integration + Now in the interests of adhering to the DRY (Don't Repeat Yourself) + principle, it would be foolish to document the Spring-WebWork integration in light of the fact that the WebWork team have already written such a - writeup. Please do consult the Spring-WebWork integration page on the WebWork wiki @@ -595,11 +596,11 @@ Note that the Spring-WebWork integration code was developed (and continues to be maintained and improved) by the WebWork developers - themselves, so in the first instance please do refer to the WebWork site - and forums if you are having issues with the integration. Do feel free to + themselves. So please refer first to the WebWork site and forums if you are + having issues with the integration. But feel free to post comments and queries regarding the Spring-WebWork integration on the Spring - support forums too. + support forums, too.
@@ -643,7 +644,7 @@ - The key question then is... how does one supply Tapestry pages with + The key question then is: how does one supply Tapestry pages with collaborating services? The answer, ideally, is that one would want to dependency inject those services directly into one's Tapestry pages. In Tapestry, one can effect this dependency injection by a variety of @@ -745,9 +746,9 @@ http://www.springframework.org/schema/beans http://www.springframework.org/schem WebApplicationContext appContext = WebApplicationContextUtils.getApplicationContext( getRequestCycle().getRequestContext().getServlet().getServletContext()); UserService userService = (UserService) appContext.getBean("userService"); -... some code which uses UserService +// ... some code which uses UserService - This mechanism does work... having said that, it can be made a lot + This mechanism does work. Having said that, it can be made a lot less verbose by encapsulating most of the functionality in a method in the base class for the page or component. However, in some respects it goes against the IoC principle; ideally you would like the page to not @@ -785,7 +786,7 @@ UserService userService = (UserService) appContext.getBean("userService"); package com.whatever.web.xportal; -import ... +// import ... public class MyEngine extends org.apache.tapestry.engine.BaseEngine { @@ -1042,7 +1043,7 @@ public abstract class Login extends BasePage implements ErrorProperty, PageRende annotate the appropriate getter methods in order to dependency inject the Spring-managed userService and authenticationService objects (lots of the class - definition has been elided for clarity)... + definition has been elided for clarity). package com.whatever.web.xportal.pages; @@ -1056,7 +1057,7 @@ public abstract class Login extends BasePage implements ErrorProperty, PageRende } - We are almost done... all that remains is the HiveMind + We are almost done. All that remains is the HiveMind configuration that exposes the Spring container stored in the ServletContext as a HiveMind service; for example: