V. Cekvenich wrote:
Struts 1.1 has something called tiles that are can be used for re-use, and at run time a tile can be bound to different beans, and more advanced capabilities.I'm not sure that Tiles can be compared at all to what Tapestry is doing. Using JSP as a substrate for any kind of framework (and Tiles is based on JSP using a taglib) limits the things you can do to promote reuse:
http://www.lifl.fr/~dumoulin/tiles/doc/tutorialBody.html
and an advanced PDF (in doco of basicPortal which uses tiles and else where).
* Tapestry binds components together through the definitions (.jwc) file and allows a component to synchronize it's state with another component - allowing object values to be passed down and back up through the runtime component hierarchy. JSP allows only "String" communication between "components" via the <jsp:include ...> mechanism (by nesting <jsp:parameter ...> tags). Other communciation can be set up by setting attributes in the request, but this gets messy very quickly and is nearly unreadable for any reasonable size number of parameters.
* JSP gets only one shot at producing a page - the rendering stage. Tapestry has a "request cycle" that sweeps through the component hiearchy with the request first (to allow components to extract request parameters and alter their internal state accordingly), then an action phase to take action (and get the resultant component, then a response (rendering) phase where output is written. This has many advantages, the least of which is that variable references on a page are consistent when read from top to bottom - a situation that is not true of JSP. This also allows the page to avoid having to manage the page buffer size, do forwarding, etc. and all that garbage. You have a return component that is rendered - no need to forward.
* JSP is implictly tied to the filesystem by using paths to jsp files to denote a "component" name (all the jsp stuff calls it "page" - revealing it's nature). Other frameworks allow templates to be stored elsewhere (like a database). This JSP mechansim cripples any attempt at doing a runtime selection of template (for example choosing based on a user's chosen display language - not doing this forces you to rely on cumbersome resource bundles for all your i18n).
* Tapestry components can have actions within them that can execute independently of your application - include the component and it will generate the links necessary to perform it's own actions. This is extremely different than the top-level controller approach of most other frameworks (Struts springs up foremost). A result of this is that almost all URL generation is done by the framework - you don't have to specify:
<%= request.getContextPath() %>/myTemplate/whyMe/ohGodWhyMe.jsp
to link to another page - you really shouldn't be concerned with URL generation, I think.
* There are a lot more things that I'm leaving out. Bottom line: Tiles is a taglib for layout and Tapestry is a framework for building component-based applications. Two completely different beasts.
Tapestry represents the leading edge of the new breed of web app frameworks - the component web app frameworks. WebObjects was the pioneer of this model and that framework is as old as the web (WO came out in 1995, I seem to recall). Tapestry is "more component than thou", however :-) and solves some problems that WebObjects does not (like being free :-)
- Drew
--
+---------------------------------+
< Drew Davidson | OGNL Technology >
+---------------------------------+
| Email: [EMAIL PROTECTED] /
| Web: http://www.ognl.org /
| Vox: (520) 531-1966 <
| Fax: (520) 531-1965 \
| Mobile: (520) 405-2967 \
+---------------------------------+
--
To unsubscribe, e-mail: <mailto:general-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:general-help@;jakarta.apache.org>
