svn commit: r468387 - /tapestry/tapestry5/tapestry-core/trunk/src/site/apt/struts.apt

[hl...@apache.org]

Author: hlship
Date: Fri Oct 27 07:15:32 2006
New Revision: 468387

URL: http://svn.apache.org/viewvc?view=rev&rev=468387
Log:
Fill in more details

Modified:
    tapestry/tapestry5/tapestry-core/trunk/src/site/apt/struts.apt

Modified: tapestry/tapestry5/tapestry-core/trunk/src/site/apt/struts.apt
URL: http://svn.apache.org/viewvc/tapestry/tapestry5/tapestry-core/trunk/src/site/apt/struts.apt?view=diff&rev=468387&r1=468386&r2=468387
==============================================================================
--- tapestry/tapestry5/tapestry-core/trunk/src/site/apt/struts.apt (original)
+++ tapestry/tapestry5/tapestry-core/trunk/src/site/apt/struts.apt Fri Oct 27 07:15:32 2006
@@ -43,7 +43,7 @@
   Where does Struts (and similar frameworks) get things wrong?  The first issue is with
   the management of <state>.
   
-  Remember "Begining Object Oriented Programming 101"?  Objects are generally defines
+  Remember "<Beginning Object Oriented Programming 101>"?  Objects are generally defined
   as a software construct that encapsulates behavior <and state>.
   
   Struts actions do not have internal state.  They can't -- they're singletons, one instance
@@ -89,6 +89,15 @@
   you decide on the flavor of output based on the kind of client: HTML for the desktop or WML
   for a phone.
   
+  Perhaps in theory, but certainly not <in practice>. Errors are rarely presented as a whole
+  new view; they are usually presented as additional content within the same view. As to the
+  myth of a single application that vends out different markups for different clients ... 
+  that is just a myth. It's not just about output, but about every aspect of application development.
+  It's more than just what content shows up where ... it's about the very functionality offered
+  and the use cases supported, which are very different from one device to another. Pull back the covers
+  on any single application that supports such diverse clients and you'll find multiple applications, one
+  per device type, squeezed together as a not-so-coherent package.
+  
 Components: Its Not Just About Output
 
   What happens when you have common <fixtures> to your application?  By fixtures,
@@ -123,7 +132,59 @@
   
   You've run into the limitation of not having true web components on your side.
   
+  With Tapestry, individual components can have their own interactions, blended seamlessly into the page, even
+  when the same component is used across multiple pages. Tapestry is able to keep everything organized
+  because it has its own view of the application, the component object model.
+  
 Tapestry: The Full Cycle Solution
 
-  <More to come ...>
+  What Tapestry offers is <structure>.  A well defined, fixed structure of pages and components within
+  pages. This structure is used in every aspect of Tapestry, including state management, output rendering,
+  and request dispatching.
+  
+  You don't have to worry about URLs. Incoming requests for Tapestry encode the
+  name of the page and the id of the component within the page, along with other information,
+  into the URL for you. Your code never has to pick apart a URL, you create
+  {{{guide/event.html}event listening methods}} to know when the user has clicked a link
+  or submitted a form, or done something more interesting using Ajax.  Tapestry has the structure it needs
+  to build all necessary information into the URL, and unpack that information in a later request.
+  
+  Tapestry is truly object oriented: you don't have to be concerned with singletons and multithreading; your 
+  pages and components have instance variables like any other plain Java object. Tapestry lets your write
+  your application using true object oriented techniques.
+
+  In terms of state management: Tapestry takes care of 
+  {{{guide/persist.html}persisting field values into the session}}. You don't have to figure out mneumonic,
+  unique names for session attributes, or write code to pull data out of the session or push it back in.
+  Tapestry is able to do this for you.
+
+  Further, in Tapestry pages and components are identical. They are <consistent>. Pages have templates, so
+  do components. Pages have transient and persistent fields. So do components. Pages have event handler methods,
+  so do components.  
+  
+  Tapestry doesn't have the idea of multiple views for a single page. However, processing within one page can easily "hand off" to
+  another <page>, in Java code, to provide the response to an action by the user.
+  
+Making the Transition
+
+  Don't expect there to be a magic tool to convert an existing application to Tapestry 5. The worlds
+  between Struts and other action oriented frameworks, and Tapestry, are just too far.  
+  
+  With Tapestry, you can start to think of your application in the same terms as your users ... as a collection
+  of pages that are connected together.  
+  
+  You don't create URLs and map them to singleton classes; you put a <component> in your page, and
+  add an {{{guide/event.html}event handling method}} to your class to be invoked when that component is triggered. Many components?
+  No problem, just add more event handler methods.
+  
+Leave Behind the Pain
+
+  Tired of constantly rebuilding and redeploying your application every time you make a change? Tapestry features
+  {{{guide/reload.html}live class reloading}}. Every time you make a change to your code or your templates, Tapestry picks up the
+  changes immediately ... no waiting!  Just think about how fast and easy building an application is without the expected
+  constraints; scripting language speed with all the power of Java.
+  
+  
+  
+