svn commit: r400343 - /tapestry/tapestry5/tapestry-project/trunk/src/site/apt/index.apt

[hl...@apache.org]

Author: hlship
Date: Sat May  6 10:15:08 2006
New Revision: 400343

URL: http://svn.apache.org/viewcvs?rev=400343&view=rev
Log: (empty)

Modified:
    tapestry/tapestry5/tapestry-project/trunk/src/site/apt/index.apt

Modified: tapestry/tapestry5/tapestry-project/trunk/src/site/apt/index.apt
URL: http://svn.apache.org/viewcvs/tapestry/tapestry5/tapestry-project/trunk/src/site/apt/index.apt?rev=400343&r1=400342&r2=400343&view=diff
==============================================================================
--- tapestry/tapestry5/tapestry-project/trunk/src/site/apt/index.apt (original)
+++ tapestry/tapestry5/tapestry-project/trunk/src/site/apt/index.apt Sat May  6 10:15:08 2006
@@ -48,6 +48,45 @@
   
   * Super-duper Ajax integration built on {{{http://dojotoolkit.org} Dojo}}
   
+Principal 1 -- Static Structure, Dynamic Behavior
+
+  Tapestry is designed to be extremely scalable in several dimensions:
+  
+  * Tapestry applications may contain many pages and many custom components.
+  
+  * Tapestry applications may contain very complex functionality.
+  
+  * Tapestry applications may be created by large, diverse teams.
+  
+  * Tapestry applications can service large numbers of concurrent users.
+  
+ One core architecture decision in Tapestry exists to service many of the above goals
+ (and others that are harder to describe).  <<Static Structure, Dynamic Behavior>>
+
+ In Tapestry, the structure of any particular page is <static>. This is necessary for
+ several reasons, most importantly because Tapestry pages are <pooled>.  Creating and Tapestry page
+ is an involved process, because the page object is simply the root of a large tree of other
+ objects including user provided components, many kinds of structural objects, template objects,
+ and others. Creating a new page instance for each request is simply not <scalable>.
+ 
+ Instead, Tapestry <pools> pages.  Once created, a page instance will be stored in a pool for
+ that particular type of page, and reused
+ in later requests. An incoming request, the result of a user clicking a link or submitting a form,
+ will be processed by <some> server within a cluster, and will use <some> page instance within the
+ page pool. Because page instances are static and uniform across instances and servers, 
+ Tapestry can use any available page instance, or create a new one as needed.
+ 
+ Tapestry does not need to store page instances inside the HttpSession. At most, it stores a smattering
+ of <persistent properties> of the page in the session, but not the entire page instance. This lean
+ use of the HttpSession is key to Tapestry's very high scalability, especially in a clustered
+ configuration.
+ 
+ In some Tapestry-like frameworks, such as Faces and Wicket, the page structure is more dynamic, at 
+ the cost of storing much, much more data in the HttpSession.
+ 
+ This static structure is not so limiting as you might think. With different kinds of conditional
+ and looping components, and the ability to "jump out of the flow" and render components in an arbitrary order, 
+ you will not find Tapestry to be rigid ... anything but!
   
 Public vs. Internal