1) I think the separation of presentation (view) from the model and controller
has gone too far (or probably is not done well in Struts). For example, I like
to have my front end developers do form (field) validation. These developers
should not have to write beans to do this (all examples I've seen so far do
form validation in Java beans). This somewhat contradicts the J2EE development
model where "application developers", who are basically scripters (not OO
developers), do the front end work.
It has not gone too far. If you don't like MVC, you've chosen the wrong tool. You don't need Struts or Java, just use some scripting language like PHP. Form validation is done via an xml config. file and many times there is no code required. This is known as the Validator and is based on the Jakarta commons-validator. You need to subclass ValidatorForm or use DynaValidatorForm.
2) There is just too much junk to write to do a simple form. The samples I've
seen have involve too many files to do a simple form. Plus, why should I have
to write a new bean for each form. Why can't the bean either be generated
automatically or there be a general purpose bean (with properties that are
created dynamically) that works for all forms?
You can do this with DynaForms. You configure each been in struts-config.xml and Struts handles it as if you coded a Java class. This approach leads to 1 config file for beans and the rest of the app (struts-config.xml), 1 config file for validation (validation.xml), and 1 Action class to handle the submitted form.
3) We already separate business logic nicely, usually by encapsulating the
logic in beans or EJBs. By the time the "application developers" get to work
writing JSP/HTML, they are not writing any business logic. So why add the
overhead of Struts (or any other framework)?
JSPs should not talk to EJBs directly, that is a known best practice. Struts is a web tier controller framework for turning web requests into business layer calls.
4) Because we separate out business logic into beans and EJBs, Java is simply
used as a scripting langauge in our JSPs - in just the same way that VBScript
is used in Active Server Pages. We try not to confuse the object oriented
language called Java, with the scripting language called Java that we use in
JSPs. We use a very small subset of Java in JSPs.
There is no Java scripting language, there is only Java the OO language. Using scriptlets in JSPs is now considered an obsolete technique for many reasons you can find on the net.
5) Based on #4, I don't particularly care for taglibs either. Again, we are
simply using Java to do simple scripting. Loops are probably the most complex
thing we do. So why add the extra overhead of taglibs. A loop is a loop
whether it has the syntax of Java or a taglib. Plus, if I want my front-end
developers to get any experience with serious development, I'd rather have them
dealing with Java as opposed to taglibs, which have no value in the real world
of programming.
I'm not sure what you mean by this; Java webapps are "real world" programming. The JSTL provides a common set of reusable taglibs that all Java web programmers are expected to know.
6) Performance is unknown. I've looked through the mail archives and have seen
requests for performance figures, but no answers (plenty of folks pushing
Struts though).
Performance is known to be quite good but no one has taken the time to get actual numbers. Feel free to do this analysis and let us know the results. The only reason people push Struts is because they've found it useful and are excited about using it. Struts will most definitely not be the weakest link in your webapps performance. Database access and network speeds are usually the 2 slowest components.
It sounds like you have the wrong expectations for Struts/Java web programming. This is not designed as a scripting environment. MVC webapps are designed to solve the numerous maintenance and productivity problems associated with scripted apps in PHP, ASP, Perl, etc.
David
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
