You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2004/11/21 14:47:39 UTC
Proposed Roadmap for 1.3.x and beyond [long]
While at ApacheCon, Don, Martin, and I had a chance to chat about refinements to the Struts Roadmap <http://struts.apache.org/roadmap.html>. Here are my notes for everyone's review and comment.
As planned, in Struts 1.3.x we would integrate Struts Chain from config and add an "extends" attribute to all the configruation elements (a la Tiles). While we're at it, I'd also like to add a Ant-style properties file to make variable substitutions within the XML elements. We use this in iBATIS, and it can be a helpful way to configure applications and reduce redundancy.
-Experimental Members-
Those items by themselves seem like enough for a release, but we might add a few "experimental" classes and interfaces to give us a chance to play with Struts Chain in our own applications. We came up with two experimental classes and an experimental interface: ActionCommand, ActionContext, and ViewContext.
* ActionCommand - A Chain Command-like interface with one method:
void Execute(ActionContext context)
Support for conventional Actions would stay in place, but as an alternative, a class could implement ActionCommand and unbind itself from the HTTP API.
* ActionContext - A Chain Context that implements the Action class API. Existing code could be converted by changing references to context.* and so forth. Don suggested constructing this on Struts Chain so that it could be exposed this through thread-local, opening the door for POJO actions that don't implement a particular interface.
* ViewContext - A Chain Context that implements the "Velocity Tools" API. In a later release, we (meaning I) could move the taglib dependencies from the servlet contexts to the ViewContext. View technologies could then look exclusively to the ViewContext rather than poke around in the various servlet contexts. (Of course, support for the original architecture would remain for some time, to give third party libraries the chance to migrate.)
After having a chance to work with ActionContext and ViewContext ourselves, we could introduce more support for these members in a later release. But for 1.3, they could be marked "experimental".
The WebContext we now pass around Struts Chain could be called the "StrutsContext" to differentiate it from the ActionContext and ViewContext.
[Are we now starting to call everything "Context" instead of "Action"? Not really. We use the "Context" suffix when a member extends Chain Context. This convention is unlike the current "Action" soup, since "Context" is a suffix that identifies a member's "family" history.]
-Subproject Distributions-
Also as planned, we would extract the Taglibs package into its own subproject. (Giving us a chance to make the Taglibs 1.0.1 release utilize the ViewContext.) We might also consider extracting "Actions" (plural) and "Plugins" into a separate "Extras" subproject. While the members here are popular, they are optional, and not essential to the core.
We've mentioned that each subproject should have its own release cycle. We've also mentioned the idea of "bundling" subprojects into a master distribution. We might consider taking that idea a step further and utilize the "Linux" approach. The Struts "1.3.0" distribution could be an aggregation of "Core 1.0.x", "Taglibs 1.0.x", and "Extras 1.0.x".
Later, if we end up with a Taglibs 1.0.1 GA before there is another Core 1.0.x GA, we could assemble a "Struts 1.3.1" distribution that aggregates (for example) "Core 1.0.0", "Taglibs 1.0.1", and "Extras 1.0.0".
The Struts aggregate distribution doesn't have to be complicated, perhaps just a ZIP of whatever subproject GA distributions work with the "best available" core.
-1.4 considerations-
One we get past 1.3.x, there are some other things that we might consider.
Consider combining DTDs. Right now, using "standard" extensions like Tiles and Validator mean using more than one configuration file. While using multiple configurations files can be a good thing, we should also try and support the idea of having a single configuration file. This might not work-out for Tiles, but we might be able to at least integrate the Validator configuration with the DynaForm configuration.
Consider adding catalog element. Depending on how the work goes with the experimental ActionCommand interface, we might identifiy a need to add a catalog element to the Struts configuration, to support using a Chain of ActionCommands.
Consider refactoring for Spring. We identified the need for adding a IOC container to Struts some time ago, but stalled on the point of which to use. Since then, Spring has gained a lot of momentum. Spring is used by the MyFaces and Beehive teams, and its on the radar for Shale. There is already a Struts-Spring component in the Spring distribution and other common ground.
-1.5 considerations-
Based on our own work with the "experimental" members inroduced in 1.3.x, we might consider some other changes.
Consider a "smart" action type. The idea is that a command in Struts chain could look at the type indicated by the ActionMapping so both Action classes and ActionCommand implementations are supported. People could then mix-and-match Actions with ActionCommands (or even chains of ActionCommands). We might even support placing an ActionCommand interface on ActionForm, so people could skip having a sepate Action or ActionCommand class. The ActionForm could do it all.
Consider a "populate" method on ActionForm. From an OOP standpoint, it might be cleaner if an ActionForm populated itself rather than rely on an "god" class to populate it from the outside.
Consider a "FormContext" mechanism. Rather than "throw-away" a request-based ActionForm, the object could be seralized as a hidden-field or session-object and restored on the next request. Many other frameworks support this behavior now. Struts would have a slightly different spin, since we look at the form as an named entity rather than as an anonymous aggregation of other objects.
-1.6 considerations-
Consider multiple controllers. One reason we introduced modules was because "there can only be one" Struts controller in an application. With the context-based changes we making, we might be able to introduce a mechanism to support a collection of Struts controllers, each identified by its servlet or filter name, each with it's own URI pattern. The key to being able to do something like this is for view members to look to the ViewContext rather than the various servlet contexts. Each Struts controller would place the appropriate ViewContext in its own requests.
Consider an alternate configuration file. There are idiosyncrasies in the element/attribute names of the struts-config which often confuse new developers. By either supporting alternative configuration loaders, or applying a stylesheet to a XML configuration, we could support both the "classic" and a new configuration.
Thoughts?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Configuration and IoC (Re: Proposed Roadmap for 1.3.x and beyond
[long])
Posted by Vic Cekvenich <vi...@friendVU.com>.
Vic wrote:
> Don Brown wrote:
>
>>
>> When you start looking at configuration for defining procedures, it
>> can get messy quick - just look at Jelly. Many would argue XML is
>> just not a good fit for procedural code/definitions.
>
>
> Good argument.
>
> Even if you liked XML for
>
>> procedural configuration, I'm not sure chain's dtd would be a good
>> idea either.
>
>
> I think Chain XML files are self describing, you can put in ANY
> properties, as long as it's valid XML. (so it's not a real DTD, it's
> open).
>
> It only can only be used to define a linear process - no
>
>> braches, loops, or iterations. Instead, you'd have to code that
>> logic inside your commands, further complicating them and making it
>> even harder to deduce flow.
>
>
> Great argument, same point as above. When developers wrote something
> for me, it was harder to follow.
>
>
>>
>> Personally, I like the approach of using XML to define items, then
>> letting how those items are processed be defined with chain or
>> whatever else. Even then, I like using chain and CoR for defining
>> one pretty static process like how Struts
>
>
> That is a good practice, Agree.
>
> handles requests, but leaving it up to
>
>> Java or scripting languages for defining more dynamic, complex
>> processes.
>>
>
>> Inversion of Control, however, is really a different beast as it
>> seeks neither to define processes or conceptual elements, but rather
>> *configures* actual classes which may be different.
>>
> Key word is "configures". You can configure chain and commands a lot
> in XML same as IoC and random proerties, declare xml elments in xml...
>
> (I do have chain dispatching based on a "DispatchCommand" that looks
> at the string passed, and then executes that Command from the Catalog,
> a bit like LookupDispatchAction- I think that's what its called)
>
> Adding IoC jar would add complexity for users (sometimes you use IoC,
> sometimes you use CoR - harder to teach), Struts would be heavyier
> (like Spring is popular, but they have 2 of everything in there).
> Struts I would like to be a light "C" (of MVC).
>
> Now back up..... I agree that declaration is a good practice and
> "process" in XML is a bad practice BUT.... users should be allowed to
> use Struts "wrong". No 2 Struts production are the same out there.
> So just becuase you can put your rope arround your neck in chain xml
> should not prevent user chains.
>
> I think once ActionCommand() is released, then it will be easier to
> see issues.
>
> On another topic, when convinient, try to keep Context clear of View
> API, so that many views are supported. (like formbean knows nothing of
> DAO)
> For example if we can have same "UserAction" that a user wrote be able
> to hanlde TilesAction request(5 arguments), Portlet requests, Jabber
> Request, JMS request, JSF request, etc.
> Imagine a user has a TilesAction or regular actions and updates to
> Struts v"1.4". Then... same action... supports Portlet (or SoA in my
> case). Not sure how this would work out but...
> For what ever reason Struts is very DAO agnostic, but somehow Servlet
> API is in there. (I do not need JDBC to build Struts).
> Of course without breaking HTML tag. :-)
>
> In general Saint "Something- st augstine" said: "perfection is achived
> not when you have nothing more to add, but when you have nothing more
> to remove"
>
>
> .V
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Configuration and IoC (Re: Proposed Roadmap for 1.3.x and beyond
[long])
Posted by Vic <vi...@friendvu.com>.
Don Brown wrote:
>
> When you start looking at configuration for defining procedures, it can
> get messy quick - just look at Jelly. Many would argue XML is just not
> a good fit for procedural code/definitions.
Good argument.
Even if you liked XML for
> procedural configuration, I'm not sure chain's dtd would be a good idea
> either.
I think Chain XML files are self describing, you can put in ANY
properties, as long as it's valid XML. (so it's not a real DTD, it's open).
It only can only be used to define a linear process - no
> braches, loops, or iterations. Instead, you'd have to code that logic
> inside your commands, further complicating them and making it even
> harder to deduce flow.
Great argument, same point as above. When developers wrote something for
me, it was harder to follow.
>
> Personally, I like the approach of using XML to define items, then
> letting how those items are processed be defined with chain or whatever
> else. Even then, I like using chain and CoR for defining one pretty
> static process like how Struts
That is a good practice, Agree.
handles requests, but leaving it up to
> Java or scripting languages for defining more dynamic, complex processes.
>
> Inversion of Control, however, is really a different beast as it seeks
> neither to define processes or conceptual elements, but rather
> *configures* actual classes which may be different.
>
Key word is "configures". You can configure chain and commands a lot in
XML same as IoC and random proerties, declare xml elments in xml...
(I do have chain dispatching based on a "DispatchCommand" that looks at
the string passed, and then executes that Command from the Catalog, a
bit like LookupDispatchAction- I think that's what its called)
Adding IoC jar would add complexity for users (sometimes you use IoC,
sometimes you use CoR - harder to teach), Struts would be heavyier (like
Spring is popular, but they have 2 of everything in there).
Struts I would like to be a light "C" (of MVC).
Now back up..... I agree that declaration is a good practice and
"process" in XML is a bad practice BUT.... users should be allowed to
use Struts "wrong". No 2 Struts production are the same out there.
So just becuase you can put your rope arround your neck in chain xml
should not prevent user chains.
I think once ActionCommand() is released, then it will be easier to see
issues.
On another topic, when convinient, try to keep Context clear of View
API, so that many views are supported. (like formbean knows nothing of DAO)
For example if we can have same "UserAction" that a user wrote be able
to hanlde TilesAction request(5 arguments), Portlet requests, Jabber
Request, JMS request, JSF request, etc.
Imagine a user has a TilesAction or regular actions and updates to
Struts v"1.4". Then... same action... supports Portlet (or SoA in my
case). Not sure how this would work out but...
For what ever reason Struts is very DAO agnostic, but somehow Servlet
API is in there. (I do not need JDBC to build Struts).
Of course without breaking HTML tag. :-)
In general Saint "Something- st augstine" said: "perfection is achived
not when you have nothing more to add, but when you have nothing more to
remove"
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Configuration and IoC (Re: Proposed Roadmap for 1.3.x and beyond
[long])
Posted by Don Brown <mr...@twdata.org>.
The bottom line is Struts now uses xml configuration as declarative
configuration, rather than procedural. We define forms, actions,
plugins, etc., without defining a process for using them.
When you start looking at configuration for defining procedures, it can
get messy quick - just look at Jelly. Many would argue XML is just not
a good fit for procedural code/definitions. Even if you liked XML for
procedural configuration, I'm not sure chain's dtd would be a good idea
either. It only can only be used to define a linear process - no
braches, loops, or iterations. Instead, you'd have to code that logic
inside your commands, further complicating them and making it even
harder to deduce flow.
Personally, I like the approach of using XML to define items, then
letting how those items are processed be defined with chain or whatever
else. Even then, I like using chain and CoR for defining one pretty
static process like how Struts handles requests, but leaving it up to
Java or scripting languages for defining more dynamic, complex processes.
Inversion of Control, however, is really a different beast as it seeks
neither to define processes or conceptual elements, but rather
configures actual classes which may be different.
Don
Joe Germuska wrote:
> Since there was so much coming out of the ApacheCon summit, I decided
> to split my responses up a bit.
> I think long-term, the way in which Struts is configured is one of the
> most important factors about its ease of use and maintenance.
>
> At 9:37 AM -0600 11/21/04, Vic wrote:
>
>> So I say no combined DTD in favor of chain DTD,
>> and no IoC, because CoR , similar in purpose, is better than IoC.
>> If IoC always had same signature - you'd have CoR.
>> I know IoC is fashionable, but CoR is better, I put both in production.
>
>
> There is definitely something to this. I don't think I would agree
> that the Chain DTD would subsume any other configuration, but it's
> possible to imagine, at least in many cases, scrapping the
> struts-config.xml and instead having each command configure itself
> with whatever it needs.
>
> The problem comes when multiple steps in the chain need to reference
> the same configuration information. For example, form beans need to
> be looked up to populate them from the request, but they also need to
> be looked up if you want to pre-populate a page with application
> data. You wouldn't really want to push the form-bean configuration
> into the "CreateActionForm" command; instead, you'd want both
> "CreateActionForm" and (some as yet non-existent) "PrepareViewContext"
> command each to look up something in the StrutsContext which had that
> expertise.
>
> The other problem (if it is a problem) comes with explaining just what
> Struts is, if there's no struts-config file! I wouldn't let that stop
> me, but it is interesting in a way.
>
> If we were to use some kind of IoC, what would be the collaborators? I
> have often thought it would be nice to replace all those config
> classes with some more intelligent classes that have config but also
> do things (especially form bean and action instantiation), thereby
> centralizing some of the logic. Furthermore, I do prefer, in general,
> the idea of initializing one (or very few) objects for each relevant
> scope (in this case, particularly, the application scope) and then
> populating properties on those objects, rather than trusting everyone
> to use the right attribute name for fishing those out of contexts.
>
> I'm still trying to go through actual Struts code looking at it with
> these ideas in mind to validate whether there are really places where
> Struts would benefit from this, or if it's really just a matter of
> taste that isn't worth trying to impose on Struts.
>
> Joe
>
>
>
> At 8:47 AM -0500 11/21/04, Ted Husted wrote:
>
>> -1.4 considerations-
>>
>> One we get past 1.3.x, there are some other things that we might
>> consider.
>>
>> Consider combining DTDs. Right now, using "standard" extensions like
>> Tiles and Validator mean using more than one configuration file.
>> While using multiple configurations files can be a good thing, we
>> should also try and support the idea of having a single configuration
>> file. This might not work-out for Tiles, but we might be able to at
>> least integrate the Validator configuration with the DynaForm
>> configuration.
>>
>> Consider adding catalog element. Depending on how the work goes with
>> the experimental ActionCommand interface, we might identifiy a need
>> to add a catalog element to the Struts configuration, to support
>> using a Chain of ActionCommands.
>>
>> Consider refactoring for Spring. We identified the need for adding a
>> IOC container to Struts some time ago, but stalled on the point of
>> which to use. Since then, Spring has gained a lot of momentum. Spring
>> is used by the MyFaces and Beehive teams, and its on the radar for
>> Shale. There is already a Struts-Spring component in the Spring
>> distribution and other common ground.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Configuration and IoC (Re: Proposed Roadmap for 1.3.x and beyond
[long])
Posted by Joe Germuska <Jo...@Germuska.com>.
Since there was so much coming out of the ApacheCon summit, I decided
to split my responses up a bit.
I think long-term, the way in which Struts is configured is one of
the most important factors about its ease of use and maintenance.
At 9:37 AM -0600 11/21/04, Vic wrote:
>So I say no combined DTD in favor of chain DTD,
>and no IoC, because CoR , similar in purpose, is better than IoC.
>If IoC always had same signature - you'd have CoR.
>I know IoC is fashionable, but CoR is better, I put both in production.
There is definitely something to this. I don't think I would agree
that the Chain DTD would subsume any other configuration, but it's
possible to imagine, at least in many cases, scrapping the
struts-config.xml and instead having each command configure itself
with whatever it needs.
The problem comes when multiple steps in the chain need to reference
the same configuration information. For example, form beans need to
be looked up to populate them from the request, but they also need to
be looked up if you want to pre-populate a page with application
data. You wouldn't really want to push the form-bean configuration
into the "CreateActionForm" command; instead, you'd want both
"CreateActionForm" and (some as yet non-existent)
"PrepareViewContext" command each to look up something in the
StrutsContext which had that expertise.
The other problem (if it is a problem) comes with explaining just
what Struts is, if there's no struts-config file! I wouldn't let
that stop me, but it is interesting in a way.
If we were to use some kind of IoC, what would be the collaborators?
I have often thought it would be nice to replace all those config
classes with some more intelligent classes that have config but also
do things (especially form bean and action instantiation), thereby
centralizing some of the logic. Furthermore, I do prefer, in
general, the idea of initializing one (or very few) objects for each
relevant scope (in this case, particularly, the application scope)
and then populating properties on those objects, rather than trusting
everyone to use the right attribute name for fishing those out of
contexts.
I'm still trying to go through actual Struts code looking at it with
these ideas in mind to validate whether there are really places where
Struts would benefit from this, or if it's really just a matter of
taste that isn't worth trying to impose on Struts.
Joe
At 8:47 AM -0500 11/21/04, Ted Husted wrote:
>-1.4 considerations-
>
>One we get past 1.3.x, there are some other things that we might consider.
>
>Consider combining DTDs. Right now, using "standard" extensions like
>Tiles and Validator mean using more than one configuration file.
>While using multiple configurations files can be a good thing, we
>should also try and support the idea of having a single
>configuration file. This might not work-out for Tiles, but we might
>be able to at least integrate the Validator configuration with the
>DynaForm configuration.
>
>Consider adding catalog element. Depending on how the work goes with
>the experimental ActionCommand interface, we might identifiy a need
>to add a catalog element to the Struts configuration, to support
>using a Chain of ActionCommands.
>
>Consider refactoring for Spring. We identified the need for adding a
>IOC container to Struts some time ago, but stalled on the point of
>which to use. Since then, Spring has gained a lot of momentum.
>Spring is used by the MyFaces and Beehive teams, and its on the
>radar for Shale. There is already a Struts-Spring component in the
>Spring distribution and other common ground.
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Proposed Roadmap for 1.3.x and beyond [long]
Posted by Vic <vi...@friendvu.com>.
I used to catch grief for that, but I still put it in "Best Practices".
.V
Dakota Jack wrote:
> On Sun, 21 Nov 2004 08:47:39 -0500, Ted Husted <hu...@apache.org> wrote:
>
>
>>Consider a "populate" method on ActionForm. From an OOP standpoint, it might be cleaner if an ActionForm populated itself rather than rely on an "god" class to populate it from the outside.
>>
>
>
>
> Yes! This would reverberate well, I think, throughout Struts.
>
>
> Jack
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Proposed Roadmap for 1.3.x and beyond [long]
Posted by Dakota Jack <da...@gmail.com>.
On Sun, 21 Nov 2004 08:47:39 -0500, Ted Husted <hu...@apache.org> wrote:
> Consider a "populate" method on ActionForm. From an OOP standpoint, it might be cleaner if an ActionForm populated itself rather than rely on an "god" class to populate it from the outside.
>
Yes! This would reverberate well, I think, throughout Struts.
Jack
--
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Replacing Action (was Moving Chain Processor Ahead ...)
Posted by Vic <vi...@friendvu.com>.
Don Brown wrote:
>
> ActionContext is based on code I wrote for a POJO action framework
> extension for Struts a little while back. It is initialized at the
> start of the chain, receiving the chain Context. It then stores an
> instance of itself in threadlocal, to be optionally retrieved by
> ActionContext.getCurrentInstance(). It contains all the methods we now
> have in Action like saveToken(), getMessage(), etc.
This "educated" Context looks good and this is what I did a year ago, it
very OO.
I now do not hang method of the Context, becuase they may not be in a
"web" context.
For example, commands may, or may not need token, messages, etc.
I like plain Context, just plain Chain context.
If some commands use it in diferent context;
depending on the context of course, w/ pun.
This way I can start puting in my values that come from browser in
version 1 of my app.
Then... in version 2, I put in something else, and my action code and
dispatcher still works.
Imagine an XML you pass to the action, and return XML. (XML is just
name/value pairs).
If there is a clever way to make the app work in both cases. I think if
action takes a VO (w/ no real methods).
Same action could service 2 diferent contexts (without instanceOf, yuck)
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Replacing Action (was Moving Chain Processor Ahead ...)
Posted by Don Brown <mr...@twdata.org>.
Joe Germuska wrote:
> Where would ActionCommand fit in, more specifically? Is the idea that
> you'd rig the chain to use a different command that fills the general
> role of the current "ExecuteAction" command? Did you guys come up
> with more specific APIs for the ActionContext and ViewContext?
The bottom line of these three classes is it replaces Action and, while
providing a new default ActionCommand interface, opens the door to
alternative action frameworks.
ActionCommand would look like this:
public interface ActionCommand {
public void execute(ActionContext ctx);
}
...notice execute() isn't capitalized, mr .net Ted :) This interface
could also possibly return ActionForward to fit easier into existing
Struts concepts. Any place Action is used now, we would expect an
implementation of ActionCommand. The nice thing about chain is we can
support both side-by-side - simply add a command that checks the action
with an "instanceof Action", and if not found, it ignores the class,
letting the second chain command check for "instanceof ActionCommand".
ActionContext is based on code I wrote for a POJO action framework
extension for Struts a little while back. It is initialized at the
start of the chain, receiving the chain Context. It then stores an
instance of itself in threadlocal, to be optionally retrieved by
ActionContext.getCurrentInstance(). It contains all the methods we now
have in Action like saveToken(), getMessage(), etc., in addition to
extending Context, so its get() implementation, if the chain context is
an instance of WebContext, looks for beans with the proper order
(request, session, application, local). For the POJO action framework,
which looked quite like a JSF backing bean, anytime the action needed to
get Struts or web-specific things, it called the static method to get
the instance of ActionContext.
Now that I think about it, I'm not sure what ViewContext would contain.
Ted was thinking it would be based off VelocityTools, but I don't see
anything there that couldn't be stuck in ActionContext.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Moving Chain Processor Ahead (Re: Proposed Roadmap for 1.3.x
and beyond [long])
Posted by Vic <vi...@friendvu.com>.
Joe Germuska wrote:
the ActionServlet initialize one or more catalogs meant for use
> with Struts
and still having other things initialize catalogs for their
> own use.
>
Yeah, 2 ways to init, of course.
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Moving Chain Processor Ahead (Re: Proposed Roadmap for 1.3.x
and beyond [long])
Posted by Joe Germuska <Jo...@Germuska.com>.
>>Perhaps the catalog initialization belongs in the ActionServlet
>>(via init params), so that the servlet
>
>If init catalog is in just a base class of something, than chains
>could be used outside of Servlet container. (One day there will be
>SoA containers for example).
I'm not sure I follow you. In a base class of what? If I understand
the recent changes to commons-chain, where there is a single
CatalogFactory per classloader, then there's nothing incompatible
with having the ActionServlet initialize one or more catalogs meant
for use with Struts and still having other things initialize catalogs
for their own use.
>>* The current chain project is a lot of classes.
>
>??
>I think Struts-Chain was VERY CLEAN. I saw it and was humbled.
>Maybe we are talking about 2 diferent things.
It's clean, but it still has 41 classes. It's not a big deal to me,
but especially since half those classes are in either the "servlet"
or "legacy" packages, and thus theoretically not destined for a long
life in Struts, I wondered if we would want to handle it in some
other way than importing them all into the core. Also, I have a hint
of an idea that it would be cool to be able to have a JAR with a
chain config in it that was kind of self-configuring (something like
what Don has recently enabled for other config files), and I wanted
to see if that resonated with anyone else.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Moving Chain Processor Ahead (Re: Proposed Roadmap for 1.3.x
and beyond [long])
Posted by Vic <vi...@friendvu.com>.
Joe Germuska wrote:
>
> Perhaps the catalog initialization belongs in the ActionServlet (via
> init params), so that the servlet
If init catalog is in just a base class of something, than chains could
be used outside of Servlet container. (One day there will be SoA
containers for example).
>
> * The current chain project is a lot of classes.
??
I think Struts-Chain was VERY CLEAN. I saw it and was humbled.
Maybe we are talking about 2 diferent things.
Would it be
> anti-integration to keep it a separate artifact and have people include
> a struts-legacy-chain.jar as an app dependency? This has some appeal to
> me also because it is so oriented towards legacy and backwards
> compatibility. This also brings up something that has been bouncing
> around in my head for a while -- the idea that a JAR might include a
> catalog config XML in the JAR itself which would somehow make it more
> automatically usable. This would let people who really don't care never
> even look at the chain-config.xml. Or is that too much invisibility?
>
I think there are 2 or more chains. One is the request processor, which
sould be visable, so people could insert something, even if this is NOT
THE RECOMENDED way, since each Struts release could change it.
(Maybe have an emty user class that can call some other chain )
Then there are user chains (xmls). One could have many, per module for
example.
So a user chain module could have: receive the map (or list), validate
(each map in the list), and send it to selected DAO.
I think once the ActionCommand is released.... everything else becomes
clear, more people need to use chain 1st.
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Moving Chain Processor Ahead (Re: Proposed Roadmap for 1.3.x and
beyond [long])
Posted by Joe Germuska <Jo...@Germuska.com>.
At 8:47 AM -0500 11/21/04, Ted Husted wrote:
>While at ApacheCon, Don, Martin, and I had a chance to chat about
>refinements to the Struts Roadmap
><http://struts.apache.org/roadmap.html>. Here are my notes for
>everyone's review and comment.
Man, sounds like fun! I wish I could have been there; I've been
thinking about ways to get started on 1.3 stuff all weekend, but kind
of wishing for higher bandwidth dialogue about specific steps than
the mailing list can provide. Ah, well.
Where would ActionCommand fit in, more specifically? Is the idea
that you'd rig the chain to use a different command that fills the
general role of the current "ExecuteAction" command? Did you guys
come up with more specific APIs for the ActionContext and ViewContext?
I like the longer-term ideas on the roadmap, although to be honest it
seems a bit conservative to stretch out some of these changes across
four minor revisions. I'm sure when we get to talking about how
we'll really implement the things, we'll get a clearer picture on
whether that is the right timing or not.
I'm most interested in moving forward with making the long-discussed
changes on the request processor, but I'm reluctant to just dive in.
So, having changed the subject line, I'd like to get a thread going
on just how we're going to do this. Here are some of the things I've
bumped up against while thinking about it...
* Presumably we don't want to gut the original RequestProcessor
class, but rather, change the default implementation class as
specified in ControllerConfig? Or maybe we do gut it, but we make a
LegacyRequestProcessor which contains the code from the current
version?
* How would we get the chain catalogs initialized? If we're really
"integrating" this, then presumably we want to scrap the
CatalogConfiguratorPlugIn and achieve that in some other way?
The idea of adding yet another property to ControllerConfig kind of
irks me. Should we try to find a more graceful way to initialize the
controller, perhaps with nested XML elements for the RequestProcessor
and the MultipartRequestProcessor? (Here's a case where the Spring
BeanFactory starts to look more appealing than Digester, since it's
trivial to add new XML to instantiate and relate new beans. Still,
extending the Digester RuleSet isn't hard once we agree to the
details. )
Perhaps the catalog initialization belongs in the ActionServlet (via
init params), so that the servlet can cleanly handle cleaning up the
factory at shutdown; then the ControllerConfig could just have the
name of the catalog and base command which should be executed for
requests for that controller? (the current CatalogConfiguratorPlugIn
uses servlet init parameters for this, but it seems to me that these
should be per-module settings, no?)
* The current chain project is a lot of classes. Would it be
anti-integration to keep it a separate artifact and have people
include a struts-legacy-chain.jar as an app dependency? This has
some appeal to me also because it is so oriented towards legacy and
backwards compatibility. This also brings up something that has been
bouncing around in my head for a while -- the idea that a JAR might
include a catalog config XML in the JAR itself which would somehow
make it more automatically usable. This would let people who really
don't care never even look at the chain-config.xml. Or is that too
much invisibility?
I guess that's enough questions for now.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Proposed Roadmap for 1.3.x and beyond [long]
Posted by Vic <vi...@friendvu.com>.
My thoughts, based on my experience, with
ActionComand(Map/Context)
which is full of benefits which I will list:
I did something like this before Ziff, mostly to avoid a common Struts
user mistake (putting properties in action class and creating a thread
safety issue) such as pseudo code impl:
Class abstract ActionCommad extend Action {
final Forward execute(req,resp, maping… ) {
Map.put(“req”,req);
Map.put(“maping”, maping);
…
execute(Map);
Forward = map.getForward();
return Forward;
} // exec
abstract execute(Map);
protected Request getRequest(Map) {
return Request Map.get(“req”);
}
In essence this is the second “user” chain (1st one is the system
request process chain)
So very simple impl.
1. As pointed out the Context/Map allows to break from Servlet API,
which does not have to be forced on people, but it did allow me to do
Laszlo easily. (Now it also allows me to “Bypass the Browser for RiA”.)
2. It lets you use Collections/Map to pass arguments, one or many and
return one or many WITHOUT changing the signature. (I also sometimes
have an internal _map for Command instances … I do not know how to
explain it better but it’s handy)
3. It is inevitable that users will use Commands once introduced 1.3.
The commands and the userchain.xml are very configurable; users end up
with “same size bricks” to build with (as opposed to IoC, which every
signature is different).
The userchain.xml is very configurable, lets you put properties in xml.
So, this is a bit of a jump but, I do not think Struts XML DTD should
be changed 2 times.
Yes I know currently elements are repeated, but the Chain.xml is VERY
configurable. My developers surprised me when they re-configured
something just in chain, no code.
For example once can make a Validate Command My “Struts-config” was
replaced by ChainConfig.
So I say no combined DTD in favor of chain DTD,
and no IoC, because CoR , similar in purpose, is better than IoC.
If IoC always had same signature – you’d have CoR.
I know IoC is fashionable, but CoR is better, I put both in production.
For example, lets say you want to add JMX to request chain… easily! With
IoC… you need to think a bit and rearrange.
Or lets say there is a Validate Command and you want to use it else
where? Trivial. Mix and match. So… lets do simple Chain and see if IoC
ads something other than coolnes.
4. Lets bring up FormBean. I had “BaseBean” (which I named company after )
extend FormBean implement Collection. This made it easy to do complex
muti row operations. (There is an implementation of this on sf.net in
apache license http://www.sourceforge.net/projects/infonoia )
I think FormBean should continue evolving and it’s not listed in
ApacheCon ideas.
5. More Collections, 1st to pass arguments and … the “latest” BaseBean
does not extend FormBean, it’s just a collection. So I no longer use
beans! (thus I am changing the name of company to something else from
baseBeans). The FormBean does… nothing.
For a single row I use a Map extension. For muti row, I use an ArrayList
of Maps. (I find it superior to RowSet and JavaBeans). It is loosely
typed and if users add UI columns or dba changes model, my “Controller”
part is still solid, no more get/set and cruft code.
So the new “FormBean” is a Collection that “maps” to the “form”/screen.
Simpler. When you need beans or VO/DTO/Dynabeans, a collection can act
as any as needed.
Later you can present the collection as XML (just like iBatis returns
rows from DB as XML).
6. I also have this dynamic dispatcher that lets you execute a DAO map,
and CRUD operation or even any Command, without ANY code (based on the
chain). One just creates a DAO map or a Command, and just pass in
arguments to the dispatcher.
So I have leaned on Chain and it took me far, and I do not see limits.
Just like Struts, Chain is simple and gets out of the way when I need to
do something but still provides a structure and a mapping for other to
be able to follow the code.
Struts 1.3 chain will be amazing. Action Command will add a lot also.
So those are my thoughts,
.V
Ps: my personal project is to leverage JDNC to use a Struts like chain
dispacher, more here:
http://www.javadesktop.org/forums/thread.jspa?threadID=6668&tstart=0
Oh and my 3rd book is on the way, based on "NEW Swing for CMS", since
JDNC will be a part of Mustang.
Ted Husted wrote:
> While at ApacheCon, Don, Martin, and I had a chance to chat about refinements to the Struts Roadmap <http://struts.apache.org/roadmap.html>. Here are my notes for everyone's review and comment.
>
> As planned, in Struts 1.3.x we would integrate Struts Chain from config and add an "extends" attribute to all the configruation elements (a la Tiles). While we're at it, I'd also like to add a Ant-style properties file to make variable substitutions within the XML elements. We use this in iBATIS, and it can be a helpful way to configure applications and reduce redundancy.
>
> -Experimental Members-
>
> Those items by themselves seem like enough for a release, but we might add a few "experimental" classes and interfaces to give us a chance to play with Struts Chain in our own applications. We came up with two experimental classes and an experimental interface: ActionCommand, ActionContext, and ViewContext.
>
> * ActionCommand - A Chain Command-like interface with one method:
>
> void Execute(ActionContext context)
>
> Support for conventional Actions would stay in place, but as an alternative, a class could implement ActionCommand and unbind itself from the HTTP API.
>
> * ActionContext - A Chain Context that implements the Action class API. Existing code could be converted by changing references to context.* and so forth. Don suggested constructing this on Struts Chain so that it could be exposed this through thread-local, opening the door for POJO actions that don't implement a particular interface.
>
> * ViewContext - A Chain Context that implements the "Velocity Tools" API. In a later release, we (meaning I) could move the taglib dependencies from the servlet contexts to the ViewContext. View technologies could then look exclusively to the ViewContext rather than poke around in the various servlet contexts. (Of course, support for the original architecture would remain for some time, to give third party libraries the chance to migrate.)
>
> After having a chance to work with ActionContext and ViewContext ourselves, we could introduce more support for these members in a later release. But for 1.3, they could be marked "experimental".
>
> The WebContext we now pass around Struts Chain could be called the "StrutsContext" to differentiate it from the ActionContext and ViewContext.
>
> [Are we now starting to call everything "Context" instead of "Action"? Not really. We use the "Context" suffix when a member extends Chain Context. This convention is unlike the current "Action" soup, since "Context" is a suffix that identifies a member's "family" history.]
>
> -Subproject Distributions-
>
> Also as planned, we would extract the Taglibs package into its own subproject. (Giving us a chance to make the Taglibs 1.0.1 release utilize the ViewContext.) We might also consider extracting "Actions" (plural) and "Plugins" into a separate "Extras" subproject. While the members here are popular, they are optional, and not essential to the core.
>
> We've mentioned that each subproject should have its own release cycle. We've also mentioned the idea of "bundling" subprojects into a master distribution. We might consider taking that idea a step further and utilize the "Linux" approach. The Struts "1.3.0" distribution could be an aggregation of "Core 1.0.x", "Taglibs 1.0.x", and "Extras 1.0.x".
>
> Later, if we end up with a Taglibs 1.0.1 GA before there is another Core 1.0.x GA, we could assemble a "Struts 1.3.1" distribution that aggregates (for example) "Core 1.0.0", "Taglibs 1.0.1", and "Extras 1.0.0".
>
> The Struts aggregate distribution doesn't have to be complicated, perhaps just a ZIP of whatever subproject GA distributions work with the "best available" core.
>
> -1.4 considerations-
>
> One we get past 1.3.x, there are some other things that we might consider.
>
> Consider combining DTDs. Right now, using "standard" extensions like Tiles and Validator mean using more than one configuration file. While using multiple configurations files can be a good thing, we should also try and support the idea of having a single configuration file. This might not work-out for Tiles, but we might be able to at least integrate the Validator configuration with the DynaForm configuration.
>
> Consider adding catalog element. Depending on how the work goes with the experimental ActionCommand interface, we might identifiy a need to add a catalog element to the Struts configuration, to support using a Chain of ActionCommands.
>
> Consider refactoring for Spring. We identified the need for adding a IOC container to Struts some time ago, but stalled on the point of which to use. Since then, Spring has gained a lot of momentum. Spring is used by the MyFaces and Beehive teams, and its on the radar for Shale. There is already a Struts-Spring component in the Spring distribution and other common ground.
>
> -1.5 considerations-
>
> Based on our own work with the "experimental" members inroduced in 1.3.x, we might consider some other changes.
>
> Consider a "smart" action type. The idea is that a command in Struts chain could look at the type indicated by the ActionMapping so both Action classes and ActionCommand implementations are supported. People could then mix-and-match Actions with ActionCommands (or even chains of ActionCommands). We might even support placing an ActionCommand interface on ActionForm, so people could skip having a sepate Action or ActionCommand class. The ActionForm could do it all.
>
> Consider a "populate" method on ActionForm. From an OOP standpoint, it might be cleaner if an ActionForm populated itself rather than rely on an "god" class to populate it from the outside.
>
> Consider a "FormContext" mechanism. Rather than "throw-away" a request-based ActionForm, the object could be seralized as a hidden-field or session-object and restored on the next request. Many other frameworks support this behavior now. Struts would have a slightly different spin, since we look at the form as an named entity rather than as an anonymous aggregation of other objects.
>
> -1.6 considerations-
>
> Consider multiple controllers. One reason we introduced modules was because "there can only be one" Struts controller in an application. With the context-based changes we making, we might be able to introduce a mechanism to support a collection of Struts controllers, each identified by its servlet or filter name, each with it's own URI pattern. The key to being able to do something like this is for view members to look to the ViewContext rather than the various servlet contexts. Each Struts controller would place the appropriate ViewContext in its own requests.
>
> Consider an alternate configuration file. There are idiosyncrasies in the element/attribute names of the struts-config which often confuse new developers. By either supporting alternative configuration loaders, or applying a stylesheet to a XML configuration, we could support both the "classic" and a new configuration.
>
> Thoughts?
>
> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org