Martin Cooper wrote:
On 11/13/05, Wolfgang Gehner <[EMAIL PROTECTED]> wrote:
-1, the most important thing that Struts 1.3 allows us to get rid of is
the "extends Action", which becomes "implements Command". So the focus
should be on this.
The "Action" in "Struts Action Framework" isn't the Action class.
Maybe true, it's just hard to communicate.
It's
action as in action-oriented, as distinct from component-oriented.
Regardless of whether you choose to implement Actions or Commands, it's
still an action-oriented framework.
Well, I happen to use 1.3 with Tiles in a portlet-like manner. I call an
action (command) from a tiles definition. I have onEdit and onRender
methods. Are portlets components? Then 1.3 opened the door to component
orientation. New, WOW! All I'm saying instead of focusing on the old
stuff which everyone already knows, let's communicate the new
possibilities! And they are in the CORe chain. What we are really
talking about is programmers being able to defend why they want to use
Struts for another 5 years, with all that modern component wizardry around.
Wolfgang
--
Martin Cooper
The Command/Chain of Command= Chain of Responsibility=CoR leads me to
the name Struts COR(e).
Spell it with an "e" at the end or without, but the use of CoR is really
the leap the framework has done to make it the technology choice of the
future.
I see actions as a thing of the past. We use commands now. So does the
Struts Request processor. Struts has become a more generic Request
Processor. With the discussion on "action oriented" versus "component
oriented", I think the request processor has been rebuilt to allow both.
Which is the great news about 1.3. We've been doing actions for so long,
to that we are just learning to discover that greatness. Too bad if, via
naming, we were to somewhat limit the perspective to "action handling".
Even Shale uses a chain, and my wild guess is that both Shale and TI
will use the code in the Core subproject eventually; it's just such a
great piece of work.
Action Framework sells it below value, IMHO. Today, in the age of
flexibility, it kind of puts itself in a corner for a particular kind of
usage.
Maybe I missed some threads, but I think most people were OK to go with
CORE Library. So let me be a dissident on "Action".
I love 1.3 and I just see that I would have a more difficult time
explaining why I "still" use Struts instead of Spring. That is if can't
flaunt
the fact that 1.3 is NEW, more open (flexible wiring is what sells
Spring), abd a *CORE* piece of solid code infrastructure. That's why I
believe in Struts CORe.
Wolfgang Gehner
L.
Ted Husted wrote:
The website seems to be in pretty good shape now. I just ran build-all
on the applications subproject, and that's looking pretty good too. I
think that just leaves
* Reviewing the applications
* Adding the Actions package to PlugIns and renaming it Extra
If this all goes well, then I'm thinking we can roll 1.3.0 sometime
next week.
Now about the whole "what to call it" thing :)
I was about to suggest "Struts Smurf", but, hey, why not go for the
next best thing?
We've called everything else "Action", why not call the framework
that too? :)
OK, let's try it on for size:
Today, the Apache Struts project is comprised of two distinct
frameworks and several subprojects. The two frameworks are *Struts
Action* and *Struts Shale*. Struts Action is the original action/page
framework. Struts Shale is an event/component framework based on
JavaServer Faces.
...
Struts Action is a flexible control layer based on standard
technologies like Java Servlets, JavaBeans, ResourceBundles, and XML,
as well as various Jakarta Commons packages, like BeanUtils and Chain
of Responsibility. Action helps you create an extensible development
environment for your application, based on published standards and
proven design patterns.
....
Struts Action in a Nutshell
The framework's controller class, also called "Action", acts as a
bridge between the application's Model and the web View. When a
request is received, the Request Processor invokes an Action class.
The Action class consults with the Model (or, preferably, a Facade
representing your Model) to examine or update the application's state.
The framework provides an ActionForm class to help transfer data
between Model and View.
....
We could then call the bundle the "Struts Action Library".
Thoughts on calling the core of the original framework "Action"? Last
call!
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
