Re: Chain of commands in 1.3
On 9/9/05, Marco Mistroni <[EMAIL PROTECTED]> wrote: > This answer is from my point of view Following Ted's example, > All my business logic is now in the Command.. all action does Is simply > To build context and pass it to the command.. so code in action is really > very simple.. I think Marco has hit on an important point. You can write the business side of your application with Commons Chain regardless of what Struts is doing. Likewise, Struts can use Commons Chain for it's internal logic regardless of what your application is doing. There should be a clean separation between the Struts presentation layer and your application. I believe some people are looking at the use of Commons Chain by Struts as a way to continue the HTTP request up into the business layer. Personally, I think that's a misstep. Struts should collect values for your business logic to process. The role of the Action is to provide a place where the presentation layer can exchange values with rest of the application. I've been using a C# port of Commons Chain extensively for over a year now, and it's working quite well for us. We find that a Chain of Responsiblity is very easy to unit test, so we are able to test the business layer before plugging it into the presentation layer. -- HTH, Ted. http://www.husted.com/poe/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Chain of commands in 1.3
Hello Michael, Not sure if this is of any help, but Mr Ted Husted has written a MailReader application That uses Struts and Common Chains, When I checked it out (last april) it was at this link http://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/?root=Apache-SVN I have followed that app in writing my own that uses commands defined In a spring config file.. Business logic is done in the command, Actions behave exactly like Before.. I'll try to answer some of your question (anyone pls correct me if I am Wrong...) ... based on what I have done using samples & articles around, & advices from Joe et other 1.3 guys.. Keep in mind that what I am referring is to an application like MailReader, I have used Commands just for moving logic out of Actions,not for modifying The chain used by struts itself.. > (1) The first one is where to check 1.3 out from? Ok, I might have not >been following the list, but http://struts.apache.org does not have >links to 1.3 source code nor it explains how to set up Subversion. I > Last time I checked (April) jars were at this link http://svn.apache.org/builds/struts/maven/nightly/ beware though that Struts 1.3 does not include by default taglibs & tiles, so you need to download a separate jar for that >Also, I would like to get all sources in a jar file with a build >script. I do not really want to check out file by file from repository >unless this is really justified. At same location there should be a zip file for sources (which includes Also build.xml) >(2) How tight is integration between commands from chain-config.xml >and actions from struts-config.xml ? Should not it be possible to >define actions in chain-config.xml as commands? I know that actions >have more attributes and they have elements, but tighter >integration would be a great thing. This answer is from my point of view Following Ted's example, All my business logic is now in the Command.. all action does Is simply To build context and pass it to the command.. so code in action is really very simple.. >Command returns true or false, Action returns ActionForward. How does >this work? Where the action forward is returned to? Is it set into the >context? ActionForward will be selected depending on what the command return. Normally if the command return false, you will go to original page.. >(4) Neither Bill's article nor Vic's example stress out the scope of >the Context. Is it filled out for each request? Yes in my opinion.. >Can I set up the scope >for the Context? Considering that Context has accessors for request, >session and servletcontext, it should be a long-term object. Whom it >belongs to? Should access to it be synchronized? If I am right, context is the only way to pass data from Action to Commands. Again, following ted's example, my Action build a context and populates with What the Command needs to do its logic. So, for example, get that username & password from request, put it into the Context and pass the Context to the command, which will use what is in the context to do a login operation for example >(5) It is nice that process() is changed into a chain, but what are >the relations and dependencies between the commands? How do they >affect each other? They will affect each other when a command is itself a chain of commands.. Sorry I don't know how to explain it better, maybe joe or other 1.3 committers could make a case (I didn't find one for my needs).. >What do they store in the context and what do they >expect? What do they store: the data resulted from the operation the command executed, which could be needed by an Action or other commands What do they expect: the data needed for performing the operation That the command does.. for example logging in, querying a database, inserting data etc.. > What would be the effect of removing a standard command or >adding a new one? This question does not require immediate answer, >rather a reminder for better docs ;-) Are you talking about the chain used by Struts itself? Well If you Remove a command out of the struts chain, I think things are going To be pretty difficult :) Adding/overriding commands will result in your commands being executed, and as long as the existing commands can find in the context what they need, There shouldn't be any problems.. If you check StrutsWS_Struts1.3 app at this link http://cvs.sourceforge.net/viewcvs.py/strutsws/ it overrides struts default chain to add additional processing.. hope I haven't confused you more :) HTH marco (6) Bill's article [2] shows a login interceptor implemented as command, but all it does is displays 403 error. Well, it reminds that request and response objects did not go nowhere, and can be used, but what I would like to see is not short-circuiting the chain, but redirecting to a login action. I am not sure how this is going to work in the chain. Should I somehow preselect the interceptor action (login action) before SelectAct
Re: Chain of commands in 1.3
At 4:20 PM -0700 9/8/05, Michael Jouravlev wrote: I still have couple of questions before checking out the 1.3 source code. I'm going to take them out of order, as some are simpler than others. (1) The first one is where to check 1.3 out from? You figured this one out: http://struts.apache.org/acquiring.html has information about all the many ways to acquire Struts. Frankly, if you have Maven installed, it's really not a big deal to check out code from the repository, and it may be easier to keep up with incremental changes. Do what works for you, of course. (4) Neither Bill's article nor Vic's example stress out the scope of the Context. Is it filled out for each request? Can I set up the scope for the Context? Considering that Context has accessors for request, session and servletcontext, it should be a long-term object. Whom it belongs to? Should access to it be synchronized? The ActionContext instance is request scoped. It is created by the Request Processor before the base chain command is invoked. Struts will never spawn an additional thread which might contend for simple properties of the ActionContext, so unless you have some exotic programming models, it is probably save to consider it threadsafe. Of course, the ActionContext may well have references to things which may require more careful access, including but not limited to the HttpSession. (5) It is nice that process() is changed into a chain, but what are the relations and dependencies between the commands? How do they affect each other? What do they store in the context and what do they expect? What would be the effect of removing a standard command or adding a new one? This question does not require immediate answer, rather a reminder for better docs ;-) I won't try to answer it all now, but note that as we stand right now, there are still some unfortunate internal dependencies on order of execution which were just a result of an imperfect first pass at translating the original RequestProcessor into the chain based one. Of course several commands expect one or two objects to be in the context, and this should be documented more clearly; however, particularly regarding post-form-validation behavior, there's too much hard coded logic testing things like "is the form valid." The chain's control logic should actually prevent the context from reaching a command which has that concern, but the initial commons-chain implementation (as well, perhaps, as the nature of expressing conditional logic in XML) make that harder than it should be. This is something which is relatively likely to change before Struts 1.3 goes GA. Not radically, but enough that if you are customizing the chain-config.xml for your app, you should pay close attention to changes in interim releases and discussions on the dev list. (well, it turns out that I answered more of this later than I thought I would, in answering item 6, so read on if your curiosity has been piqued!) (2) How tight is integration between commands from chain-config.xml and actions from struts-config.xml ? Should not it be possible to define actions in chain-config.xml as commands? I know that actions have more attributes and they have elements, but tighter integration would be a great thing. I look at Vic's example [3]: === cut here === The classes (now there can be more than one!) to be executed in the testCmd chain are specified in a chain-config.xml, similar to struts-config.xml === cut here === Instead of one config file I have two files now. Um, I would rather had less XML than more. Command returns true or false, Action returns ActionForward. How does this work? Where the action forward is returned to? Is it set into the context? There are a few questions in here. First, the explicit ones at the end: the command which executes an action takes the ActionForward which is returned and places it in the ActionContext in "the right place." If you chose to attach a command to an mapping and leave out the "type" attribute, then your command should assume the responsibility of populating the "actionConfig" property of the ActionContext, which is the net effect of the ExecuteAction command. Note that it is possible to have a command execute in addition to having an Action execute. After some discussions about Struts Ti on the dev list, I now wonder if we should have (or ought yet to) set that up so that the looked up command is somehow used as the first in a chain which is also composed of the rest of those standard commands. I'm not entirely sure how this would happen, but it would allow you to set up a Filter instead of a simple command, and therefore have access to the action context twice, much like the WebWork interceptors that have inspired some of Don's thinking in Struts Ti. I think this is something relatively reachable, but since I've never programmed with the Interceptor model, I don't think
Re: Chain of commands in 1.3
Found 1.3 nightlies under http://struts.apache.org/acquiring.html Would be nice to have the same links under http://struts.apache.org/download.cgi or to reduce number of links to the sources/binaries down to one ;-) Michael. On 9/8/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > I still have couple of questions before checking out the 1.3 source code. > > (1) The first one is where to check 1.3 out from? Ok, I might have not > been following the list, but http://struts.apache.org does not have > links to 1.3 source code nor it explains how to set up Subversion. I > think I knew where to check it out from, but forgot ;-(( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chain of commands in 1.3
I still have couple of questions before checking out the 1.3 source code. (1) The first one is where to check 1.3 out from? Ok, I might have not been following the list, but http://struts.apache.org does not have links to 1.3 source code nor it explains how to set up Subversion. I think I knew where to check it out from, but forgot ;-(( Also, I would like to get all sources in a jar file with a build script. I do not really want to check out file by file from repository unless this is really justified. (2) How tight is integration between commands from chain-config.xml and actions from struts-config.xml ? Should not it be possible to define actions in chain-config.xml as commands? I know that actions have more attributes and they have elements, but tighter integration would be a great thing. I look at Vic's example [3]: === cut here === The classes (now there can be more than one!) to be executed in the testCmd chain are specified in a chain-config.xml, similar to struts-config.xml === cut here === Instead of one config file I have two files now. Um, I would rather had less XML than more. Command returns true or false, Action returns ActionForward. How does this work? Where the action forward is returned to? Is it set into the context? (4) Neither Bill's article nor Vic's example stress out the scope of the Context. Is it filled out for each request? Can I set up the scope for the Context? Considering that Context has accessors for request, session and servletcontext, it should be a long-term object. Whom it belongs to? Should access to it be synchronized? (5) It is nice that process() is changed into a chain, but what are the relations and dependencies between the commands? How do they affect each other? What do they store in the context and what do they expect? What would be the effect of removing a standard command or adding a new one? This question does not require immediate answer, rather a reminder for better docs ;-) (6) Bill's article [2] shows a login interceptor implemented as command, but all it does is displays 403 error. Well, it reminds that request and response objects did not go nowhere, and can be used, but what I would like to see is not short-circuiting the chain, but redirecting to a login action. I am not sure how this is going to work in the chain. Should I somehow preselect the interceptor action (login action) before SelectAction command? Or exactly in this command? What about other commands like PopulateActionForm or ValidateActionForm? I do not need to execute them, but I need to execute CreateAction and ExecuteAction, which are in the end of the chain. How do I jump to them across other commands that I do not need? Or this use case should be handled by creating a new small chain specifically for login action, which would include only SelectAction, CreateAction and ExecuteAction, and then short-circuiting? References: [1] A Look at Commons Chain, Part 1: http://www.onjava.com/lpt/a/5671 [2] A Look at Commons Chain, Part 2: http://www.onjava.com/lpt/a/5693 [3] Better Code With Struts 1.3: http://www.infonoia.com/en/content.jsp?d=inf.05.06&pr=1 Michael. On 9/8/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > Thanks, Joe. > > I jumped a gun a little, since the articles at OnJava give pretty good > understanding of Struts chains: > > http://www.onjava.com/lpt/a/5671 > http://www.onjava.com/lpt/a/5693 > > I need to play with it a bit. Seems that I will be able to use > ActionForm only (or whatever other class I decide to use) for > collecting request paramaters as well as for event handling, and to > throw Action away altogether ;-) > > Michael. > > On 9/8/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > > >Considering that 1.3 is on the radar, there should be better docs for > > >this crucial feature, should not it? > > > > Indeed it should. Alas, last time I set out to write docs, I instead > > realized a bunch of things that had to be changed (rather than write > > doc thinking "it should be like this, but it's really like that"...). > > > > Since then, I've had only enough time for Struts as needed to keep up > > with stuff at work. I will gladly try to answer questions on the > > lists, and all the better if those answers help to support > > documentation. > > > > >I would contribute writing it, > > >but I don't know how to use it yet ;-) > > > > It's actually pretty straightforward; if you have time and interest, > > dive in and let us know what your questions are. > > > > Joe > > > > -- > > Joe Germuska > > [EMAIL PROTECTED] > > http://blog.germuska.com > > "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chain of commands in 1.3
Thanks, Joe. I jumped a gun a little, since the articles at OnJava give pretty good understanding of Struts chains: http://www.onjava.com/lpt/a/5671 http://www.onjava.com/lpt/a/5693 I need to play with it a bit. Seems that I will be able to use ActionForm only (or whatever other class I decide to use) for collecting request paramaters as well as for event handling, and to throw Action away altogether ;-) Michael. On 9/8/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > >Considering that 1.3 is on the radar, there should be better docs for > >this crucial feature, should not it? > > Indeed it should. Alas, last time I set out to write docs, I instead > realized a bunch of things that had to be changed (rather than write > doc thinking "it should be like this, but it's really like that"...). > > Since then, I've had only enough time for Struts as needed to keep up > with stuff at work. I will gladly try to answer questions on the > lists, and all the better if those answers help to support > documentation. > > >I would contribute writing it, > >but I don't know how to use it yet ;-) > > It's actually pretty straightforward; if you have time and interest, > dive in and let us know what your questions are. > > Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Chain of commands in 1.3
Considering that 1.3 is on the radar, there should be better docs for this crucial feature, should not it? Indeed it should. Alas, last time I set out to write docs, I instead realized a bunch of things that had to be changed (rather than write doc thinking "it should be like this, but it's really like that"...). Since then, I've had only enough time for Struts as needed to keep up with stuff at work. I will gladly try to answer questions on the lists, and all the better if those answers help to support documentation. I would contribute writing it, but I don't know how to use it yet ;-) It's actually pretty straightforward; if you have time and interest, dive in and let us know what your questions are. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
