[prev in list] [next in list] [prev in thread] [next in thread] 

List:       struts-user
Subject:    RE: Advantages of Struts (Model 2 Framework) vs. JSP only approac
From:       Brian Johnson <bj () REALCOMMUNITIES ! com>
Date:       2000-07-31 23:58:29
[Download RAW message or body]

Richard (et al?),

I'm very interested in using the struts framework, but one thing you
mentioned below is a bit disconcerting to me and I'd like to pick your brain
on this a little more if you don't mind?

You said:
--> Cons
--> - Removes ability for graphic designers to provide layout
--> of form in traditional tools such as DreamWeaver

- Is this because DreamWeaver doesn't have (robust?) support for ".tld"
files?
- Is this because DreamWeaver can't interpret the 'form' elements as tags
from a tag library and render them as html form elements for the designer?
- Is this because of some other reason?

I know DreamWeaver is extensible via JavaScript - Would providing an
"HTML-Form-Tag" <--> "Struts Tag Lib" conversion solve this issue?

I haven't started using struts, but I've been lurking about on this list for
a week now just to try and get a heads up to what is going on. I understand
that you use struts JSP tag library form tags within the JSP files to enable
the struts servlet to process (via beans, ejb) the form automatically then
to have a JSP render the resulting page. Am I basically close?

I appreciate the help and information.

Brian Johnson

-----Original Message-----
From: Richard Vowles [mailto:rvowles@sew.co.nz]
Sent: Monday, July 31, 2000 3:21 PM
To: struts-user@jakarta.apache.org
Subject: Re: Advantages of Struts (Model 2 Framework) vs. JSP only
approach


I have been thinking on this and I'd say that I'd break it into pros & cons
(and hopefully Craig will comment <grin>)

Pros
- More strongly encourages the sep. of business logic from presentation
logic.
- Allows for the support of multiple languages through the use of the
resource mechanism
- Views (JSPs) are considerably cleaner
- Whole application is easier to maintain

Cons
- Removes ability for graphic designers to provide layout of form in
traditional tools such as DreamWeaver
- Forces graphic designers and developers to work more closely

A big con for me is that it doesn't work with Resin (IMHO, the best JSP
engine out there) - Scott disagrees with the idea that bodyContent should be
available in doEndTag - the spec apparently implies that it should be only
available until before the beginning of doEndTag (i.e. the last
doAfterBody). Since Struts uses the idea that the bodyContent is available
in doEndTag.... He has asked Sun for a ruling.

I'm encouraging people to do the doAfterBody thing.

I'd like to add two things to Struts:
(1) an option to output in well formed XML instead of HTML (so I can use
XSL-T to convert) and
(2) greater options on the fields - an indication as to what data type it is
for example, and maybe constaints so that the Form bean can be derived from
the page and used as a base class.

Time being the only problem <sigh>

Richard

----- Original Message -----
From: <Richard.Cammarano@ubsw.com>
To: <struts-user@jakarta.apache.org>
Sent: Tuesday, August 01, 2000 2:07 AM
Subject: Re: Advantages of Struts (Model 2 Framework) vs. JSP only approach


> I would like my development group to start using struts for web
> development. Where can I find a list of struts advantages over the more
> traditional JSP only approach? This would help me "sell" the framework
> in my group.
>
> I took a look at readme file in the source, but I am looking for more
> of a comparison of struts vs. jsp only.
>
> I appreciate any information.
>
> Thanks,
> Rich
>
>
> This message contains confidential information and is intended only
> for the individual named.  If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail.  Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
>
> E-mail transmission cannot be guaranteed to be secure or error-free
> as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses.  The sender therefore
> does not accept liability for any errors or omissions in the contents
> of this message which arise as a result of e-mail transmission.  If
> verification is required please request a hard-copy version.  This
> message is provided for informational purposes and should not be
> construed as a solicitation or offer to buy or sell any securities or
> related financial instruments.
>

[prev in list] [next in list] [prev in thread] [next in thread]