Re: Using Eclipse to contribute to Struts
http://jakarta.apache.org/struts/faqs/eclipse.html In case you are using Eclipse 3.0 (M4 or M5) or have some other preference, you'd need to to make some adjustments. It's a good starting point nevertheless. - Indrajit - Original Message - From: Hien Q Nguyen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, 16 October, 2003 09:21 Subject: Using Eclipse to contribute to Struts Hi, I'm trying to set up my local eclipse development environment since I want to start maybe writing some test cases or applying patches from the bug database. Is there a doc or howto on this? I did a search on the Dev mailing list archive but wasn't able to find anything relevant. Thanks. --Hien - 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]
Re: Struts-chain Behavior Discussion
- Original Message - From: PILGRIM, Peter, FM [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Sent: Monday, October 13, 2003 5:39 AM Subject: RE: Struts-chain Behavior Discussion *Question of Architecture* Does this mean that we have solved the hideous Action Chaining debate? In theory an Struts Action could be refactored to be a type of ``Command'' and therefor Actions could be chained. Whenever there is a debate and each side seems to be very reasonable in certain contexts, it is more likely the system itself is in-complete or fails to meet the requirements. We use Controller Delegation Model and/or Event Handler(s) to deal with such problems. Commons-chain is not intended to solve that debate topic originally. Last year, people found when they have two RequestProcessor(s), say A and B, if they need to design a new RequestProcessor C that has methods from both A and B, the best they can do is to let C extend one of them, say A, and then copy the methods (possibly line by line) from B. So a configurable RequestProcessor is somehow needed to reuse portions of several RequestProcessor(s). This is what commons-chain is intended to solve initially. But the problems have not been cleanly solved in regard to reusability. When a Command is deeply coupled with other Command(s) in a chain through one or more flags/states in Context (say cancel flag, invalid token flag, invalid validation flag, etc.) its reusability in a different chain is very low in theory or very difficult to use (you need to configure many flags to get it work and subject to the condition the new Context offers the same set of flags). I did a little exercise to reduce the command coupling degree by introducing a NestCommand. Like LookupCommand to execute a specified chain, NestCommand always return false regardless what nested chain returns. So a termination of nested chains does not force a termination of calling chains when NestCommand is used. The following picture illustrates the idea: Main Chain: NestCommand Nested Chain: NestedCommand1 NestedCommand2 NestedCommand3 LastCommand If any nested commands return true, the control flow will *jump* to LastCommand. It seems to give an answer to my original question without the notion of branch behavior :-) NestedCommand2 does not need to check any flag set by NestedCommand1 in this way and NestedCommand3 does not need to check any flags set by NestedCommand1 and 2. They could be reused in other chains without concerning about flags. Jing Netspread Carrier http://www.netspread.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts-chain Behavior Discussion
Joe Germuska wrote: Speaking of chains, given Ted's suggestion about just plugging in another Action class as part of the ForwardConfig -- if that were to be the case, I think I'd just be more interested in a Commons-Chain/Struts-Chain solution -- which might be better anyway, as it's more forward looking than any of my suggestions. PILGRIM, Peter, FM wrote: Does this mean that we have solved the hideous Action Chaining debate? In theory an Struts Action could be refactored to be a type of ``Command'' and therefor Actions could be chained. Ted Husted wrote: I think the Chain package will make it easier for people to do the Right Thing. The ActionForm properties, and so forth, can be commuted to a Context, and the Context passed up to a Chain which can do whatever it is they want to do. Just to check in ... I've been refactoring an application that started out using the page controller type actions into an architecture that uses view commands instead, and it seems to be working well. In cases where I want to forward directly to the page, I can use a single Command: command name=summary className=app.command.SummaryView / In cases where I need to do something else first, like look up a seed record or process an update, I can set up a Chain that executes the business operations first, and then runs the view command. For one interesting page, I have two chains running back to it, depending on which control is used: chain name=summary_select_applicant command className=app.command.SummaryList / command className=app.command.SummaryView / /chain chain name=summary_select_permit command className=app.command.Select / command className=app.command.SummaryList / command className=app.command.SummaryView / /chain So, in places where I had business actions forward to presentation actions, I'm now back to having command actions forward straight to the server pages again. Life is good. Ladies and gentlemen, I believe we've found the missing link =:) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts-chain Behavior Discussion
Jing Zhou wrote: Commons-chain is not intended to solve that debate topic originally. Last year, people found when they have two RequestProcessor(s), say A and B, if they need to design a new RequestProcessor C that has methods from both A and B, the best they can do is to let C extend one of them, say A, and then copy the methods (possibly line by line) from B. So a configurable RequestProcessor is somehow needed to reuse portions of several RequestProcessor(s). This is what commons-chain is intended to solve initially. The composable request processor is what finally got Craig to scratch the itch, but he's been mentioning the Chain of Responsibility pattern for some time, in several contexts (so to speak). I don't think it's fair to say Commons-Chain is intended to solve any specific Struts issue. The request processor brought the work to a head, but Chain speaks to the need for a business layer framework. The RequestProcessor is an example of where Struts needs to utilize what amounts to business logic. The rules we want the request processor to follow are not uniform and subject to a RFP, but may differ from application to application. In other words, we want to create arbitrary request processors -- and arbitrary often indicates that some flavor of business logic is in play. =:) It's true that the RequestProcessor is an important proof of concept, but, it's just the beginning. IMHO, Chain is intended to provide core utility that many business layer implementations share, which happens to include the request processor implementation. Another likely candidate in Struts space would be chaining validation commands. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nested-EL
[EMAIL PROTECTED] wrote: Understood. I have all of the classes written. The TLD is looking a little daunting. From my studies it appears that the tld is generated from an xml file that is run through an xsl stylesheet. If you want the classes, I can send them to you. Yes, that's true. But it may not be as difficult to work with the XML you might imagine. Try copying a likely suspect for a template, and then run the Ant compile.website target .. Instant TLD. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23860] New: - warn if logic tags are prematurely terminated
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23860. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23860 warn if logic tags are prematurely terminated Summary: warn if logic tags are prematurely terminated Product: Struts Version: 1.0 Final Platform: Other URL: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23745 OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] when logic:equal ... / ... /logic:equal is inadvertently written, the tag is simply ignored! Sure, I know that an xml validator would find that too, but this time, I would even be happy if got an error at all ;) (related RFE http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23745 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts-chain Behavior Discussion
-Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] - Original Message - From: PILGRIM, Peter, FM [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Sent: Monday, October 13, 2003 5:39 AM Subject: RE: Struts-chain Behavior Discussion *Question of Architecture* Does this mean that we have solved the hideous Action Chaining debate? In theory an Struts Action could be refactored to be a type of ``Command'' and therefor Actions could be chained. Whenever there is a debate and each side seems to be very reasonable in certain contexts, it is more likely the system itself is in-complete or fails to meet the requirements. We use Controller Delegation Model and/or Event Handler(s) to deal with such problems. What are you talking about here? What I am talking about or rather aiming the ability create common Struts components. Suppose team T1 invents a generic web search engine component. Let say another team T2 wanted to use that component, say embed it is in own JSP views using say Tiles. How does the search component forward or transfer control to the external component that T2. One way could be to use an action chain. First, one writes a Struts Action in such way that it puts a known public bean or put the bean in the form bean. Whatever. This Output Bean contains contains your search result or selected object. Second, one can generate a dynamic ActionForward that names the second Action to forward. But I am thinkgin Craig has given us an alternative option, of maybe using a Command to do this. But if and only if an Action is refactored as a Command. Commons-chain is not intended to solve that debate topic originally. Last year, people found when they have two RequestProcessor(s), say A and B, if they need to design a new RequestProcessor C that has methods from both A and B, the best they can do is to let C extend one of them, say A, and then copy the methods (possibly line by line) from B. So a configurable RequestProcessor is somehow needed to reuse portions of several RequestProcessor(s). This is what commons-chain is intended to solve initially. Ay Ay, Captain! I don't mean to rain on the parade. I was involved in the composable request processor discussion way way back in the summer. As the Expresso core committer who integrated Struts 1.1 I found also a futuristic design issues merging the TilesRequestProcessor and our own ExpressoRequestProcessor. How would you merge the next processor, and the next one, and the next one after that. But the problems have not been cleanly solved in regard to reusability. When a Command is deeply coupled with other Command(s) in a chain through one or more flags/states in Context (say cancel flag, invalid token flag, invalid validation flag, etc.) its reusability in a different chain is very low in theory or very difficult to use (you need to configure many flags to get it work and subject to the condition the new Context offers the same set of flags). I dont understand the reusability problems. To me having read the Gang of Four original book, the design of Chain of Responsibilty and Craig's code and what he has said to me (to us) on list makes this a non-issue. Actual design pattern is a linear path. The only difference I can see is the context, which I guess you should treat it as opaque object any way. If you write a Command that need various context setting that you should declare in the javadoc or documentation. I did a little exercise to reduce the command coupling degree by introducing a NestCommand. Like LookupCommand to execute a specified chain, NestCommand always return false regardless what nested chain returns. So a termination of nested chains does not force a termination of calling chains when NestCommand is used. The following picture illustrates the idea: You said your NestCommand always returns `false' Main Chain: NestCommand Nested Chain: NestedCommand1 NestedCommand2 NestedCommand3 LastCommand If any nested commands return true, the control flow will *jump* to LastCommand. It seems to give an answer to my original question without the notion of branch behavior :-) And this paragraph NestCommand can return true. This conflicts with the first. What if NestCommand return false does that not terminate the chain, and thus stop LastCommand from executing. NestedCommand2 does not need to check any flag set by NestedCommand1 in this way and NestedCommand3 does not need to check any flags set by NestedCommand1 and 2. They could be reused in other chains without concerning about flags. It sounds to me like you trying to create conditional commands. A | B-D-E | C If B is a command that has IF THEN behaviour that is on a boolean flag V then if V == true then the order of execution is A,B,D,E,C (the execution terminates after C) otherwise V == false then order of
DO NOT REPLY [Bug 23864] New: - html radio tag, value attribute, special characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23864. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23864 html radio tag, value attribute, special characters Summary: html radio tag, value attribute, special characters Product: Struts Version: 1.1 Beta 1 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] We noticed that a string value containing html sensitive characters, such as etc., is not filtered / escaped for html:radio tag (the value of the radio input). This cause the resulting html page to break, as in the following browser view - [radio box here] checked=checked Blue User should see this - [radio box here] Blue After looking at the taglib source code, we know that HiddenTag, OptionsTag, TextareaTag, TextTag, etc, do escape the special characters, using ResponseUtils.filter method. However, RadioTag, CheckboxTag do not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23860] - warn if logic tags are prematurely terminated
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23860. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23860 warn if logic tags are prematurely terminated [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-10-16 13:42 --- Again, Struts never see's this, since the tag is never called in the first place. If you look in the generated html you'll probably see /logic:equal Again this would be a Jasper job to flag any unmatched ending tags that it --knows-- about. Again you can assign this to Jasper. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23864] - Escape special characters in html:radio value attribute
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23864. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23864 Escape special charactersin html:radio value attribute [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Summary|html radio tag, value |Escape special characters |attribute, special | in html:radio value |characters |attribute Version|1.1 Beta 1 |1.1 Final - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reviving PageController (ViewController?) discussion?
Is the PageController going to have an associated ActionForm? When preparing to display a new page, it is often the case that I want to have access to a new action form that I can populate with default values for the HTML form to display. The action form is probably not of the same type as the action form for the previously-executed action, as that action form was having its processing completed, while this new action form is just beginning its lifecycle. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts-chain Behavior Discussion
PILGRIM, Peter, FM wrote: -Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] - Original Message - From: PILGRIM, Peter, FM [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Sent: Monday, October 13, 2003 5:39 AM Subject: RE: Struts-chain Behavior Discussion *Question of Architecture* Does this mean that we have solved the hideous Action Chaining debate? In theory an Struts Action could be refactored to be a type of ``Command'' and therefor Actions could be chained. Whenever there is a debate and each side seems to be very reasonable in certain contexts, it is more likely the system itself is in-complete or fails to meet the requirements. We use Controller Delegation Model and/or Event Handler(s) to deal with such problems. What are you talking about here? What I am talking about or rather aiming the ability create common Struts components. Suppose team T1 invents a generic web search engine component. Let say another team T2 wanted to use that component, say embed it is in own JSP views using say Tiles. How does the search component forward or transfer control to the external component that T2. One way could be to use an action chain. First, one writes a Struts Action in such way that it puts a known public bean or put the bean in the form bean. Whatever. This Output Bean contains contains your search result or selected object. Second, one can generate a dynamic ActionForward that names the second Action to forward. But I am thinkgin Craig has given us an alternative option, of maybe using a Command to do this. But if and only if an Action is refactored as a Command. It sort of is in the existing proof of concept (i.e. there is an adapter Command that can call an existing Action), but that will be of more interest to people with existing code that want to use it in a CoR based request processor. I'm imagining that new code based on such a pattern would be constructed out of Commands in the first place. Commons-chain is not intended to solve that debate topic originally. Last year, people found when they have two RequestProcessor(s), say A and B, if they need to design a new RequestProcessor C that has methods from both A and B, the best they can do is to let C extend one of them, say A, and then copy the methods (possibly line by line) from B. So a configurable RequestProcessor is somehow needed to reuse portions of several RequestProcessor(s). This is what commons-chain is intended to solve initially. Ay Ay, Captain! I don't mean to rain on the parade. I was involved in the composable request processor discussion way way back in the summer. As the Expresso core committer who integrated Struts 1.1 I found also a futuristic design issues merging the TilesRequestProcessor and our own ExpressoRequestProcessor. How would you merge the next processor, and the next one, and the next one after that. But the problems have not been cleanly solved in regard to reusability. When a Command is deeply coupled with other Command(s) in a chain through one or more flags/states in Context (say cancel flag, invalid token flag, invalid validation flag, etc.) its reusability in a different chain is very low in theory or very difficult to use (you need to configure many flags to get it work and subject to the condition the new Context offers the same set of flags). I dont understand the reusability problems. To me having read the Gang of Four original book, the design of Chain of Responsibilty and Craig's code and what he has said to me (to us) on list makes this a non-issue. Actual design pattern is a linear path. The only difference I can see is the context, which I guess you should treat it as opaque object any way. If you write a Command that need various context setting that you should declare in the javadoc or documentation. The code I've written to date illustrates how I propose to reduce problems of interdependence between commands. For every case where your command expects an input attribute in the Context (or plans to create an output attribute), have a String property on the Command's implementation class made up of the attribute name with Key on the end, that documents the name of the attribute you intend to use. This does several things for you: * It self documents the appropriate attribute keys if you are diligent about applying this design pattern. * It makes the actual keys to be used configurable (improves reusability in different environments). * It means that your code can *ask* a Command instance where it stored something, or plans to store something, instead of just assuming. For example, the Command that selects an appropriate ActionConfig based on the input path (the Command version of the processMapping) needs to store the ActionConfig it found under an agreed-upon location in order for later commands to find it. Snippets of this class (AbstractSelectAction)
RE: Struts-chain Behavior Discussion
Pilgram, Peter wrote: -Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] - Original Message - From: PILGRIM, Peter, FM To: 'Struts Developers List' Sent: Monday, October 13, 2003 5:39 AM Subject: RE: Struts-chain Behavior Discussion *Question of Architecture* Does this mean that we have solved the hideous Action Chaining debate? In theory an Struts Action could be refactored to be a type of ``Command'' and therefor Actions could be chained. Whenever there is a debate and each side seems to be very reasonable in certain contexts, it is more likely the system itself is in-complete or fails to meet the requirements. We use Controller Delegation Model and/or Event Handler(s) to deal with such problems. What are you talking about here? What I am talking about or rather aiming the ability create common Struts components. --- I agree, common Struts components are the goal. Chains and variations on them or alternatives such as decorators, proxies and even unadulterated rejaminators are the means of getting there. --- Suppose team T1 invents a generic web search engine component. Let say another team T2 wanted to use that component, say embed it is in own JSP views using say Tiles. How does the search component forward or transfer control to the external component that T2. One way could be to use an action chain. First, one writes a Struts Action in such way that it puts a known public bean or put the bean in the form bean. Whatever. This Output Bean contains contains your search result or selected object. Second, one can generate a dynamic ActionForward that names the second Action to forward. But I am thinkgin Craig has given us an alternative option, of maybe using a Command to do this. But if and only if an Action is refactored as a Command. Commons-chain is not intended to solve that debate topic originally. Last year, people found when they have two RequestProcessor(s), say A and B, if they need to design a new RequestProcessor C that has methods from both A and B, the best they can do is to let C extend one of them, say A, and then copy the methods (possibly line by line) from B. So a configurable RequestProcessor is somehow needed to reuse portions of several RequestProcessor(s). This is what commons-chain is intended to solve initially. Ay Ay, Captain! I don't mean to rain on the parade. I was involved in the composable request processor discussion way way back in the summer. As the Expresso core committer who integrated Struts 1.1 I found also a futuristic design issues merging the TilesRequestProcessor and our own ExpressoRequestProcessor. How would you merge the next processor, and the next one, and the next one after that. --- I have encountered the same problem that you describe and that Craig says commons-chain is intended to solve initially. Last summer I posted code on this list for two Struts components. I called them action wrappers after the conceptual idea behind the implementation. These components use actions to decorate other actions. They add useful behavior which is unknown to the wrapped action just as a border is unknown to a bordered graphic or window. The implementation relies on a modified request processor invoking both the wrapping action and the wrapped action. I asked for a request processor refactoring but was ignored. Hopefully, the commons-chain implementation will permit the same functionality. As long as both actions can be invoked the components can still be used. But there is another piece to the component idea. Actions (chained, wrapped, or purple) usually need data to accomplish their mission. I'm not refering to application data available in the form bean; I'm refering to data which supports the component itself. An integral part of configuring a component is making the data available to it. For Struts this means the Struts configuration file and very possibly the ActionMapping (or ActionConfig). I haven't seen discussion on this related issue. --- John A. Sessler - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Do you Yahoo!? The New Yahoo! Shopping - with improved product search
RE: Reviving PageController (ViewController?) discussion?
At 11:41 -0400 10/16/03, Derek Richardson wrote: Is the PageController going to have an associated ActionForm? When preparing to display a new page, it is often the case that I want to have access to a new action form that I can populate with default values for the HTML form to display. The action form is probably not of the same type as the action form for the previously-executed action, as that action form was having its processing completed, while this new action form is just beginning its lifecycle. That basic idea (a different form for on-the-way-out-to-the-view than the one on-the-way-in-to-the-controller is really useful, and we've fudged something like on the current project, but I have to admit that while I've been waiting to get done with my current project and back to doing something about this conversation, it kind of looks like the struts-chain stuff is passing us by. See Ted's recent post copied in below... I'm definitely going to look at Chain before I invest a lot of energy in a PageController that works as earlier discussions have gone. Joe At 5:33 -0400 10/16/03, Ted Husted wrote: Ted Husted wrote: I think the Chain package will make it easier for people to do the Right Thing. The ActionForm properties, and so forth, can be commuted to a Context, and the Context passed up to a Chain which can do whatever it is they want to do. Just to check in ... I've been refactoring an application that started out using the page controller type actions into an architecture that uses view commands instead, and it seems to be working well. In cases where I want to forward directly to the page, I can use a single Command: command name=summary className=app.command.SummaryView / In cases where I need to do something else first, like look up a seed record or process an update, I can set up a Chain that executes the business operations first, and then runs the view command. For one interesting page, I have two chains running back to it, depending on which control is used: chain name=summary_select_applicant command className=app.command.SummaryList / command className=app.command.SummaryView / /chain chain name=summary_select_permit command className=app.command.Select / command className=app.command.SummaryList / command className=app.command.SummaryView / /chain So, in places where I had business actions forward to presentation actions, I'm now back to having command actions forward straight to the server pages again. Life is good. Ladies and gentlemen, I believe we've found the missing link =:) -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts-chain Behavior Discussion
- Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, October 16, 2003 4:37 AM Subject: Re: Struts-chain Behavior Discussion Jing Zhou wrote: Commons-chain is not intended to solve that debate topic originally. Last year, people found when they have two RequestProcessor(s), say A and B, if they need to design a new RequestProcessor C that has methods from both A and B, the best they can do is to let C extend one of them, say A, and then copy the methods (possibly line by line) from B. So a configurable RequestProcessor is somehow needed to reuse portions of several RequestProcessor(s). This is what commons-chain is intended to solve initially. The composable request processor is what finally got Craig to scratch the itch, but he's been mentioning the Chain of Responsibility pattern for some time, in several contexts (so to speak). I don't think it's fair to say Commons-Chain is intended to solve any specific Struts issue. The request processor brought the work to a head, but Chain speaks to the need for a business layer framework. The RequestProcessor is an example of where Struts needs to utilize what amounts to business logic. The rules we want the request processor to follow are not uniform and subject to a RFP, but may differ from application to application. In other words, we want to create arbitrary request processors -- and arbitrary often indicates that some flavor of business logic is in play. =:) It's true that the RequestProcessor is an important proof of concept, but, it's just the beginning. IMHO, Chain is intended to provide core utility that many business layer implementations share, which happens to include the request processor implementation. Another likely candidate in Struts space would be chaining validation commands. Yes. That's why I am saying it is intended to solve *initially*. Since common-chains is in sandbox status, more new concepts could be explored/debated and when it matures we'll have a solid foundation. -Ted. Jing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Eclipse to contribute to Struts
-cvs access- To access the apache cvs server in eclipse is very simple too. Search with pserver as the keyword under help(F1). The first hit should give you instruction on how to setup a new repository location. You can find all the necessary parameters on this page: http://www.apache.org/foundation/cvs.html -Original Message- From: Indrajit Raychaudhuri [mailto:[EMAIL PROTECTED] Sent: October 16, 2003 1:35 AM To: Struts Developers List Subject: Re: Using Eclipse to contribute to Struts http://jakarta.apache.org/struts/faqs/eclipse.html In case you are using Eclipse 3.0 (M4 or M5) or have some other preference, you'd need to to make some adjustments. It's a good starting point nevertheless. - Indrajit - Original Message - From: Hien Q Nguyen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, 16 October, 2003 09:21 Subject: Using Eclipse to contribute to Struts Hi, I'm trying to set up my local eclipse development environment since I want to start maybe writing some test cases or applying patches from the bug database. Is there a doc or howto on this? I did a search on the Dev mailing list archive but wasn't able to find anything relevant. Thanks. --Hien - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts-chain Behavior Discussion
- Original Message - From: PILGRIM, Peter, FM [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Sent: Thursday, October 16, 2003 5:09 AM Subject: RE: Struts-chain Behavior Discussion -Original Message- From: Jing Zhou [mailto:[EMAIL PROTECTED] - Original Message - From: PILGRIM, Peter, FM [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Sent: Monday, October 13, 2003 5:39 AM Subject: RE: Struts-chain Behavior Discussion *Question of Architecture* Does this mean that we have solved the hideous Action Chaining debate? In theory an Struts Action could be refactored to be a type of ``Command'' and therefor Actions could be chained. Whenever there is a debate and each side seems to be very reasonable in certain contexts, it is more likely the system itself is in-complete or fails to meet the requirements. We use Controller Delegation Model and/or Event Handler(s) to deal with such problems. What are you talking about here? What I am talking about or rather aiming the ability create common Struts components. I am talking about the Action Chaining debate (if we refer to the same problem) could be solved with fine grained controls in Action if the extended Action classes could provide event handlers or delegation model, or other similar facility. Commons-chain is not intended to solve that debate topic originally. Last year, people found when they have two RequestProcessor(s), say A and B, if they need to design a new RequestProcessor C that has methods from both A and B, the best they can do is to let C extend one of them, say A, and then copy the methods (possibly line by line) from B. So a configurable RequestProcessor is somehow needed to reuse portions of several RequestProcessor(s). This is what commons-chain is intended to solve initially. Ay Ay, Captain! I don't mean to rain on the parade. I was involved in the composable request processor discussion way way back in the summer. As the Expresso core committer who integrated Struts 1.1 I found also a futuristic design issues merging the TilesRequestProcessor and our own ExpressoRequestProcessor. How would you merge the next processor, and the next one, and the next one after that. But the problems have not been cleanly solved in regard to reusability. When a Command is deeply coupled with other Command(s) in a chain through one or more flags/states in Context (say cancel flag, invalid token flag, invalid validation flag, etc.) its reusability in a different chain is very low in theory or very difficult to use (you need to configure many flags to get it work and subject to the condition the new Context offers the same set of flags). I dont understand the reusability problems. To me having read the Gang of Four original book, the design of Chain of Responsibilty and Craig's code and what he has said to me (to us) on list makes this a non-issue. Actual design pattern is a linear path. The only difference I can see is the context, which I guess you should treat it as opaque object any way. Since you involved in the composable RequestProcessor discussion, the intention of such design is to *reuse* as much as possible the portions of different RequestProcessor(s). Instead of creating a new RequestProcessor for slightly different requirements, commons-chain could help to configure the new RequestProcessor in terms of a chain with its commands borrowed from existing commands for other RequestProcessor chains. So we could *reuse* the commands without creating new RequestProcessor class. If you write a Command that need various context setting that you should declare in the javadoc or documentation. I did a little exercise to reduce the command coupling degree by introducing a NestCommand. Like LookupCommand to execute a specified chain, NestCommand always return false regardless what nested chain returns. So a termination of nested chains does not force a termination of calling chains when NestCommand is used. The following picture illustrates the idea: You said your NestCommand always returns `false' Correct! So it never terminates calling chains by definition. Main Chain: NestCommand Nested Chain: NestedCommand1 NestedCommand2 NestedCommand3 LastCommand If any nested commands return true, the control flow will *jump* to LastCommand. It seems to give an answer to my original question without the notion of branch behavior :-) And this paragraph NestCommand can return true. This conflicts with the first. What if NestCommand return false does that not terminate the chain, and thus stop LastCommand from executing. No. NestCommand always return false. All possible execution paths are as follows: * Assuming all nested commands return false: NestCommand - NestedCommand1 -
Re: Struts-chain Behavior Discussion
PILGRIM, Peter, FM wrote: Suppose team T1 invents a generic web search engine component. Let say another team T2 wanted to use that component, say embed it is in own JSP views using say Tiles. How does the search component forward or transfer control to the external component that T2. One way could be to use an action chain. First, one writes a Struts Action in such way that it puts a known public bean or put the bean in the form bean. Whatever. This Output Bean contains contains your search result or selected object. Second, one can generate a dynamic ActionForward that names the second Action to forward. But I am thinkgin Craig has given us an alternative option, of maybe using a Command to do this. But if and only if an Action is refactored as a Command. Personally, I wouldn't bother dragging an Action into it. Just do the whole thing as a Command/Chain. The Action collect the parameters, puts them into the Context, and passes the Context down to Chain. Chain executes the search and passes the Context back. The Action's one and only job is as an adapter that transfers attributes between the HTTP Context and the Chain Context. I think when we start pursuing this strategy, servlets/actions as adapters, we start moving from Model 2 to Model 3. What's Model 3? Here's something I wrote up this morning: Model 1 uses a server page to conduct the business operations and render the dynamic data generated by the business operation. Model 2 uses a servlet to conduct the business case processing and a server page to render the dynamic data generated by the servlet. Model 3 uses an independent set of classes (POJOs) to conduct the business operations and a server page to render the dynamic data; a servlet (or filter) acts as a thin adapter between the business classes and server pages. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using Eclipse to contribute to Struts
Hi Indrajit, Thanks for replying. The link that you mentioned is geared toward more of Struts Users. I'm actually interested in getting Struts source code from the CVS repository and set up a project in eclipse so that I can tinker with Struts source code and soon hopefully I'd be able to contribute. I guess what I want to know is if any Struts developer uses Eclipse as their IDE for the development of Struts. If so, what is your set up like? Thanks, --Hien On Thursday, October 16, 2003, at 03:35 AM, Indrajit Raychaudhuri wrote: http://jakarta.apache.org/struts/faqs/eclipse.html In case you are using Eclipse 3.0 (M4 or M5) or have some other preference, you'd need to to make some adjustments. It's a good starting point nevertheless. - Indrajit - Original Message - From: Hien Q Nguyen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, 16 October, 2003 09:21 Subject: Using Eclipse to contribute to Struts Hi, I'm trying to set up my local eclipse development environment since I want to start maybe writing some test cases or applying patches from the bug database. Is there a doc or howto on this? I did a search on the Dev mailing list archive but wasn't able to find anything relevant. Thanks. --Hien - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Eclipse to contribute to Struts
I wrote an answer, but it got a bit long for this list, so I posted it on my web site for Hien and anyone else who's interested. http://www.ninsky.com/struts/eclipse.html Steve -Original Message- From: Hien Q Nguyen [mailto:[EMAIL PROTECTED] Sent: October 16, 2003 7:50 PM To: Struts Developers List Subject: Re: Using Eclipse to contribute to Struts Hi Indrajit, Thanks for replying. The link that you mentioned is geared toward more of Struts Users. I'm actually interested in getting Struts source code from the CVS repository and set up a project in eclipse so that I can tinker with Struts source code and soon hopefully I'd be able to contribute. I guess what I want to know is if any Struts developer uses Eclipse as their IDE for the development of Struts. If so, what is your set up like? Thanks, --Hien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Using Eclipse to contribute to Struts
James' version uses 'Check out As...' rather than 'Check out as Project'. That's probably better as you can set up the classpath and get the code completion feature etc. working more easily. My notes don't cover that at all so use his first. And he has pretty pictures :-) Steve -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: October 16, 2003 10:33 PM To: 'Struts Developers List' Subject: RE: Using Eclipse to contribute to Struts Here's a little something I put together also: http://www.struts-atlanta.org/helping-develop-struts/index.html -- James Mitchell Software Engineer / Struts Evangelist http://www.struts-atlanta.org 678.910.8017 AIM:jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
