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

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-serv16014/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.14
retrieving revision 1.15
diff -C2 -d -r1.14 -r1.15
*** index.xml	23 Sep 2005 07:23:42 -0000	1.14
--- index.xml	28 Sep 2005 01:04:59 -0000	1.15
***************
*** 10,31 ****
      <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>, 
--- 10,36 ----
      <section id="overview_new">
        <title>Overview</title>
! 	<p><strong>Struts Dialogs</strong> is a library for Struts 1.2.x framework, which improves 
! 	development process and makes applications more robust and user-friendly. 
! 	Struts Dialogs combines best features of Struts Front Controller pattern with 
! 	Page Controller features of ASP.NET. It implements event handling, basic state management, 
! 	provides simplified control flow and facilitates component development.</p>
  	<ul>
! 	<li><strong>Simplified control flow</strong> - cleaner separation of concerns between actions, 
! 	action forms and JSP pages.</li>
! 	<li><strong>Event handling</strong> - uniform processing of command links and form submission
! 	events.</li>
! 	<li><strong>State management</strong> - using session-scoped form bean as first-class stateful
  	input/output object.</li>
! 	<li><strong>Easier configuration</strong> - improved request/response cycle is controlled with
! 	less XML markup and fewer Java classes.</li>
! 	<li><strong>Component development</strong> - either standalone or visually embedded components 
! 	without portal engine and portlet API.</li>
! 	<li><strong>Web Wizards</strong> - controlled flow of web pages for a given web resource, 
! 	similar to traditional desktop wizard dialogs.</li>
  	</ul>
      </section>

      <section id="controlflow">
!       <title>Front Controller pattern</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>, 
***************
*** 36,116 ****
  	<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>

! 	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.
! 
 	<section id="traditionalflow">
! 	 <title>Traditional Struts approach</title>

! 		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.

! 		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:

! 		<figure src="images/struts-pre-post-action.gif" alt="Pre- and Post- actions"/>

! 		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.
 	</section>

<section id="codebehind">
! 	 <title>Code-behind for Struts</title>
! 
! 		Struts Dialogs employs code-behind pattern similar to one used in .NET framework, 
! 		while keeping your investments into Struts.

! 		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.

! 		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.

! 		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.

! 		<figure src="images/struts-dialog-action.gif" alt="Dialog action"/>

! 		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 parent action. 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.
! 	</section>
! </section>

!     <section id="eventhandling">
!       <title>Event handling</title>

! 	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.

! 	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>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>
      </section>

- 
      <section id="state_management">
        <title>State management</title>
--- 41,117 ----
  	<li><strong>Action</strong>: Dispatcher (J2EE); part of Command (.NET)</li>
  	<li><strong>ActionForm</strong>: part of Command (.NET)</li>
! 	<li><strong>JSP page</strong>: view</li>
  	</ul>

! 	The Front Controller pattern does not specify exact details of how the state should be managed, 
! 	or how a response should be handled after a view is rendered. Out-of-the-box Struts framework does 
! 	not provide much help on these subjects. Quite contrary, official Struts documentation suggest 
! 	practices that may complicate the matters.
! 	</section>
! 	
 	<section id="traditionalflow">
! 	 <title>Struts: traditional request/response cycle</title>

! 	Class <code>ActionForm</code> was initially designed as convenience object for input data. 
! 	Struts guidelines recommend using ActionForm in request scope. This precludes
! 	from storing state information in ActionForm. It is up to developer to decide 
! 	where to queue output data to, and where to store information between requests.

! 	Struts documentation does not specify how exactly to prepare JSP page, and how to handle form
! 	submission. 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, while
! 	action-relevant business data (green oval on the picture below) is located outside of an action:

! 	<figure src="images/struts-pre-post-action.gif" alt="Pre- and Post- actions"/>

! 	Each interactive JSP page is handled by at least two actions, and each action can render
! 	different pages. Because of many-to-many relationships between actions and JSP pages, 
! 	web application becomes hard to maintain right from the start.
 	</section>

<section id="codebehind">
! 	 <title>Struts Dialogs: code-behind and event handling</title>

! 	Struts Dialogs makes development simpler by employing code-behind pattern similar 
! 	to one used in ASP.NET framework, while keeping your investments into Struts.

! 	One of the ASP.NET concepts is a unity of page markup (ASPX) and business-related code (C# or VB). 
! 	A page layout and widgets are defined in the markup, while corresponding class handles 
! 	page lifecycle and incoming events. This concept is especially easy to grasp for programmers 			of desktop applications:

! <source> 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.
! </source>

! 	This pattern is implemented by Struts Dialogs with no changes to core Struts classes 
! 	or tag libraries. Moreover, it is improved, because Struts allows to define several 
! 	markup pages corresponding to one Java class.

! 	To use event-dispatching actions one should think in terms of web resources. 
! 	Internet is about web resources, not about 
! 	mere pages. A page is just a visualization of a resource in its current state at
! 	a given time. An address identifies a resource, not a particular representaion of it. 
! 	A resource can be rendered differently depending on its state.

! 	<figure src="images/struts-dialog-action.gif" alt="Dialog action"/>

! 	In Struts Dialogs each resource is represented by one action (which consists of
! 	an action class and a form bean). Depending on resource state, an action can render 
! 	one view or another. Views, corresponding to an action, are defined as JSP pages. 
! 	Each JSP page belongs to one action only, which is called a parent action.

! 	Submission of a form from JSP page generates input event, which is handled by 
! 	the page's parent action. Action class defines handler methods for every input event. 
! 	Input events can be generated not only by submitting a form (POST), but also by 
! 	clicking on a command link (GET). Think of enhanced <code>DispatchAction</code>.

! 	<p>Direct linking from JSP page to another resource is possible, but discouraged. 
! 	Instead, a command link should generate an event, which would be handled by parent action 
! 	class. It is up to an action class to decide where to navigate next. This approach 
! 	allows to define all navigation targets in the <code>struts-config.xml</code> file, 
! 	having a clear representation of web application structure.</p>
      </section>

      <section id="state_management">
        <title>State management</title>
***************
*** 131,137 ****
  	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>

--- 132,138 ----
  	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
  	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>