Tapestry
Community:
(6 votes)
Loading …Maturity: (5 votes) Loading …Documentation: (6 votes) Loading …Resources: (7 votes) Loading … Customization: (7 votes) Loading …Integration: (6 votes) Loading …Tapestry is a framework for creating dynamic and robust web applications in Java. Tapestry is built on the concept of standard Java Servlet API. It can work in any servlet container or application server. Tapestry is a real framework for building intricate applications by using simple and reusable components. It competes with other frameworks such as Struts, Web Work, and Turbine. Tapestry is developed by Howard Lewis Ship; it has emerged as the first choice for web developers as an application framework. Tapestry is also a part of Jakarta Project at Apache software foundation.
At present Tapestry is in release 5.0. The main focus of Tapestry is on creating dynamic HTML pages. With default implementations supplied, API of Tapestry is portrayed in terms of interfaces. By replacing new objects with the correct interfaces, the performance of the framework can be changed considerably. An ordinary example is to override where page and component specifications are stored.
Key Principles
Tapestry is well thought-out around four key principles:
- Simplicity - web applications should be easy to understand.
- Consistency - anything that works in pages should work in components. Anything that works in small applications should work in large applications. Different developers should find similar solutions to similar problems.
- Efficiency - applications should be scalable and productive with minimum effort.
- Feedback - if anything goes wrong, framework should identify fault.
General Structure of Tapestry
- First of all an Application Servlet is invoked by the Web container.
- Then it creates an Application Engine object for each user.
- In the next step Application Engine reads the main application config file.
- Then Application Engine reads property files.
- Finally an Application Engine renders a HTML view from a template.
Understanding Tapestry
Tapestry is a component-centric framework not operation-centric. Majority of the web technologies (struts, servlets etc.) are operation-centric. While creating servlets that are called when a user clicks a link or submits a form. Whereas you are responsible for selecting a suitable URL, with the name and type of any query parameters and can easily pass information you need in the URL.
The whole lot is diverse inside Tapestry. Tapestry applications are composed of pages; which can be created from smaller components. Components can be created from other components. Every page contains a unique name, and every component within a page has its own unique id. Every component has an address that can easily be integrated into a URL.
Pages and Components
Tapestry splits an application into a set of pages. Each page is bringing together from Tapestry components. Components themselves may be assembled from other components.
All Tapestry components can be containers of other components. Tapestry pages, and most user-defined components, have a template, a special HTML file that describes the static and dynamic portions of the component, with indicators which define where embedded components are active.
Components may have one or more named parameters that may be bound by the page or component which contains them. Contrasting Java method parameters, Tapestry component parameters may be bidirectional (a component may read a parameter to obtain a value, or write a parameter to set a value).
Most components are concerned only with creating HTML while a certain subset of components deals with handling of incoming requests. Other components, form, and the form control components (Text Field, Property Selection, Checkbox, etc.), make ease to HTML forms. When such components render, they read properties from application objects so as to make available default values. When forms get submitted, the components within the form read HTTP query parameters, converting the values to appropriate types and then update properties of application objects.
Language of Tapestry
With passage of time Tapestry has developed its own language. The Engine is a central object, which contains the same position in Tapestry that the HttpSession has in the Servlet API. The Engine has responsibility of storing the unrelenting state of the application (properties that exist from one request to the next), and this is achieved by storing the Engine into the HttpSession.
Engine service is a link between Servlets, URLs and the rest of Tapestry. Engine services encode URLs by assuring availability of query parameters that identify to the framework. When the generated URL is triggered (when end user clicking a link or submitting a form), the exact operation will occur. Services have to decode the incoming requests. That is how cycle of URL encoding and decoding inside a single object goes on.
Central point for all server side stat is the Visit object, which is an application-defined object. The Visit object is stored as a property of the Engine, and so is ultimately stored persistently in the HttpSession
Another application-specific object is the Global object. It is independent of any particular user or session and stores information global to the entire application. Common usage of the Global object is to integrate logic that performs JNDI lookups of session EJBs.
Features
By using Tapestry it is very easy to develop web applications. Tapestry adopts a component approach to web development, making it possible to move all the boring code out of the application and into the framework. Applications developed using the Tapestry framework naturally adapts to the Tapestry philosophy of simplicity, consistency, efficiency, and feedback.
- High Level Interfaces and Data Flow
Provided components, learning the APIs, and XML component and page specification are not enough while developing in Tapestry. Moreover you have to understand its key notion and the logic flow of the framework.
There are lots of high-level concepts that developers should know for successfully using Tapestry. One such concept is the Visit object. The Visit object contains information about a single client’s visit to the Web page. This object is processed by the Engine. This object can be any routine object that put into practice a serializable interface and that is the only requirement. Under the covering, this object is stored in the HttpSession.
- Handling Exception and Classify them
Tapestry has very complicated exception reporting and classification mechanism. The Exception reporting uses reflection to work backwards through the chain of exceptions, displaying JavaBeans properties of each exception and a stack trace of the deepest exception.
In addition, feature about the servlet, application, request, servlet context, and JVM is displayed. The objective is to generate report when exception occurs, in order to save developers debugging time.
- Tapestry pages and pooling
Tapestry pages are pooled. To create a page, we generally enlarge our new page class from Tapestry’s BasePage and it has already plenty of functionality for reusing, with quite a number of different properties and methods. As a result, creating an instance of a page class is wastage of computer resources.
To avoid creating a page object every time when yet another users requests the page, Tapestry has a pool for every kind of page and stores in that pool some number of instances of the given page class.
Integration of Tapestry with Other Frameworks
- Tapestry-OGNL: Tapestry can be integrated with “OGNL”(Object Graph Navigation Language). OGNL is used to allow two different objects (such as a page and a component contained by that page) to share information.
- Tapestry-Spring: It can be easily integrated with “spring” framework. Tapestry introduces spring beans directly into pages.
- Tapestry-Acegi: Tapestry can also be integrated with the Acegi security framework
- Tapestry-Flash: It has short term property storage modeled on Rail’s "Flash".
- Tapestry-Prop: Non-reflective property access; fast but limited replacement for "OGNL".
Frameworks doing the same job
Listener methods in Tapestry are very similar to C#. In both cases, method of particular object instance is symbolized as an object. Calling it a
"listener" or a "listener method" is creating a little bit naming confusion; so it is called a "delegate" and a "delegate method".
Just supply the listener method without supplying entire Servlet, this listener method is invoked at the right time, under the right conditions. It’s not your business to think how to build that URL, what data goes in to the URL, or how to clasp it up to your application-specific code. These are all handled by the framework.
Something good about Tapestry
Tapestry is a good substitute of scripting environments like JavaServer Pages etc. Tapestry provides a complete framework for making tremendously dynamic applications with minimum coding.
Tapestry provides the following benefits:
- It has very high level of reuse as everything in Tapestry is a reusable component
- Developers get rid of writing tedious and tiresome code. (Here Code is of objects, methods and properties, not URLs and query parameters)
- Internationalization/Localization is now very easy.
- Extremely robust applications because less code resulted in less bugs.
- Graphic designers and Java developers can work together without having to know each other’s jobs so team integration becomes very easy.
Something bad about Tapestry
One of the main disadvantages of Tapestry is the lack of tools support. Although it is inquisitive to see that a Tapestry application can be developed using a simple text editor, and Ant is as useful here as with any other Java application, which can’t be happily accepted by the majority of Java web developers, especially when it comes to an application on an enterprise scale.
Another main hindrance to acceptance of Tapestry is that it provides complicated solutions for simple problems. The reason is that the developers of the framework are speeding up to create more and more powerful solutions, but the necessity of simpler answers to everyday problems is being unnoticed. This can be easily compensated by creating more components for the framework, of different levels of complexity and power, but it has not been done so far. For this reason many feels that Tapestry is not a full-bodied framework yet.
One of the clear picture s of this can be found in this example in which all the errors had to be displayed which was made on the page in Struts; it takes as little as one tag:
<html:errors/>
To achieve the same purpose in Tapestry, it took four components and many more lines of code, both in the HTML template and in the page specification.
Leave a comment