Feedback on Struts Pros and Cons
All, I work with a company that is new to Java and we are evaluating tools for a standard J2EE architecture. One of the Model 2 approaches we are looking at is Struts. After spending some time evaluating Struts, I have assembled the attached list of pros and cons, but would like to get some impartial third party feedback. If anyone sees anything I missed, I would appreciate your insights. Thanks! -David -- Struts Advantages: 1. Provides a controller ActionServlet that dispatches requests to the appropriate business actions (Action subclasses) provided by the application developer. All dispatching is defined in an XML file (struts-config.xml). 2. Supports internationalization of messages and prompts. 3. Provides message collections that can be easily displayed in a subsequent JSP/Servlet. 4. Allows the input (data entry) JSP/Servlet to be specified for each Action subclass, so control can be returned to that JSP/Servlet in the case of an error. 5. Provides custom tags to delegate many of the JSPs' HTML commands and Servlets' println statements to tag libraries. 6. Automates population of the JSP domain object (ActionForm subclass) with input data. 7. Allows data entry validation (ActionForm subclass) and business logic (Action subclass) to be decoupled from the presentation JSPs/Servlets. 8. Data validation can be turned on or off in web.xml. Struts Disadvantages: 1. Instead of direct dispatching by controller Servlet(s), dispatching is defined in an XML file, adding a layer of indirection overhead to the architecture. 2. Requires behavior typically factored for commonality in controller Servlet methods to be duplicated in every Action subclass (some common behavior could possibly be delegated to additional classes or components and accessed by each Action subclass). 3. Struts internationalization is limited to static strings and does not include internationalization of data returned by a business component. 4. Struts internationalization requires an ApplicationResources.properties file, which conflicts with the current Enterprise Java Application Standard of definely properties directly in the web.xml file. 5. Presentation of message collections is predefined in tag libraries (although these could be modified for more specialized presentation). 6. Requires understanding of custom tags and tag libraries, as well as their deployment. While this may not be a problem for more advanced developers, this will add another layer of complexity for less experienced development and support teams and requiring more intensive EAS involvement. 7. Delegating much of the presentation layer to custom tags can make the final HTML/presentation less clear than HTML placed directly in the JSPs/Servlets. 8. Data entry validation is toggled on/off on a global basis only (not on a per JSP/Servlet basis). 9. Requires recompilation and redeployment when data entry validation or business component invocation changes. This is unnecessary if data entry validation and business component invocation is performed in a JSP. 10. Requires at least one additional class per deployed page: an Action subclass to invoke the corresponding business component or model behavior and forward control to the subsequent JSP/Servlet. Fewer classes are required if this behavior is performed within the controller Servlet. 11. Struts applications, with their Action and ActionForm subclasses and the struts-config.xml file, add additional development and deployment complexity that may be too difficult for less experienced developers to grasp. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Feedback on Struts Pros and Cons
David Bueche [EMAIL PROTECTED] wrote: Struts Disadvantages: 1. Instead of direct dispatching by controller Servlet(s), dispatching is defined in an XML file, adding a layer of indirection overhead to the architecture. Do you really think, this is an disadvantage? 2. Requires behavior typically factored for commonality in controller Servlet methods to be duplicated in every Action subclass (some common behavior could possibly be delegated to additional classes or components and accessed by each Action subclass). There is still the possibility to subclass ActionServlet and so create own controller. 3. Struts internationalization is limited to static strings and does not include internationalization of data returned by a business component. A bit can be achieved with the placeholders in constant strings. 4. Struts internationalization requires an ApplicationResources.properties file, which conflicts with the current Enterprise Java Application Standard of definely properties directly in the web.xml file. Struts does not use ApplicationResources.properties as real properties. The file is used only as a handy tool for peristing string maps. In our projects we use database backed internationalization with struts. 5. Presentation of message collections is predefined in tag libraries (although these could be modified for more specialized presentation). 6. Requires understanding of custom tags and tag libraries, as well as their deployment. While this may not be a problem for more advanced developers, this will add another layer of complexity for less experienced development and support teams and requiring more intensive EAS involvement. 7. Delegating much of the presentation layer to custom tags can make the final HTML/presentation less clear than HTML placed directly in the JSPs/Servlets. 8. Delegating much of the presentation layer to custom tags can become a performance problem. -- gR -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Feedback on Struts Pros and Cons
Hi, I've just finished building a prototype using Struts and talking to EJB session beans at the back end and can give you a brief sum up of my own practical experiences without answering you point for point : The chief adavantages are : simplified error handling (some) / easy internationalisation / automatic form handling - think of validation and parameter retrieval / ready-made tag libraries for code-free JSPs / localisation of all action handling Incidentally some of the disadvantages you list are trivial : almost every servlet based framework I've worked with requires at least one class to be programmed per action. A Struts tip : think in terms of Actions not pages; so actions can be reused by many pages And.. Data entry validation can be toggled per JSP (per form actually; you simply don't implement the validate method if you don't want it!) Disadvantages are : - only for JSP / servlets - a relatively steep learning curve (but thereafter vastly improved productivity) - you're bound to the Struts tag libs if you use them (which you should). If you ditch Struts you can start layouting again -:) - (your point )internationalization is limited to static strings Cheers Anthony PS I only subscribed to this newsgroup today and the messages are all streaming into my mailbox. I's there a !@#$%%%$#@ newsgroup where on can anser this sort of thing using a normal newsgroup reader? -Original Message- From: David Bueche [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, October 31, 2001 2:23 PM To: [EMAIL PROTECTED] Subject: Feedback on Struts Pros and Cons All, I work with a company that is new to Java and we are evaluating tools for a standard J2EE architecture. One of the Model 2 approaches we are looking at is Struts. After spending some time evaluating Struts, I have assembled the attached list of pros and cons, but would like to get some impartial third party feedback. If anyone sees anything I missed, I would appreciate your insights. Thanks! -David -- Struts Advantages: 1. Provides a controller ActionServlet that dispatches requests to the appropriate business actions (Action subclasses) provided by the application developer. All dispatching is defined in an XML file (struts-config.xml). 2. Supports internationalization of messages and prompts. 3. Provides message collections that can be easily displayed in a subsequent JSP/Servlet. 4. Allows the input (data entry) JSP/Servlet to be specified for each Action subclass, so control can be returned to that JSP/Servlet in the case of an error. 5. Provides custom tags to delegate many of the JSPs' HTML commands and Servlets' println statements to tag libraries. 6. Automates population of the JSP domain object (ActionForm subclass) with input data. 7. Allows data entry validation (ActionForm subclass) and business logic (Action subclass) to be decoupled from the presentation JSPs/Servlets. 8. Data validation can be turned on or off in web.xml. Struts Disadvantages: 1. Instead of direct dispatching by controller Servlet(s), dispatching is defined in an XML file, adding a layer of indirection overhead to the architecture. 2. Requires behavior typically factored for commonality in controller Servlet methods to be duplicated in every Action subclass (some common behavior could possibly be delegated to additional classes or components and accessed by each Action subclass). 3. Struts internationalization is limited to static strings and does not include internationalization of data returned by a business component. 4. Struts internationalization requires an ApplicationResources.properties file, which conflicts with the current Enterprise Java Application Standard of definely properties directly in the web.xml file. 5. Presentation of message collections is predefined in tag libraries (although these could be modified for more specialized presentation). 6. Requires understanding of custom tags and tag libraries, as well as their deployment. While this may not be a problem for more advanced developers, this will add another layer of complexity for less experienced development and support teams and requiring more intensive EAS involvement. 7. Delegating much of the presentation layer to custom tags can make the final HTML/presentation less clear than HTML placed directly in the JSPs/Servlets. 8. Data entry validation is toggled on/off on a global basis only (not on a per JSP/Servlet basis). 9. Requires recompilation and redeployment when data entry validation or business component invocation changes. This is unnecessary if data entry validation and business component invocation is performed in a JSP. 10. Requires at least one additional class per deployed page: an Action subclass to invoke the corresponding business component or model behavior and forward control to the subsequent JSP/Servlet
DB driven i18n was Feedback on Struts Pros and Cons
gR, could you shed some light how you are using a DB backend for i18n w/ struts? Sounds interesting. -Craig 4. Struts internationalization requires an ApplicationResources.properties file, which conflicts with the current Enterprise Java Application Standard of definely properties directly in the web.xml file. Struts does not use ApplicationResources.properties as real properties. The file is used only as a handy tool for peristing string maps. In our projects we use database backed internationalization with struts. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DB driven i18n was Feedback on Struts Pros and Cons
I'm interested in this as well as I was thinking of developing such a thing by extending the MessagesResource and MessageResourcesFactory objects. -james [EMAIL PROTECTED] http://www.ejcenter.com/struts/ --- [EMAIL PROTECTED] wrote: gR, could you shed some light how you are using a DB backend for i18n w/ struts? Sounds interesting. -Craig 4. Struts internationalization requires an ApplicationResources.properties file, which conflicts with the current Enterprise Java Application Standard of definely properties directly in the web.xml file. Struts does not use ApplicationResources.properties as real properties. The file is used only as a handy tool for peristing string maps. In our projects we use database backed internationalization with struts. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Feedback on Struts Pros and Cons
This is actually quite good, but I'm a nit-picker ;-)
David Bueche wrote:
1. Provides a controller ActionServlet that dispatches requests to the appropriate
business actions (Action subclasses) provided by the application developer. All
dispatching is defined in an XML file (struts-config.xml).
Personally, I don't consider Action subclasses to be business objects.
Rather, they should be used to invoke business method. They are an
adapter between HTTP and the rest of your application.
See also Section 2.5 of the User Guide
http://jakarta.apache.org/struts/userGuide/building_model.html#business_logic
[Arrange] things so that your Action classes (part of the Controller
role, as described below) translate all required information from the
HTTP request being processed into property setter calls on your business
logic beans ... Such a business logic class can be reused in
environments other than the web application for which they were
initially constructed.
2. Supports internationalization of messages and prompts.
True. You might specifically mention error messages, since that is the
central role of the i18n features.
3. Provides message collections that can be easily displayed in a subsequent
JSP/Servlet.
Isn't this really part of 2?
4. Allows the input (data entry) JSP/Servlet to be specified for each Action
subclass, so control can be returned to that JSP/Servlet in the case of an error.
Not exactly. The JSP's specify an ActionMapping. If automatic validation
is used, this mapping should include an input path (URI) to use in the
case of an error. This may or may not be the JSP that submitted the
form.
5. Provides custom tags to delegate many of the JSPs' HTML commands and Servlets'
println statements to tag libraries.
The JSP already handle the println part. The custom tags replace
scriptlets, and simplify access to framework resources, like the
localised labels and messages.
6. Automates population of the JSP domain object (ActionForm subclass) with input
data.
This is also a big part of what the custom tags do.
7. Allows data entry validation (ActionForm subclass) and business logic (Action
subclass) to be decoupled from the presentation JSPs/Servlets.
True, modified by (1).
8. Data validation can be turned on or off in web.xml.
Not true. The validate switch is really a misnomer, and refers to the
format of the Struts configuration file. Validation can be controlled on
a mapping by mapping basis (as discrete as it gets).
Struts Disadvantages:
1. Instead of direct dispatching by controller Servlet(s), dispatching is defined in
an XML file, adding a layer of indirection overhead to the architecture.
I would say that the indirection is a good thing, since it decouples
your architechture from physical URIs. The mappings are all logical
URIs, and all the supporting classes and JSPs can be changed without
changing the names used by any of the mappings.
The mappings actually reduce overhead, since they allow the use of
light-weight actions rather than deploying another servlets for every
task.
2. Requires behavior typically factored for commonality in controller Servlet
methods to be duplicated in every Action subclass (some common behavior could
possibly be delegated to additional classes or components and accessed by each Action
subclass).
Not true. Actions are very easy to subclass, and most people do.
3. Struts internationalization is limited to static strings and does not include
internationalization of data returned by a business component.
Struts doesn't limit internatonalization in any way. Your business
components are free to internationalize data in any way it likes. If you
have another i18n system, the message resource object could be
subclassed to use that instead. The design is based on an interface, so
any backend object could be used.
The Sstrings are also not static, but templates that accept
replacement parameters. To write a message from whole cloth, simply
design a key like
error.dynamic = {0}
in the Application Resoources.
4. Struts internationalization requires an ApplicationResources.properties file,
which conflicts with the current Enterprise Java Application Standard of definely
properties directly in the web.xml file.
So how does that work when you need to define several hundred properties
for several different locales?
5. Presentation of message collections is predefined in tag libraries (although
these could be modified for more specialized presentation).
Why is this a disadvantage?
6. Requires understanding of custom tags and tag libraries, as well as their
deployment. While this may not be a problem for more advanced developers, this will
add another layer of complexity for less experienced development and support teams
and requiring more intensive EAS involvement.
True. But I don't know if throwing more money into maintaining Scriplets
is a better option ;-)
I would venture to say that
Re: Feedback on Struts Pros and Cons
Anthony Chater wrote: I only subscribed to this newsgroup today and the messages are all streaming into my mailbox. I's there a !@#$%%%$#@ newsgroup where on can anser this sort of thing using a normal newsgroup reader? Sadly not. No one has ever volunteered the resources to sponsor Jakarta newsgroups. There is a digest version of the list. See the additional commands footer for details. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Feedback on Struts Pros and Cons
In MVC nomenclature consider ActionServlet as the controller and Action and the Validation Framework as controller extensions (I used these names as class names in old projects before I discover struts), so business dosn´t fit here. And thinking a little, it isn´t a good idea to put business logic here (routing and domain validation isn´t business), as these code will be coupled with struts (and servlet and web). Because actions decides which commands to execute, decides where to go next and prepares the environment for jsp view rendering, I think I can call it controller extension. Ted Husted wrote: This is actually quite good, but I'm a nit-picker ;-) David Bueche wrote: 1. Provides a controller ActionServlet that dispatches requests to the appropriate business actions (Action subclasses) provided by the application developer. All dispatching is defined in an XML file (struts-config.xml). Personally, I don't consider Action subclasses to be business objects. Rather, they should be used to invoke business method. They are an adapter between HTTP and the rest of your application. See also Section 2.5 of the User Guide http://jakarta.apache.org/struts/userGuide/building_model.html#business_logi c [Arrange] things so that your Action classes (part of the Controller role, as described below) translate all required information from the HTTP request being processed into property setter calls on your business logic beans ... Such a business logic class can be reused in environments other than the web application for which they were initially constructed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
