Don Brown wrote the following on 12/2/2005 12:44 AM:
When we started Struts Ti, it was conceived as a new
framework that aimed to simplify the developers life requiring no
configuration,
What??!!!! No configuration? You mean you aren't using the Spring/ EJB/
JASS/ RMI/ Hibernate/ JMS/ Struts/ Maven/ XDoclet/ Ajax/ AspectJ/
WebServices/ 1050 XML confif files/ KitchenSink solution? That framework
must suck.
But all kidding aside, that's my biggest complaint right now with Java
solutions that seem to be pushed - Too many 'extra' parts that you need
and lack of good documentation and/or examples in getting started.
Even when I taking my first stab into JSF a few months ago, I was quite
annoyed with having to go to several different web sites to get what I
needed, and even then, there was little documentation on how to
integrate everything. Now granted Craig and the others on the MyFaces
list were more than helpful, but I certainly can see how someone new to
choosing a JSF solution would be really overwhelmed. You don't just go
get "JSF" - you have to get a JSF implementation like MyFaces and then
also probably get Shale. But regardless, look how difficult the process
is... put yourself in the 'newbie' shoes. You hear the buzz word JSF so
you decide to google it. Go ahead put in "JSF" in google. What do you
get? Well one of the hits near the top is JSFCentral so you go and click
on that link http://www.jsfcentral.com/ That home page doesn't help
much for just getting started, you try some other sites (ignoring the
military ones). Next there is one on JSF-Spring.. newbie thinking "Oh
great, more confusion, I need to use Spring with this?." Well scroll
though the Google results yourself and start clicking on some links -
It's darn confusing to someone wanting to try and use the technology.
"Hmmm there's this Oracle stuff, there's this MyFaces stuff I keep
seeing... Hmm there is Shale stuff and I see Spring mentioned." I
understand JSF is a reference and not an implementation but I'd love to
get some focus group surveys going on with 'new developers' and give
them a day to explore the web with just the question "Figure out how to
get started coding a JSF application."
Even the examples out there for JSF applications aren't that great. Even
the MyFaces ones often break (hit the browser refresh button when going
through them). I understand, as has been mentioned numerous times
before, that JSF take a different mindset. To quote Craig:
<quote>
Fundamentally, in the Java-based web application architecture space, two
schools of thought are emerging as very popular ... an "action framework
based approach" (Struts 1.x, WebWork, Spring MVC, ...) and a "component
based approach" (JavaServer Faces, Tapestry, ASP.Net, ...).'
</quote>
I agree that both are viable and *I actually do LIKE* JSF - I'm not here
to bash it and I look forward to watching it progress. I would disagree
though with the statement that I believe many in the latter camp above
are claiming: that JSF is 'easier' to pick up for a newbie. I'm not
going to say that it will be 'more difficult' to learn, but I wouldn't
say it will be easier either. I guess if you know Zero about the servlet
api (basic request/response) stuff and you are using a JSF GUI designer
tool, then yea, for a basic app, I'm guessing JSF might be quicker. Do I
have empirical evidence to make this claim? No I do not. However, I've
worked with people over enough time on the Struts list to notice where
most of the questions come from. I still firmly believe that once we see
a lot of 'average-to-new' developers coding with JSF, that we'll see
just as many questions as you see new struts developers post. I
obviously can't state that as 'fact' but I'll be willing to bet that the
learning curve will end up about the same (assuming little Servlet
programming experience.. if someone has a decent amount of JSP/Servlet
programming experience, I'd actually tip to the side that Struts will be
easier to pick up).
I sort of digressed a bit with my above JSF comments. My point was that
I'm frustrated with the current trend that seems to push for the
inclusion of more and more 'stuff' into J2EE applications. Sure, some of
it is necessary, but some of it isn't. (Do I really need 50 Factory
objects in the event my web app becomes a Swing app in the future? Do I
really need 25 layers and 30 XML files to get to a DAO? Do I really have
to be injecting so much stuff at runtime?).
It's sort of funny.. for the heck of it, I pulled out my old JSP book
"Web Development with JavaServerPages by Fields/Kolb (Manning)" and
looked back at their simple example of a web application. The example
has one main servlet controller you submit to and you pass in the
request the name of a Command object which gets looked up in a Map and
execute called on it. Basically, in a sense, the concept isn't much
different from Struts. Someone that understands Java and understands the
Servlet API can see what's going on very easily. THIS is my big sticking
point with some of the new technologies. What is "going on" beneath the
covers becomes so far removed from the developer that I think we end up
making things more difficult instead of easing the burden on developers.
I could be totally wrong of course, but it's just my current perception.
How many times have you started coding using a new technology
implementation and you couldn't figure out why something wasn't working
right. Your options become a) google b) keep trying different things c)
ask on a mailing list or d) get out your debugger and start going
through a million files that are contained in the jars you downloaded
and hope you don't have a lot of injection stuff going on.
Don't get me wrong, I like using open source technologies to aid me. I
really don't feel like going back to coding JDBC by hand. I don't want
to be typing out.println(" ...") or even <%= %> in a JSP either. I do
tend to think, however, that Java apps many times tend to be bloated
with "too much" stuff. For the past three months I started working on a
client side (windows forms) .NET app written in C# and I have to admit,
other than the lack of some nice logging functionality, I was blown away
by the ease in which most everything was *there for me* provided by the
.NET framework. It was very nice.
This is why I was always against the idea of removing things from Struts
like Tiles (when talk of that was buzzing around). I don't think most
new developers enjoy having to hunt around the web in order to find
components they need to really make the progress they want. I also don't
think the framework should 'require' their use or prevent someone from
using a third party package, but the basics should all be there for
quickly getting started.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
