You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Craig R. McClanahan" <Cr...@eng.sun.com> on 2000/06/23 06:07:25 UTC

Re: Difference between Turbine and Struts

I am by no means an expert on Turbine's features, but the following
points highlight some of the differences and similarities.

* Both environments focus on the key goal of the MVC design
  pattern -- separation of business logic from presentation logic
  so that you can update either with minimal impacts on the
  other.

* Turbine is substantially more full-featured in it's approach,
  partly due to its much longer lifetime to date and partly by
  design (for example, it includes connection pools and lots
  of integration with other components).  Struts is very narrowly
  focused on the basic MVC controller function and a
  custom tag library.

* Turbine is somewhat agnostic about what technology you
  use for the presentation layer, although it is best integrated
  (from what I understand) with Webmacro.  Struts is focused
  on working with JSP as the presentation layer.

* Turbine's mechanisms often predate emerging Java standards
  for many types of resources, so it's no surprise that they aren't
  compatible.  Struts will, to the extent it adds any features later,
  be extended in ways that are compliant with the emerging J2EE
  family of API standards.

Turbine is an excellent framework that doesn't really have much synergy
with JSP pages at the moment -- although there is talk of extending in
that direction.  Struts is a new framework (quite good IMHO :-) that is
focused on the synergies that JSP custom tags offer to reduce the
workload of creating web applications, coupled with an implementation of
a good design pattern (same as Turbine's) for the overall application.

Craig McClanahan




XSLT Tag (was Re: Difference between Turbine and Struts)

Posted by David Geary <sa...@tri-lakesonline.net>.
"Craig R. McClanahan" wrote:

> One of the approaches I'm looking at for this is to let you define XSLT
> mappings in your JSP page itself -- something like this:
>
>     <xsl:xslt stylesheet="xxxxx.xsl">
>         ... XML elements to be transformed ...
>     </xsl:xslt>
>
> There is a custom tag somewhat like this in the "jakarta-taglibs" project
> already, but at the moment it deals only with external XML and XSL files -- we
> need an extension for the nesting option above.  There is also work going on in
> the Servlet 2.3 and JSP 1.2 specs that might let you specify things like XSLT
> transformations externally, to be applied for you by the servlet container.
> But that's for the future -- this approach should be feasible now.

I think the tag is a good idea, but as you point out it's likely to be superseded,
perhaps by the JSP standard tag library.

> I am not an XML guru, but it seems to me that any such approach would mean not
> using the "form" series of custom tags, because they render legal HTML syntax,
> but not necessarily legal XML syntax.  Am I missing something here?

The most common use of XSLT in a JSP page is transforming XML into HTML, so in that
case, the form tags can peacefully coexist. If the XSLT transforms XML into
something other than HTML, then the form tags don't make sense anyway.



david


Re: STRUTS DEBUG

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Robert Balahura wrote:

> Are there built in debugging mechanisms to debug classes in struts?  For
> example, to check what values are being retrieved from my FormClass by my
> ActionClass?

There is nothing built in to Struts at the moment to assist in this.

One relatively easy approach might be to subclass ActionServlet with a
special version that overrides the processActionInstance() method.  The
overridden class might look like this:

    protected void processActionInstance(...) throws ... {

        ... log the details of the passed formInstance ...
        super.processActionInstance(...);

    }

One trick I use in my programs (to make this sort of thing easier) is to
implement a toString() method on my ActionForm beans, that dumps out the
interesting contents into the result string.  That way, in my override method
above, I can say something like this:

    getServletContext().log(formInstance.toString());

and the String version of the form bean will get logged to the servlet log,
without the servlet having to know anything about the insides.

Craig McClanahan





STRUTS DEBUG

Posted by Robert Balahura <rj...@sciborg.uwaterloo.ca>.
Are there built in debugging mechanisms to debug classes in struts?  For
example, to check what values are being retrieved from my FormClass by my
ActionClass?


Re: Difference between Turbine and Struts

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Robert Balahura wrote:

> Hi Craig,
>
> Do you have any suggestions for the separation for presentation and content
> using Struts?  My goal is to separate content  and presentation as much as
> struts separates business logic and presentation.
>

One of the approaches I'm looking at for this is to let you define XSLT
mappings in your JSP page itself -- something like this:

    <xsl:xslt stylesheet="xxxxx.xsl">
        ... XML elements to be transformed ...
    </xsl:xslt>

There is a custom tag somewhat like this in the "jakarta-taglibs" project
already, but at the moment it deals only with external XML and XSL files -- we
need an extension for the nesting option above.  There is also work going on in
the Servlet 2.3 and JSP 1.2 specs that might let you specify things like XSLT
transformations externally, to be applied for you by the servlet container.
But that's for the future -- this approach should be feasible now.

I am not an XML guru, but it seems to me that any such approach would mean not
using the "form" series of custom tags, because they render legal HTML syntax,
but not necessarily legal XML syntax.  Am I missing something here?

Craig





Re: Difference between Turbine and Struts

Posted by Marius Sorin Barduta <ma...@necomm.ro>.
Robert,

IMHO, I don't think there are *really* any differences between "separation
of presentation and content"  and "separation of business logic and
presentation". Can you be more specific about what do you mean by the above
terms?

Regards,
Marius

> Hi Craig,
>
> Do you have any suggestions for the separation for presentation and
content
> using Struts?  My goal is to separate content  and presentation as much as
> struts separates business logic and presentation.
>



RE: Difference between Turbine and Struts

Posted by Robert Balahura <rj...@sciborg.uwaterloo.ca>.
Hi Craig,

Do you have any suggestions for the separation for presentation and content
using Struts?  My goal is to separate content  and presentation as much as
struts separates business logic and presentation.


-----Original Message-----
From: Craig R. McClanahan [mailto:Craig.McClanahan@eng.sun.com]
Sent: Friday, June 23, 2000 12:07 AM
To: struts-user@jakarta.apache.org
Subject: Re: Difference between Turbine and Struts


I am by no means an expert on Turbine's features, but the following
points highlight some of the differences and similarities.

* Both environments focus on the key goal of the MVC design
  pattern -- separation of business logic from presentation logic
  so that you can update either with minimal impacts on the
  other.

* Turbine is substantially more full-featured in it's approach,
  partly due to its much longer lifetime to date and partly by
  design (for example, it includes connection pools and lots
  of integration with other components).  Struts is very narrowly
  focused on the basic MVC controller function and a
  custom tag library.

* Turbine is somewhat agnostic about what technology you
  use for the presentation layer, although it is best integrated
  (from what I understand) with Webmacro.  Struts is focused
  on working with JSP as the presentation layer.

* Turbine's mechanisms often predate emerging Java standards
  for many types of resources, so it's no surprise that they aren't
  compatible.  Struts will, to the extent it adds any features later,
  be extended in ways that are compliant with the emerging J2EE
  family of API standards.

Turbine is an excellent framework that doesn't really have much synergy
with JSP pages at the moment -- although there is talk of extending in
that direction.  Struts is a new framework (quite good IMHO :-) that is
focused on the synergies that JSP custom tags offer to reduce the
workload of creating web applications, coupled with an implementation of
a good design pattern (same as Turbine's) for the overall application.

Craig McClanahan