Moving Chain Processor Ahead (Re: Proposed Roadmap for 1.3.x and beyond [long])

[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: Replacing Action (was Moving Chain Processor Ahead ...)

[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 ...)

[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])

[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])

[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])

[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