Here are my concerns with Tapesty.
Please feel free to debate these points.
I am still trying to feel my way through. If I am wrong on a point or there is
a better way let me know.
-->
The "view" is proprietary.
While I agree, in not having java scriptlet code in the view, I believe the
same simple view can be achieved with simple templating languages like velocity
or freemarker. Tapesty's view does not offer absolute/complete protection from
an html author stomping on it.
A framework that supports multiple result types(e.g. freemarker, jsp, velocity,
xslt, jasperreports, jax-rpc, or custom) doesn't lock you in.
There are often times you may need to produce a pdf/excel result, doing so
should not be an uphill battle.
This type of flexiblity helps bridge the gap with existing applications. If
you are converting a struts application that used velocity, you don't have to
completetly throw away the view.
The view is appears slightly "more" verbose than needed.
compare snippet:
<table cellspacing="10">
<tr>
<td>ID</td>
<td>Name</td>
<td>Level</td>
</tr>
<tr>
<td colspan="3"><hr></td>
</tr>
<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>
</table>
vs.
<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.
Tapestry page(Actions) are based on inheritance(same complaint about struts).
Instead of simply implementing an interface, basing your stack on inheritance
can be less flexible to change and more dependent on a library and implicit
behaviors.
I tried finding best practice type apps with tapestry. In looking at "better
petshop", I found a development model when most "Pages" extended SecurePage
e.g.SecurePage extends--> PetshopBasePage extends --->BasePage
The same type of secure behavior could be achieve in Webwork via interceptors.
This way actions are unaware they are secure and actions can be redeployed
elsewhere with behavior turned off.
sample below (note there are a couple other ways of expressing this).
<interceptor-stack name="secureStack">
<interceptor-ref name="security"/>
<interceptor-ref name="defaultStack"/>
</interceptor-stack>
<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>
vs
<package name="policy" extends="default" namespace="/openPolicy">
<default-interceptor-ref name="defaultStack"/>
<action name="list" class="com.pennmutual.csc.actions.PolicyListAction"
method="list">
<result name="SUCCESS" type="freemarker">list.flt</result>
<result name="CANCEL" >/home.jsp</result>
</action>
</package>
The use of interceptors allows all sorts of configurable pre/post processing
Abstract page and getter/setter wierdness
While I see that it is an initiative for Tapestry 5.0, these abstract actions
are not quite pojo driven development.
I also see difficulties doing things like wiring AOP advice via spring(though
dependencies can still be wired), since an abstract class can not be
instantiated directly.
Heavy API usage to achieve behavior
-in the way and adds learning curve
-Action cannot be reused outside of web enviroment
vs. simple pojo based actions
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)
--->
pkg
imports
<!--- you could also just implement "Action" -->
class CustomerAction extends BaseAction implements PersistanceAware {
private List customerList;
private Customer customer;
PersistanceManager manager;
public void SetPersistanaceManager(PersistanaceManager _pm) {
this.manager = _pm;
}
public List getCustomers() {
if (customerList !=null) {
customerList = manager.findAll(Customer.class);
}
return customerList();
}
public String list() {
return SUCCESS;
}
public String save() {
manager.saveOrUpdate(customer);
addActionMessage(getText("object.save.success", customer.id));
return SUCCESS;
}
public void validate() {
// this is not the only way to do validation simple field validation
if(customer.name==null || customer.name.length<1) {
addActionErrror(getText("customer.name.required"));
}
}
public String view() {
if (customer!=null && customer.id != null) {
customer =(Customer)manager.load(Customer.class, customer.id);
} //else assume we are doing a new/edit
return SUCCESS;
}
get/setCustomerHere---
}
-----Original Message-----
From: Jonnalagadda, Sumithra [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 25, 2006 10:08 PM
To: tapestry-user@jakarta.apache.org
Subject: tapastry vs struts
We are currently evaluating different frameworks to build our e-commerce
site.
Struts
Pros : huge user base and hence good support
Cons : its stagnant.
Tapestry :
Pro : component based development
Cons : not as big user base as struts.
These are the preliminary points I could gather till.
More experienced ones can you please help me make the right decision by
sharing your experinces.
Thanks
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]
