[CONF] Apache Tapestry Principles

2013-02-17 Thread confluence







Principles
Page edited by Bob Harner


Comment:
Wordsmithing, including adding a new controversial claim that you can create new components but not new types of components. Yeah, I know it is technically inaccurate, but it's important not to scare new users who overreact to a basic misunderstanding about how limiting static structure is.


 Changes (4)
 




...
h1. Principle 1 -- Static Structure, Dynamic Behavior  
The concept of Dynamic Behavior should be pretty obvious when you are building a web application; things should look different for different users/situations. But what does it mean that Tapestry has Static Structure? Static structure implies that when you build a page in Tapestry you are going to define all of the types of components that are used within that page. Under no circumstance during the rendering or event processing of the page will you be able to dynamically create a new type of component and place that into the component tree. 
 
At first glance, this seems quite limiting ... other frameworks allow new elements to be created on the fly; its also a common feature of desktop GUIs such as Swing. But static structure turns out to be not so limiting after all. You _can_ create new elements (youre actually re-rendering existing components with different properties). And you have plenty of options for getting dynamic behavior out of your static structure; from the simple conditional and looping components to the more advanced implementations of Tapestrys BeanEditor or Grid components, Tapestry gives you the control over what renders and when. 
At first glance, this seems quite limiting ... other frameworks allow new elements to be created on the fly; its also a common feature of desktop GUIs such as Swing. But static structure turns out to be not so limiting after all. You _can_ create new elements (youre actually re-rendering existing components with different properties). And you have plenty of options for getting dynamic behavior out of your static structure; from the simple conditional and looping components to the more advanced implementations of Tapestrys BeanEditor or Grid components, Tapestry gives you control over what renders and when, and even where it appears on the page. And starting in Tapestry 5.3 you can even use the [Dynamic component|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/components/Dynamic.html], which renders whatever is in an external template file. 
 Why did Tapestry choose static structure as a core principle? Its really a matter of meeting the requirements of agility and scalability. 
...
h1. Principle 2 -- Adaptive API  
A key feature of Tapestry 5 is its adaptive API. 
 In traditional Java frameworks (including Struts, [JSF|Tapestry for JSF Users] and even the now-ancient Tapestry 4) user code is expected to conform to the framework. You create classes that extend from framework-provided base classes, or implement framework-provided interfaces. 
...


Full Content


Related Articles


 Page:
 Tapestry Tutorial





 Page:
 Getting Started





 Page:
 Introduction





 Page:
 Principles





 Page:
 Tapestry for JSF Users




 

Principle 1  Static Structure, Dynamic Behavior

The concept of "Dynamic Behavior" should be pretty obvious when you are building a web application; things should look different for different users/situations. But what does it mean that Tapestry has "Static Structure?" Static structure implies that when you build a page in Tapestry you are going to define all of the types of components that are used within that page. Under no circumstance during the rendering or event processing of the page will you be able to dynamically create a new type of component and place that into the component tree.

At first glance, this seems quite limiting ... other frameworks allow new elements to be created on the fly; 

[CONF] Apache Tapestry Principles

2010-11-30 Thread confluence







Principles
Page moved by Howard M. Lewis Ship






From: 

Apache Tapestry
 Getting Started


To: 

Apache Tapestry
 Documentation





Children moved






   
Change Notification Preferences
   
   View Online
   









[CONF] Apache Tapestry Principles

2010-11-29 Thread confluence







Principles
Page edited by Howard M. Lewis Ship


 Changes (23)
 



h21. What is Apache Tapestry? 
 Apache Tapestry is an open-source framework for creating dynamic, robust, highly scalable web applications in Java. Tapestry complements and builds upon the standard Java Servlet API, and so it works in any servlet container or application server. 
...
Tapestry is released under the Apache Software Licence 2.0.  
h21. Principle 1 -- Static Structure, Dynamic Behavior 
 The concept of Dynamic Behavior should be pretty obvious when you are building a web application; things should look different for different users/situations. But what does it mean that Tapestry has Static Structure? Static structure implies that when you build a page in Tapestry you are going to define all of the components that are used within that page. Under no circumstance during the rendering or event processing of the page will you be able to dynamically create a new component and place that into the component tree.  
h52. Why use static structure? Doesnt this hamper my ability to build software they way I want? 
 
Second part first, static structure is not as limiting as you may think. You have plenty of options for getting dynamic behavior out of your static structure; from the simple conditional and looping components to the more advanced implementations of Tapestrys BeanEditor or Grid components. Its open source, peel back the covers and see how it works!  
...
 *Agility* 
Tapestry is designed to be an agile working environment; Ccode less, deliver more. To support you writing less code Tapestry does a lot of work on your POJO page/component before processing its first request. For complex pages this work can eat up CPU cycles as well as resources. Using a Static Structure static structure means that Tapestry can build this page model once and reuse it to handle each request, whether its a link or a form post. 
 *Scalability* 
