You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Simon Raveh <si...@nominum.com> on 2004/01/26 23:22:46 UTC
struts vs tapestry
hello,
My company is evaluating struts and tapestry for our new web application.
I'm leaning towards tapestry but I'd appreciate a list of the advantages
in using tapestry and the disadvantages of struts.
Thanks,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: struts vs tapestry
Posted by Jamie Orchard-Hays <ja...@dang.com>.
Simon, you might want to search the archives. There have been a few
discussion already about these two frameworks.
Although I was never a Struts developer, my team developed our last
application using it. We evaluated Struts against Tapestry and went
with it. Everyone is very happy about it. They guys who did Struts
before seem to be enjoying Tapestry (as well as enjoying being more
productive), but really do not like going back to the Struts world. One
guy refers to it as something like "going back into the sewer."
I personally absolutely love Tapestry. It is fun, powerful, effective,
reusable, and the community is great. The only really hard part of
Tapestry is learning the life-cycle.
Advantages:
fun
powerful
components
reusable
clean separation of HTML and processing code (this is big if you have
designers that want to do html--there was a great post about this
within the past week)
responsive community
great error reporting
Spindle (for Eclipse)
efficient
the http junk is hidden
Jamie
On Jan 26, 2004, at 5:22 PM, Simon Raveh wrote:
> hello,
>
> My company is evaluating struts and tapestry for our new web
> application.
> I'm leaning towards tapestry but I'd appreciate a list of the
> advantages in using tapestry and the disadvantages of struts.
>
> Thanks,
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: struts vs tapestry
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jan 26, 2004, at 5:22 PM, Simon Raveh wrote:
> My company is evaluating struts and tapestry for our new web
> application.
> I'm leaning towards tapestry but I'd appreciate a list of the
> advantages in using tapestry and the disadvantages of struts.
Heavy on the anti-Struts, rather than pro-Tapestry (but everyone here
is pro Tapestry anyway):
http://crazybob.org/roller/page/crazybob/20040126#struts_1_1_could_use
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: struts vs tapestry
Posted by Chip Turner <ct...@redhat.com>.
Simon Raveh <si...@nominum.com> writes:
> hello,
>
> My company is evaluating struts and tapestry for our new web application.
> I'm leaning towards tapestry but I'd appreciate a list of the
> advantages in using tapestry and the disadvantages of struts.
We're also looking at this choice for a project we'll be starting
soon. In particular, reference Tapestry sites as well as sites using
Tapestry for large deployments (hundreds of dynamic pages, etc) would
be especially useful. I can't find a "Sites Using Tapestry" section
of the Tapestry website, but I may just be looking in the wrong place.
Thanks,
Chip
--
Chip Turner cturner@redhat.com
Red Hat, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: struts vs tapestry
Posted by Jamie Orchard-Hays <ja...@dang.com>.
I think this mirrors our experience here at Darden. Perhaps Erik and/or
Allen will chime in. I hadn't thought about it before but we've adopted that
sort of division of labor among the Tapestry developers as well, Erik being
our current deep-level uber-hacker for the heavier customizations we've
needed. We also chose to keep the ognl out of the html templates for a clean
separation of tasks.
Jamie
----- Original Message -----
From: "Vince Marco" <vm...@mac.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Tuesday, January 27, 2004 9:56 AM
Subject: Re: struts vs tapestry
> Our last project lasted a bit over a year and involved about 10 webapps
> half of which we did in Struts and half in Tapestry. One of the
> problems we delt with is developer rampup, as we only had 2 developers
> out of 4 fluent with Struts and none with Tapestry.
>
> Struts presents MVC to JSP/Servlet development. It is not designed to
> scale incredibly well. As the application grows, so does the
> complexity and management of the struts-config.xml file. It is better
> than JSP development without it, but it does require effective
> management of custom tags. I found it better to use JSTL instead of
> the struts-bean tag lib when possible. Within the MVC model, JSPs
> really aren't very good views, the only role they are used for. The
> reason for this is that this role focuses on rendering dynamic HTML
> tags in the response. JSPs accomplish this by providing a tag
> extension model which get compiled into Java to produce tag output.
> This process effective blurs error traceability through a generated
> servlet layer. This can be countered with JSP-aware debuggers, but
> only in development and often debugging issues from production logs is
> pretty difficult. Also, with tag extension we are asking developers to
> constantly change the language they design and build webapps with,
> making the learning curve difficult.
>
> Tapestry steps in here to solve both of the items mentioned. There is
> some commonality as Tapestry is also MVC-based. However, Tapestry is
> much friendlier to all HTML/XHTML design tools. This made the web
> design run much smoother. The error handling is very precise compared
> to Struts, even in production logs. We found this to cut production
> issue resolution and acceptance testing drastically. We also chose to
> push OGNL statements out of the HTML templates and into the XML
> page/component specs. The objective was to keep the HTML templates as
> simple as possible. We also chose to use XHTML compliant templates,
> which opened up XML editors and XSLT scripts for template editing. I
> highly recommend identifying web developer requirements/tasks and
> applying a minimal set of Tapestry features to those tasks. Not every
> developer, for instance, needs to delve into services and understand
> the full workings of the render cycle, or even component development.
> Tapestry comes with a solid set of components to cover most web
> development. Specialize a developer or 2 on the deeper aspects of
> Tapestry and let other developers establish a productive use of
> existing components and services. Most developers will be very
> productive sticking with existing components, the global, the visit,
> basic render cycle, and action listeners.
>
> From this experience I would say that Tapestry scales very effectively.
> The only place I will use Struts in the future is within a Portal
> application which supports and requires it. I would like to see
> existing commercial Portal frameworks embrace Tapestry while
> maintaining their JSP/Struts-based tag API. That would be cool.
>
> Vince
>
> On Jan 26, 2004, at 3:22 PM, Simon Raveh wrote:
>
> > hello,
> >
> > My company is evaluating struts and tapestry for our new web
> > application.
> > I'm leaning towards tapestry but I'd appreciate a list of the
> > advantages in using tapestry and the disadvantages of struts.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: struts vs tapestry
Posted by Vince Marco <vm...@mac.com>.
Our last project lasted a bit over a year and involved about 10 webapps
half of which we did in Struts and half in Tapestry. One of the
problems we delt with is developer rampup, as we only had 2 developers
out of 4 fluent with Struts and none with Tapestry.
Struts presents MVC to JSP/Servlet development. It is not designed to
scale incredibly well. As the application grows, so does the
complexity and management of the struts-config.xml file. It is better
than JSP development without it, but it does require effective
management of custom tags. I found it better to use JSTL instead of
the struts-bean tag lib when possible. Within the MVC model, JSPs
really aren't very good views, the only role they are used for. The
reason for this is that this role focuses on rendering dynamic HTML
tags in the response. JSPs accomplish this by providing a tag
extension model which get compiled into Java to produce tag output.
This process effective blurs error traceability through a generated
servlet layer. This can be countered with JSP-aware debuggers, but
only in development and often debugging issues from production logs is
pretty difficult. Also, with tag extension we are asking developers to
constantly change the language they design and build webapps with,
making the learning curve difficult.
Tapestry steps in here to solve both of the items mentioned. There is
some commonality as Tapestry is also MVC-based. However, Tapestry is
much friendlier to all HTML/XHTML design tools. This made the web
design run much smoother. The error handling is very precise compared
to Struts, even in production logs. We found this to cut production
issue resolution and acceptance testing drastically. We also chose to
push OGNL statements out of the HTML templates and into the XML
page/component specs. The objective was to keep the HTML templates as
simple as possible. We also chose to use XHTML compliant templates,
which opened up XML editors and XSLT scripts for template editing. I
highly recommend identifying web developer requirements/tasks and
applying a minimal set of Tapestry features to those tasks. Not every
developer, for instance, needs to delve into services and understand
the full workings of the render cycle, or even component development.
Tapestry comes with a solid set of components to cover most web
development. Specialize a developer or 2 on the deeper aspects of
Tapestry and let other developers establish a productive use of
existing components and services. Most developers will be very
productive sticking with existing components, the global, the visit,
basic render cycle, and action listeners.
From this experience I would say that Tapestry scales very effectively.
The only place I will use Struts in the future is within a Portal
application which supports and requires it. I would like to see
existing commercial Portal frameworks embrace Tapestry while
maintaining their JSP/Struts-based tag API. That would be cool.
Vince
On Jan 26, 2004, at 3:22 PM, Simon Raveh wrote:
> hello,
>
> My company is evaluating struts and tapestry for our new web
> application.
> I'm leaning towards tapestry but I'd appreciate a list of the
> advantages in using tapestry and the disadvantages of struts.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org