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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
