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.
[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.
However "result" "success" has nothing to do with the interceptor stack in my
sample. I am trying to see where your concern is coming from.
Also where is this extra maintance in list.vm coming from?
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.
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.
-Matt
-----Original Message-----
From: Henri Dupre [mailto:[EMAIL PROTECTED]
Sent: Monday, May 01, 2006 12:44 PM
To: Tapestry users
Subject: Re: tapastry vs struts
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.
This message, including any attachments, is intended only for the recipient(s)
named above. It may contain confidential and privileged information. If you
have
received this communication in error, please notify the sender immediately and
destroy or delete the original message. Also, please be aware that if you are
not
the intended recipient, any review, disclosure, copying, distribution or any
action or reliance based on this message is prohibited by law.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
