[Struts-cvs] struts-site/src/documentation/content/xdocs/strutsdialogs index.xml,1.11,1.12

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Update of /cvsroot/struts/struts-site/src/documentation/content/xdocs/strutsdialogs
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11633/src/documentation/content/xdocs/strutsdialogs

Modified Files:
	index.xml 
Log Message:


Index: index.xml
===================================================================
RCS file: /cvsroot/struts/struts-site/src/documentation/content/xdocs/strutsdialogs/index.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** index.xml	4 Aug 2005 08:18:47 -0000	1.11
--- index.xml	11 Sep 2005 01:46:38 -0000	1.12
***************
*** 7,12 ****
  
    <body>
!     <section id="overview">
        <title>Overview</title>
  	<p>Struts Dialogs library allows building <em>web components</em> using Struts and JSP.</p>
  
--- 7,146 ----
  
    <body>
! 
!     <section id="overview_new">
        <title>Overview</title>
+ 	<p><strong>Struts Dialogs</strong> combines Front Controller pattern of classic Struts with Page Controller features
+ 	of ASP.NET and JSP. It implements event handling, basic state management, provides simplified control flow and facilitates 
+ 	component development.</p>
+ 
+ 	<ul>
+ 	<li><strong>Simplified control flow</strong> - concerns between actions, action forms and JSP pages are cleanly separated.</li>
+ 	<li><strong>Event handling</strong> - command links and form submissions are processed 
+ 	by an action, which a JSP page corresponds to.</li>
+ 	<li><strong>State management</strong> - session-scoped ActionForm is elevated from simple request buffer to stateful 
+ 	input/output object.</li>
+ 	<li><strong>Component development</strong> - It is possible to create standalone and embedded components without portal 
+ 	engine and portlet API.</li>
+ 	<li><strong>Web Wizards</strong> - create web wizards, similar to traditional desktop wizard dialogs.</li>
+ 	</ul>
+     </section>
+ 
+     <section id="controlflow">
+       <title>Simplified control flow</title>
+ 	<p>Struts is a controller framework that adheres closely to the principles of Front Controller Pattern 
+ 	(<link href="http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html">J2EE Front Controller pattern</link>, 
+ 	<link href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/DesFrontController.asp">.NET Front Controller pattern</link>):</p>
+ 
+ 	<ul>
+ 	<li><strong>ActionServlet</strong>, <strong>RequestProcessor</strong>: Controller (J2EE); Handler (.NET)</li>
+ 	<li><strong>Action</strong>: Dispatcher (J2EE); part of Command (.NET)</li>
+ 	<li><strong>ActionForm</strong>: part of Command (.NET)</li>
+ 	<li><strong>JSP</strong>: view</li>
+ 	</ul>
+ 
+ 	<p>The Front Controller pattern does not specify how the state should be managed, or where a request should be directed
+ 	after a view is rendered. Out-of-the-box Struts does not provide much help on these subjects. Quite contrary, 
+ 	official Struts documentation suggest practices that may complicate the matters.</p>
+ 
+ 	<section id="traditionalflow">
+       	  <title>Traditional Struts approach</title>
+ 
+ 		<p>ActionForm was initially designed as convenience object for input data. Struts guidelines recommend using 
+ 		ActionForm with request scope, which prevents from storing state information in it. It is up to 
+ 		the developer to decide where to queue output data, and where to store information between requests.</p>
+ 
+ 		<p>Struts documentation does not specify how exactly JSP preparation and form submission should 
+ 		be handled. Struts users came up with idea of pre-Action (output Action, setup Action) and post-Action 
+ 		(input Action) dispatchers, so actions and JSP pages are interlaced:</p>
+ 
+ 		<figure src="images/struts-pre-post-action.gif" alt="Pre- and Post- actions"/>
+ 
+ 		<p>The problem here is that one JSP can relate to several actions, and the only way to determine 
+ 		the action (or actions) that handle the submission of the page, is to look through the JSP code. 
+ 		Because of many-to-many relationships between actions and JSP pages, web application becomes 
+ 		hard to maintain right from the start.</p>
+ 	</section>
+ 
+ 	<section id="codebehind">
+       	  <title>Code-behind for Struts</title>
+ 
+ 		<p>Struts Dialogs employs code-behind pattern similar to one used in .NET framework, 
+ 		while keeping your investments into Struts.</p>
+ 
+ 		<p>One of the .NET concepts is a unity of page markup (ASP) and business-related code (C# or VB). 
+ 		A page layout and widgets are defined in the markup, while corresponding code-behind class handles 
+ 		page lifecycle and incoming events. This concept is especially easy to grasp for desktop applications 
+ 		programmers: before page is displayed, the code behind it initializes page data. After page is rendered, 
+ 		activating a widget in the browser window generates event, which is dispatched to a handler.</p>
+ 
+ 		<p>This pattern can be implemented in Struts with no change to core classes or tag libraries. It even can
+ 		 be improved, because Struts allows to define several markup pages corresponding to one action.</p>
+ 
+ 		<p>First you need to change your mindset. Forget about traditional Struts pre-actions and post-actions. 
+ 		Do not think in terms of pages either. Think in terms of web resources. Recall that internet is about 
+ 		web resources, not about mere pages. A page is just a visualization of resource in its current state at
+ 		a given time. An address identifies a resource, not a particular representaion of it. Resource can be rendered 
+ 		differently depending on its state.</p>
+ 
+ 		<figure src="images/struts-dialog-action.gif" alt="Dialog action"/>
+ 
+ 		<p>In Struts Dialogs each resource is serviced by one action class. Depending on resource state, 
+ 		the action class can render different views,defined in JSP pages. Each JSP page belongs to 
+ 		one action class only, which is called <em>parent action</em>. Data, submitted from a page, is handled by the parent 
+ 		action. If submitted data changed resource state, the action may render a different page the next time resource
+ 		is accessed. Read more on input submission in <strong>Event Handling section</strong>.</p>
+ 	</section>
+     </section>
+ 
+     <section id="eventhandling">
+       <title>Event handling</title>
+ 
+ 	<p>Official Struts documentation does not specify, how exactly form input should be handled. 
+ 	It is common practice to prepare content for JSP page with one action, and to collect input data 
+ 	in another action. This wide-spread net of single-task actions makes development more complicated 
+ 	than it could be.</p>
+ 
+ 	<p>Struts Dialogs offers a different approach, which is used by frameworks like .NET and JSF. 
+ 	Form submission generates input event, which is handled in action class. Action class defines 
+ 	handler methods for every input event. Input events can be generated not only by submitting a form, 
+ 	but also by clicking on a command link.</p>
+ 
+ 	<p>Direct linking from JSP page to another resource is discouraged. Instead, a command link should 
+ 	generate an event, which would be handled by parent action class. Only action class should decide 
+ 	which resource to navigate to next. This approach allows to define all navigation targets in the <code>struts-config.xml</code>
+ 	file, thus having a clear representation of web application structure.</p>
+ 
+ 	<p>Event handling is implemented by DialogAction, the extension of venerable DispatchAction. 
+ 	DialogAction provides other services as well, like <strong>two-phase request processing</strong>.</p>
+     </section>
+ 
+ 
+     <section id="state_management">
+       <title>State management</title>
+ 
+ 	<p>Struts Dialogs does not introduce new classes to manage application state. Instead, it uses 
+ 	the class which already exists in the Struts core, ActionForm. Official Struts guidelines recommend 
+ 	using ActionForm with request scope, only to collect input data. This decision entails developers 
+ 	to use custom objects to queue output data and to store information between requests.</p>
+ 
+ 	<p>Struts Dialogs suggests to use session scope for ActionForm. One simple change in the config file 
+ 	promotes ActionForm from simple request buffer to stateful input/output object. In JSF terms, 
+ 	ActionForm now acts as a backing bean for JSP page. There is nothing groundbreaking in using 
+ 	session scope for ActionForm, or in storing output data in it. Online poll shows that about 60% of
+ 	respondents use ActionForm for queueing output data.</p>
+ 
+ 	<p>With changing ActionForm scope to session, it is possible now to initialize form bean only once, 
+ 	and to reuse data between requests. This is convenient for form resubmissions, for page reloading
+ 	or for navigating back to previous resource. Having all resource data 
+ 	in a single ActionForm simplifies JSP page. Struts automatically populates ActionForm 
+ 	with submitted data, now you can use this data to render a page without any 
+ 	additional efforts. Session scope justifies the usage of nested properties within ActionForm, 
+ 	which allows to use business objects or DTOs directly without copying their data to ActionForm 
+ 	and from ActionForm.</p>
+ 
+     </section>
+ 
+     <section id="components">
+       <title>Component Development</title>
  	<p>Struts Dialogs library allows building <em>web components</em> using Struts and JSP.</p>
  
***************
*** 50,58 ****
     </section>  
  
      <section id="selectaction">
        <title>SelectAction: dispatches submit events</title>
  	<p><link href="selectaction.html">SelectAction</link> is an enhancement of standard DispatchAction. 
! 	It handles submit events and provides improved dispatching functionality.
! 	SelectAction has the following features:</p>
  	<ul>
  	<li>works uniformly with pushbuttons, image buttons and regular links;</li>
--- 184,201 ----
     </section>  
  
+     <section id="actions">
+       <title>Actions</title>
+ 	
+ 	<p>Most features of the Struts Dialogs library are available through use of different action
+ 	classes. Most often you will be using DialogAction class, extending your specific action class 
+ 	from it.</p>
+      
+ 
      <section id="selectaction">
        <title>SelectAction: dispatches submit events</title>
  	<p><link href="selectaction.html">SelectAction</link> is an enhancement of standard DispatchAction. 
! 	It handles submit events and provides improved dispatching functionality. You can use this action
! 	class if you do not need full power of DialogAction, and all you want is just to dispatch submit
! 	events to handler methods. SelectAction has the following features:</p>
  	<ul>
  	<li>works uniformly with pushbuttons, image buttons and regular links;</li>
***************
*** 62,66 ****
  
      <section id="dialogaction">
!       <title>DialogAction: handles component state and renders a view</title>
  	<p><link href="dialogaction.html">DialogAction</link> is the main asset of 
  	Struts Dialogs library.</p>
--- 205,209 ----
  
      <section id="dialogaction">
!       <title>DialogAction: the Jack of all trades</title>
  	<p><link href="dialogaction.html">DialogAction</link> is the main asset of 
  	Struts Dialogs library.</p>
***************
*** 83,90 ****
  
  
      <section id="crudaction">
        <title>CRUDAction: simplifies CrUD operations</title>
! 	<p><link href="crudaction.html">CRUDAction</link> is a more specific kind of action class, 
! 	which implements all operations needed to manipulate business data, nested business object (BO),
  	or nested value object (VO) also called an <code>item</code>. This action allows to create 
  	new item, duplicate existing item, edit, view, clear and delete item.</p>
--- 226,240 ----
  
  
+     <section id="wizardaction">
+       <title>WizardAction: creates robust page flows</title>
+     	<p><link href="wizardaction.html">WizardAction</link> allows to create <em>web wizards</em>,
+         similar to traditional desktop wizard dialogs. A wizard has predefined sequence of states,
+         and is rendered with HTML forms, containing Back, Forward, Cancel and Done pushbuttons.</p>
+    </section>
+ 
      <section id="crudaction">
        <title>CRUDAction: simplifies CrUD operations</title>
! 	<p><link href="crudaction.html">CRUDAction</link> implements all operations needed 
! 	to manipulate business data, nested business object (BO),
  	or nested value object (VO) also called an <code>item</code>. This action allows to create 
  	new item, duplicate existing item, edit, view, clear and delete item.</p>
***************
*** 94,104 ****
  	implement handling of both item list and CRUD operations as one web component.</p>
     </section>  
! 
!     <section id="wizardaction">
!       <title>WizardAction: creates robust page flows</title>
!     	<p><link href="wizardaction.html">WizardAction</link> allows to create <em>web wizards</em>,
!         similar to traditional desktop wizard dialogs. A wizard has predefined sequence of states,
!         and is rendered with HTML forms, containing Back, Forward, Cancel and Done pushbuttons.</p>
!    </section>
  
        <section id="demos">
--- 244,248 ----
  	implement handling of both item list and CRUD operations as one web component.</p>
     </section>  
!    </section>  
  
        <section id="demos">
***************
*** 114,116 ****
  
    </body>
! </document>
--- 258,260 ----
  
    </body>
! </document>
\ No newline at end of file