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 "
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 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 DA? 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.

Preach on, brother Rick! :)

I think your arguments about simplicity are very cogent. I think too
often, people mistake having to do less work for something being more
simple. Simplicity, to me, is being able to fully understand what it is
I'm doing, not necessarily having to do less of it. This is the failing I
see in a great many things we're all playing with today, be is JSF, JSTL,
Struts, Spring, Hibernate or any of 100 other things we could all name.

AMEN!

Less Code <Simple

In my experience, over-complexificationialzing in the name of writing
less code always makes for more cost.

Larry

12/2/05, Frank W. Zammetti <fzlists (AT) omnytex (DOT) comwrote:
Preach on, brother Rick! :)

I think your arguments about simplicity are very cogent. I think too
often, people mistake having to do less work for something being more
simple. Simplicity, to me, is being able to fully understand what it is
I'm doing, not necessarily having to do less of it. This is the failing I
see in a great many things we're all playing with today, be is JSF, JSTL,
Struts, Spring, Hibernate or any of 100 other things we could all name.

Crap! You are going to move that chain junk into WebWork? Do they know that?

12/1/05, Don Brown <donald.brown (AT) gmail (DOT) comwrote:
Well, considering I started work a couple of hours ago, no, nothing yet :)
I can tell you my approach I thought of today - replace the WebWork
ServletDispatcher with a Common-Chain RequestProcessor then weave in a
command or two that detects what type of action is being called, and
delegates to the appropriate chain. I'm hoping to even use Struts Action
1.3 as a dependency at first, so you have 100% Struts 1.x functionality, yet
you can start migrating sections to Struts Ti (WebWork) as you have time.

The Struts Ti repository is here:
I'll be adding a
phase1 directory with the code.

If you are interested in Struts Ti, I'd highly recommend pulling down
WebWork and giving it a spin. You could also swing by your local bookstore
and thumb through the excellent WebWork in Action book from Manning :)

Don

12/1/05, Rahul Akolkar <rahul.akolkar (AT) gmail (DOT) comwrote:

Don, Ted -

Any of this in sandbox yet? Where should I be looking? Trying to line
up some weekend reading

-Rahul

To unsubscribe, e-mail: user-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: user-help (AT) struts (DOT) apache.org
>
>
>
>

What I don't understand is why JSF was built when there was Tapestry?
Is there an explanation for that?

12/2/05, Rick Reumann <struttin (AT) reumann (DOT) netwrote:
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 "
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 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 DA? 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.
--

A framework, according to the GoF, is a set of cooperating classes
that make up a reusable design for a specific class of software.

A toolkit, according to the GoF, is a set of related and reusable
classes designed to provide useful general purpose functionality.

Essentially, struts has decided to do away with the original
framework, substitute in a toolkit that does chaining and jump in bed
with another framework that is totally unrelated.

The justification for all this strange conduct is that everything is
really an application. Everything is not an application. Frameworks
have their own qualities

The history is not right either. JSF was an old deal with Sun and was
sinking into the sunset years ago when Craig was asked to come aboard.
Some time later, a long, long time ago, JSF was out but without any
following. Hence, Craig decided to try to zip up the product by
"borrowing" the Struts branding. That allowed JSF to act like it was
new, and has even been described as "cutting edge", which is
hilarious, and to get a hearing.

This was not a case where a bunch of people in Struts decided that JSF
was the cat's meow and wanted to go that way. Most of the people
involved with JSF are transplants with no idea what Struts is about.
They are tool people looking for a tool fix; a Visual Basic sort of
coding framework.

Anyway, a framework is not a "semi-complete application". Next we
will hear that TCP/IP is a "semi-complete application". Some
distinctions are intelligent and should be kept.

12/5/05, Ted Husted <ted.husted (AT) gmail (DOT) comwrote:>
<snip>
IMH, I don't see the engineering value-add of a "one size fits all"
framework. A framework is a semi-complete application, and action/page
applications are built differently than event/component frameworks.
Since the applications are different, the frameworks should be
different too.

Some people in our community want to dive into JavaServer Faces, and
others want to pursue the tried-and-true action-orientated approach.
Rather than burn bridges, we're built a bigger roof :)
</snip>

-Ted.

To unsubscribe, e-mail: user-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: user-help (AT) struts (DOT) apache.org
--

The burning bridges thing is often far underrated. Caesar burned the bridge
back to Rome on passing over the Rubicon. That is the origin of the
metaphor. The metaphor originally was the act. Caesar said, when burning
the bridge, "iactum est", which means "the die is cast", using his own
metaphor. In the Vulgate version of the New Testament, Christ also says
"iactum est", which has been translated "it is finished". Sometimes a clear
decision is much better than a waffling decision to accommodate the "hoi
polloi". , that's Greek.

12/5/05, Adam Hardy <ahardy.struts (AT) cyberspaceroad (DOT) comwrote:

Ted Husted on 05/12/05 12:54, wrote:
IMH, I don't see the engineering value-add of a "one size fits all"
framework. A framework is a semi-complete application, and action/page
applications are built differently than event/component frameworks.
Since the applications are different, the frameworks should be
different too.

Surely the framework (singular) wraps the HTTP request response paradigm?

Some people in our community want to dive into JavaServer Faces, and
others want to pursue the tried-and-true action-orientated approach.
Rather than burn bridges, we're built a bigger roof :)

I like the analogy. Thanks for the clarification.
--
Adam

To unsubscribe, e-mail: user-unsubscribe (AT) struts (DOT) apache.org
For additional commands, e-mail: user-help (AT) struts (DOT) apache.org
--