On 5/1/06, Payne, Matthew <[EMAIL PROTECTED]> wrote:
<table cellspacing="10">
<tr>
<td>ID</td>
<td>Name</td>
<td>Level</td>
</tr>
<tr>
<td colspan="3"><hr></td>
</tr>
#foreach($customer in $customerList)
<tr>
<td>$customer.id</td>
<td>$customer.fullName</td>
<td>$customer.memberLevel</td>
</tr>
#end
</table>
The Tapestry view requires a knowledge of OGNL and the syntatic sugars of
what @Insert(@Update?) is.
In addition, the tapestry view often requires additional binding lingo in
the .page specification file.
Velocity or Freemarkers have their own limitations... To start, I don't know
any HTML editor that willl open that page in wisywyg. And with my experience
with php, writing by hand the #foreach loops in a table is a great door for
breaking a document layout! In our website, everything is table based and
all pages are constantly evolving. When you have several levels of
nested loops, the Velocity/Freemarker templates are becoming weak, as with
the Tapestry tags, I can still load the document inside Dreamweaver, add a
table inside another one without breaking my document. After all the
struggles doing layout with php, I'll never go back to that!
<package name="policy" extends="default" namespace="/securePolicy">
<default-interceptor-ref name="secureStack"/>
<!-- Add your actions here -->
<action name="list" class="
com.pennmutual.csc.actions.PolicyListAction" method="list">
<result name="SUCCESS" type="velocity">list.vm</result>
</action>
</package>
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.vmdocument and you won't be able to have components there... In
tapestry
components are independents... If you look at our website (www.actualis.com),
you'll see that the top plus left sides of the website are context
dependent. With tapestry components, this is completly hidden when we are
developing new pages, all these components are "hidden" and come with the
@Border.
Abstract page and getter/setter wierdness
Agree, this is a little weird but works quite nicely in Tapestry 4.
Heavy API usage to achieve behavior
Don't agree, in tapestry 4, I find the API quite light.
-Action cannot be reused outside of web enviroment
I'm not sure to understand what do you mean by that...
webwork sample below. Note the absence of any Servlet centric object(no
HttpRequest/Session)
These xwork actions can be used by other things outside the serlet
enviroment (e.g. quartz scheduler, osworkflow, or an in-house app)
--->
Ok this is a fact but you can't expect the framework to manage all your URLs
if it is not linked to the servlet somehow. Does webwork separate the URL
management from the pages?
For selecting a web framework, I would try to answer the following
questions:
- what to expect about the maintainance? (long term/short term)
- what is the size of the project? how many pages, short term and long term?
- will the html layouts be straightforward?
- internationalization?
If you are stuck with the project for several years, then the learning curve
might not be the most important factor... But if you are just building a
small website that you won't maintain later, then I can understand that
Tapestry's learning curve might not be worth it.
Henri.
