Yes, we should be passing an API context object instead of tucking things away here and there in the various contexts. We started work on one during the 1.1 march, but it was sidetracked by the module initiative. At this point, it will probably be slated for Stuts 2.0.

The other questions speak to whether you want to take a declarative approach to writing a web application. If you are writing a small application, the strategy of using XML configurations to deploy object graphs can be more trouble than it's worth. But if you are writing a larger application, most developers believe it is much better than the alternatives. (Been there, done that.) Of course, your mileage may vary.

There are several other web application frameworks available, most of which are tracked by the wafer project.

Choosing a framework is like choosing shoes. You really need to try them on for yourself to be sure.

Like most software products, Struts is far from perfect. But, like Java itself, for complex enterprise applications, many developers find it's the best alternative available today. Neither Struts nor Java is the best choice for all applications and all teams, but most people do find that it is a good choice for larger applications that need to be maintained and improved over time.

If there is a disadvantage to using Struts, it's that the underlying design is so darn useful that people try to use it as an application framework rather than a WEB application framework. Many teams invest *way* too much business logic in ActionForms and Actions. Why? Because most large application do need to utilize the Context and Command patterns. But because they don't have a distinct business framework, people usurp the Struts classes.

The Chain of Responsibility package in the Commons Sandbox is a first step toward creating a business layer framework. Webwork is doing something similiar with their xwork package.

-Ted.

Robert H. Tran wrote:
I am not sure that is true. Struts seems to lack of an API. IMO, there are
more required configurations than necessary. Take Action for example, to
write an Action, one has to paddle back and forth between the code and the
configuration. It is like an executable having to configure each of its
dlls. The visibility of the mappings is nice to have but the mappings can
be generated after the fact as in a debugging view. When the application is
finished, configurations become static. But since configurations are
required, they will be like loose ends of the application. Another issue:
how can one componentize his code and deploy it in a self-contained plug-in,
as with Eclipse? Please forgive my novice.

- Robert.

----- Original Message ----- From: "Rick Hightower" <[EMAIL PROTECTED]>
To: "'Struts Developers List'" <[EMAIL PROTECTED]>
Sent: Wednesday, December 03, 2003 6:24 PM
Subject: RE: Disadvantages of Struts?




Don't be silly. Struts is perfect.

-----Original Message-----
From: Robert H. Tran [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2003 2:10 PM
To: Struts Developers List
Subject: Disadvantages of Struts?

I just wonder if Struts comes with any significant drawback. I mean not in
terms of when to use Struts and when not to use it necessarily, but more

in


the line of anyone's wishes that it had been better. Any advice is very
appreciated.




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to