Based on my understanding this is my first attempt at mapping Struts to Tapestry. Given the fact that i have'nt spent enough time with tapestry, it is very likely that i might have commited some glaring errors. Please correct me wherever i have gone wrong.
Tapestry at the minimum needs to have a page template,page specification and a page class.
page template(HTML with tapestry tags)=> jsp with struts tags page specification(template-page class mapping)=> page=> Action and ActionForm merged into one?, so data and business logic merged into one?)
[STRUTS] in Struts generally speaking there is only one struts-config.xml everybody is workign with.
[TAPESTRY] But there seems to be a page specification for every page that you have in your application (Taperstry). So there is no clearcase merge problems to deal with ;-)
[STRUTS] in struts-config.xml we map an action to a form. So the target JSP renders using the properties from the form.
[TAPESTRY] The pagespecification maps every component that you have in the page template to a property in the Page class that you defined. So the component -> value mapping has been taken out of the template and put in another configuration file?.
[STRUTS] Every action gets submitted to the appropriate Action class. Based on the action (inspecting the request parameters) you might execute different methods if you have the same Action class mapped to different actions. I'm referring to LookUpDispathAction here.
[TAPESTRY] Every action possible on the page template is mapped to a method in the page class (The method declaration needs to be according to a specific contract just like execute() in Struts). They are called listeners? you indicate the action-listener mapping in the page template itself along with the component that will trigger this action.
I know its pretty basic but feel this c'd be a starting point.
In a form, you "wire up" components (such as TextField and Checkbox) to properties of your page. When the components render, they read those properties. When the form is submitted, the same components update the properties.
Tapestry uses the OGNL library (www.ognl.org), so instead of simple property names, you can use property paths and expressions. This means that the components can, for example, edit address.city (the city property of the address property of the page). So you don't have to move data out of a ActionForm object and into your domain objects.
Underneath it all, Tapestry is still operation-centric; it just has a "map" of the application (this is the component object model, where the application is divided into pages, and pages into components, and everything has a unique id). This means a small number of operations, built into the framework, are sufficient for building all kinds of applications. You can always create new operations (they're called engine services in Tapestry lingo) to fulfil needs specific to your application ... such as when you need a very particular URL format.
--<br />Howard M. Lewis Ship<br />Independent J2EE / Open-Source Java Consultant<br />Creator, Jakarta Tapestry<br />Creator, Jakarta HiveMind<br /><a href="http://howardlewisship.com" target="_blank" rel="nofollow">http://howardlewisship.com</a>
Originally posted by Howard Lewis Shp: You can always create new operations (they're called engine services in Tapestry lingo) to fulfil needs specific to your application ... such as when you need a very particular URL format.
Hey, this sounds interesting! Does vanilla Tapestry come with alternative URL formats?
In 3.0, its not about the formats, its about basic functionality. For example, the Workbench example distributed with the framework has a special engine service for displaying a chart on demand. The book has examples of a service speciailzed for use as a ad banner redirect.
Tapestry 3.1 (still in planning stages) will provide a lot more control over the actual format of URLs.