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 divides a web application into a set of pages, each constructed from components. This provides a consistent structure, allowing the Tapestry framework to assume responsibility for key concerns such as URL construction and dispatch, persistent state storage on the client or on the server, user input validation, localization/internationalization, and exception reporting. Developing Tapestry applications involves creating HTML templates using plain HTML, and combining the templates with small amounts of Java code. In Tapestry, you create your application in terms of objects, and the methods and properties of those objects – and specifically not in terms of URLs and query parameters. Tapestry brings true object oriented development to Java web applications.
Tapestry is specifically designed to make creating new components very easy, as this is a routine approach when building applications.
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.
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 may be created by large, diverse teams.
- Tapestry applications can service large numbers of concurrent users.
It's more than what you can do with Tapestry ... it's 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 it's 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 there's no going back!
Tapestry is released under the Apache Software Licence 2.0.
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.
Why use static structure? Doesn't this hamper my ability to build software they way I want?
Second part first, static At first glance, this seems quite limiting ... other frameworks allow new elements to be created on the fly; it's also a common feature of desktop GUIs such as Swing. 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 Tapestry's BeanEditor or Grid components. It's open source, peel back the covers and see how it works!, Tapestry gives you the control over what renders and when.
Why did Tapestry choose static structure as a core principle? It's really a matter of meeting the requirements of agility and scalability.
Agility
Tapestry is designed to be an agile working environment; "code 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 means that Tapestry can build this page model once and reuse it to handle each request, whether it's a link or a form postpages and components when first loading them. It also uses shared instances of page and component classes (shared across multiple threads and requests). Having dynamically modifiable structure would imply that each request has its own instance and, further, that the entire structure would need to be serialized between requests so that it can be restored to handle later requests.
Scalability
When building large scale systems it 's is 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 structure 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 Tapestry's very high scalability, especially in a clustered configuration. Again, linking an instance of a page to a particular client would require vastly more server-side resources than having a single shared page instance.
Principle 2 – Adaptive API
...
Finally, Tapestry 5 explicitly separates actions (requests that change things) and rendering (requests that render pages) into two separate requests. Performing an action, such as clicking a link or submitting a form, results in a client side redirect to the new page. This is often called "redirect after post". This helps ensure that URLs in the browser are book-markable ... but also requires that a bit more information be stored in the session between requests (using the @Persist annotation).
Principle 3 – Differentiate Public vs. Internal APIs
An issue plaguing previous versions of Tapestry 4 (and earlier) was the lack of a clear delineator between private, internal APIs and public, external APIs. The fact that your code would extend from base objects but that many of the methods on those base objects were "off limits" further confused the issue. This has been identified as a key factor in the "steep learning curve of Tapestry" meme.
...
Tip |
---|
If you ever find yourself forced to make use of internal APIs, please bring it up on the developer mailing list; this is how we know which services should be exposed as public, and fall under the backwards compatibility umbrella. |
Principle 4 – Ensure Backwards Compatibility
Tapestry has been plagued by backwards compatibility problems with every major release (through Tapestry 4). Tapestry 5 does not even attempt to be backwards compatible to Tapestry 4. Instead, it lays the ground work for true backwards compatibility going forwards.
...