On 5/1/06, Payne, Matthew <[EMAIL PROTECTED]> wrote:

Thanks for the response Henri,
I appreciate you stepping up to the plate with a response.


[quote] To start, I don't know
any HTML editor that willl open that page in wisywyg
[/quote]

Don't think this is a big issue.
What does an xhtml editor say when you try to validate your pages with
tapestry attributes?

Take the sample below

<tr jwcid="@For" source="ognl:customerList" value="ognl:customer"
element="tr">
   <td><span jwcid="@Insert" value="ognl:customer.id"/></td>
   <td><span jwcid="@Insert" value="ognl:customer.fullName"/></td>
   <td><span jwcid="@Insert" value="ognl:customer.memberLevel"/></td>
</tr>

Vs.

#foreach($customer in $customerList)
<tr>
   <td>$customer.id</td>
   <td>$customer.fullName</td>
   <td>$customer.memberLevel</td>
</tr>
#end

Neither is going to render live rows in an editor.  In addition the first
is more obscure to look at.



This


<tr jwcid="@For" source="ognl:customerList" value="ognl:customer"
element="tr">
  <td><span jwcid="@Insert" value="ognl:customer.id">id</span></td>
  <td><span jwcid="@Insert" value="ognl:customer.fullName">Name</span></td>
  <td><span jwcid="@Insert" value="ognl:customer.memberLevel
">Beginner</span></td>
</tr>

will render correctly in any html editor. I find this a very powerful
feature, our web designer can still open our tapestry pages in dreamweaver
and directly tweak on them.




[quote]Although the interceptor concept is great, "<result name="SUCCESS"
type="velocity">list.vm</result>" sounds weak to me.
I just can't imagine how difficult it would be to maintain that
list.vm document and you won't be able to have components there

[/quote]

I wouldn't discount interceptors as weak, in practice they have been
proven to be more "agile" than an inheritance model.
Spring make great use of the concept. Though inheritance may more still be
more appropriate in certain circumstances.


Oh I was rather refering to their implementation in webwork. It seems that
on success they only render a specific page. I find this a little weak
compared to pages in Tapestry...




I looked at www.actualis.com.
The same type of layout separation can be achieved with Sitemesh(see
http://www.opensymphony.com/sitemesh/index.html).  list.vm can be very
plain/vanilla and a sitemesh decorator can take care of wrapping css and a
menu structure around simple pages.


Components in Tapestry are much more powerful than just templates and
decorating... We have around 40-50 components from low level (rendering a
link) to high level (page layout). Everything in the same framework, there
is no need or an external framework. Sitemesh relies on JSP which do have
their own weaknesses. I won't argue that you can't do  a same website in
tapestry and in other frameworks but in the end I find that the structure of
the tapestry application improves reuse and maintenance.




e.g.

  <decorator name="shoppingCart" page="layout.vm">
                       <pattern>/cart/*.action</pattern>
          </decorator>

   <decorator name="admin" page="adminLayout.vm">
                       <pattern>/admin/* </pattern>
           </decorator>


Sitemesh decorators can also examine meta content with the child pages to
supply context relative information.


That is behind Tapestry components... All the context is available in the
compoents without any addition. Writing a form in a component is
straightforward... not sure how this translates in decorators.

Henri.

Reply via email to