John Henry Xu wrote the following on 7/2/2005 6:43 AM:
Is writting
lots of getters and setters manually the most productive way in real
projects?
You keep coming back to this getters and setters thing:) Like I said any
editor (even vim:) can create getters and setters. I take it you think
Struts is all about getters and setters? Seriously, don't take offense
to this, but I'm wondering how many Struts applications you actually
coded? I usually have several ActionForms and some beans which do have
get/set methods. The beans (value objects/dto's) I'd have even if I was
coding an application in Swing/.NET or whatever. So your main thrust
here seems to be about ActionForms and get/set methods? Honestly that's
such a small part of the whole process I still can't believe you are
harping on it. I think we can terminate listening to your posts because
of this statement:
"My experience was Struts have more
codes and configuration files than straight forward JSP+Javabean+taglibs
approach that was done before."
This tells me either:
A) You haven't used Struts much
OR
C) The applications you write using your home-grown approach have to be
quite sucky and would be a royal pain to maintain and refactor as
requirements change.
I make this claim because Struts (and other web application frameworks)
provide ALREADY WRITTEN CODE in jars that you'd have to write YOURSELF
if you didn't use a framework. So, to quote you, - more lines mean more
time and a waste of money. So under your own logic you are costing your
company a TON of money and you might want to think about adopting some
web framework for your developers to start using.
I can get into all the little things web frameworks provide, but here
are some simple questions I have for you that maybe you can answer from
'your experience'...
Where do your forms submit to?
How do you handle/configure where the page forwards to after the request
is sent?
When you need to change the flow of the application (what page forwards
to where) how do you make this change?
How do you handle server side validation problems and display messages
to the user about these server side problems?
If you handled ANY of the above than I will GUARANTEE you that I can
take your SAME application, and not change any of your business logic,
and end up with code that is CLEANER and, most importantly from your
perspective, written in LESS lines.
I truly truly would love for you to zip up a sample of one of your web
applications and let us check out this 'smaller' code base. Please do
it. Pretty please.
I'm sorry if I sound a bit hostile, but I've had this 'argument' with so
many people over the years. They say stuff like "I don't see why use
(insert your favorite web framework), you just complicate things and end
up with more code and configuration files." Then what happens is I see
their code and see all the wasted stuff they are doing that a web
framework provides 'out of the box.' I think the problem is these people
don't see how the framework saves time because they haven't worked with.
Do these frameworks have problems? Yes, they do. I'm not a fan of
ActionForms myself, but I do see their place in the Struts world. JSF
seems to have gotten rid of them. Some frameworks the learning curve
looks too steep for me to invest the time in it (Spring's UI framework
seemed to be one of these back in the day when I first considered it...
the docs sucked). Others out there seem good, but I'm just too
comfortable with Struts to make the change. I can whip out a quality web
app using Struts and iBATIS in practically no time at all. Granted, yes,
Struts has a learning curve, but once you learn it you can apply it to
any app or other apps that are coded with it. Conversely, if we take
your "JSP+Javabean+taglibs only" application it will be much more
difficult for a new person to the application to understand (again, you
are all about saving money so I'm not sure how you can't see how your
home-grown approach will cost you more in the long run).
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