When building large scale systems its important to consider how your resources are going to be used on each deployed server, and how that information is going to be shared between servers. Static Sstructure means that page instances do not need to be stored inside the HttpSession and simple browsing users do not require extra system resources. This lean use of the HttpSession is key to Tapestrys very high scalability, especially in a clustered configuration. 
  
h21. Principle 2 -- Adaptive API 
 A key feature of Tapestry 5 is adaptive API. 
...
For example, you may have a login form and have a method that gets invoked when the form is submitted:  
{code:JAVA} {code:lang=java} 
public class Login { 
  @Persist
  @Property
  private String userId; 
 
  @Property
  private String password; 
 
  @Component
  private Form form; 
 
  @Inject
  private LoginAuthenticator authenticator; 
 
void onValidateFromForm() 
  {
if (! authenticator.isValidLogin(userId, password))
{
  form.recordError(Invalid user name or password.);
}
  } 
 
Object onSuccessFromForm() 
  {
return PostLogin.class; 
  } 
} 
} 
{code}  
This short snippet demonstrates a bit about how Tapestry operates. Pages and services within the application are injected with the @Inject annotation. The method names, onValidateForm() and onSuccess(), inform Tapestry about when the method is to be invoked. The two events validateForm and success occur when a form is submitted; validateForm is triggered to perform cross-field validations, and success is only triggered when there are no validation errors. The onSuccess() methods return value directs Tapestry on what to do next: jump to another page within the application (here identified as the class for the page, but many other options exist). When there are exceptions, the page will be redisplayed to the user. 
This short snippet demonstrates a bit about how Tapestry operates. Pages and services within the application are injected with the @[Inject|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/annotations/Inject.html] annotation. The method names, {{onValidateFromForm()}} and {{onSuccessFromForm()}}, inform Tapestry about when each method is to be invoked. This naming convention identifies the event that is handled, (validate and success) and the id of the component from which the event is triggered (the form component{footnote}The component id can be omitted, leaving the method name 

[CONF] Apache Tapestry Principles

2010-10-04 Thread confluence







Principles
Page edited by Josh Canfield


 Changes (14)
 



...
Tapestry is architected to scale from tiny, single-page applications all the way up to massive applications consisting of hundreds of individual pages, developed by large, diverse teams. Tapestry easily integrates with any kind of backend, including JEE, Spring and Hibernate.  
Its more than what you can do with Tapestry ... its also how you do it! Tapestry is a vastly productive environment. Java developers love it because they can make Java code changes and see them immediately ... no redeploy, no restart! And its blazingly fast to boot (even when files change). Designers love it because Tapestry templates are so close to ordinary HTML, without all the cruft and confusion seen in JavaServer Pages. Managers love it because it makes it easy for large teams to work together, and because they know important features (including localization) are baked right in. Once you work in Tapestry theres no going back!  Tapestry is released under the Apache Software Licence 2.0.  h2. Principle 1 -- Static Structure, Dynamic Behavior  
Tapestry is designed to be extremely scalable in several dimensions: 
* Tapestry applications may contain large numbers of pages and many custom components. * Tapestry applications may contain very complex functionality. 
...
* 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 
Its more than what you can do with Tapestry ... its also how you do it! Tapestry is a vastly productive environment. Java developers love it because they can make Java code changes and see them immediately ... no redeploy, no restart! And its blazingly fast to boot (even when files change). Designers love it because Tapestry templates are so close to ordinary HTML, without all the cruft and confusion seen in JavaServer Pages. Managers love it because it makes it easy for large teams to work together, and because they know important features (including localization) are baked right in. Once you work in Tapestry theres no going back! 
 
In Tapestry, the structure of any particular page is static. This is necessary for several reasons, most importantly because Tapestry pages are pooled. Creating a 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. 
Tapestry is released under the Apache Software Licence 2.0. 
 
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. 
h2. Principle 1 -- Static Structure, Dynamic Behavior 
 
Tapestry does not need to store page instances inside the HttpSession. At most, it stores a smattering of persistent field values from the page, but not the entire page instance. This lean use of the HttpSession is key to Tapestrys very high scalability, especially in a clustered configuration. 
The concept of Dynamic Behavior should be pretty obvious when you are building a web application; things should look different for different users/situations. But what does it mean that Tapestry has Static Structure? Static structure implies that when you build a page in Tapestry you are going to define all of the components that are used within that page. Under no circumstance during the rendering or event processing of the page will you be able to dynamically create a new component and place that into the component tree. 
 
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. 
h5. Why use static structure? Doesnt this hamper my ability to build software they way I want? Second part first, static structure is not as limiting as you may think. You have plenty of options for getting dynamic behavior out of your static structure; from the simple conditional and looping components to the more advanced implementations of Tapestrys BeanEditor or Grid