RE: Eliminate Setup Actions
-Original Message- From: Ben Taylor [mailto:[EMAIL PROTECTED] Sent: 05 March 2005 08:03 To: Struts Users Mailing List Subject: Eliminate Setup Actions Hi, Can anyone tell me if there is an easy way to put information (required to populate drop down boxes using data from a db) in to the request, without having to write a setup Action for each page as is done here: http://www.reumann.net/struts/lesson2/step9.do . You could use ``DispatchAction'' and ``LookupDispatchAction'' for your multiple actions. In the some kind of ``DispatchAction'' write method to render the form `promptForm( ... )' and then another method `processForm( ... )' . hth -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
Many people would suggest that using Actions in Struts would be preferrable whether or not you need to do any setup or any processing in the movement from one page to another in a website. I think of Actions as places to organize what needs to be done (processing the request) and providing any dynamic navigation needed with the ActionForward return class. With the forward being determined in the Action, this is the ideal place to manage or to delegate management of the setup as well. Thus, I don't see any value in doing setup prior to coming to the action. This would be desireable, I think, only if you did not want to use the Action at all. If you are going to use the Action, this is an unnecessary complication I think. I may not understand the point, however. Certainly there seems to be a lot of interest in doing this, that is, providing pre-action setup. I am not sure why. This thread confuses me. I don't see the point at all. On Sat, 5 Mar 2005 08:03:04 +, Ben Taylor [EMAIL PROTECTED] wrote: Hi, Can anyone tell me if there is an easy way to put information (required to populate drop down boxes using data from a db) in to the request, without having to write a setup Action for each page as is done here: http://www.reumann.net/struts/lesson2/step9.do . Thank you for any help! -- No one ever went blind looking at the bright side of life. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
But do you see the point in setup functions *outside* an Action's code that occurs on the forward-level? Meaning, once an Action returns a forward, do some setup based on what forward was returned? If so, check out the Bugzilla ticket I opened today where I provide this functionality, as well as the pre-Action capability (which I think makes sense if you don't think about the timing... maybe there is setup that you want to perform regardless of which forward is returned by the Action... yes, it happens before the Action is executed, but it hardly matters whether it happens before or after execute() is called, as long as it happens regardles of the forward returned is the pertinent point). -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, March 9, 2005 1:55 pm, Shey Rab Pawo said: Many people would suggest that using Actions in Struts would be preferrable whether or not you need to do any setup or any processing in the movement from one page to another in a website. I think of Actions as places to organize what needs to be done (processing the request) and providing any dynamic navigation needed with the ActionForward return class. With the forward being determined in the Action, this is the ideal place to manage or to delegate management of the setup as well. Thus, I don't see any value in doing setup prior to coming to the action. This would be desireable, I think, only if you did not want to use the Action at all. If you are going to use the Action, this is an unnecessary complication I think. I may not understand the point, however. Certainly there seems to be a lot of interest in doing this, that is, providing pre-action setup. I am not sure why. This thread confuses me. I don't see the point at all. On Sat, 5 Mar 2005 08:03:04 +, Ben Taylor [EMAIL PROTECTED] wrote: Hi, Can anyone tell me if there is an easy way to put information (required to populate drop down boxes using data from a db) in to the request, without having to write a setup Action for each page as is done here: http://www.reumann.net/struts/lesson2/step9.do . Thank you for any help! -- No one ever went blind looking at the bright side of life. - 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: Eliminate Setup Actions
Well im in the camp of never show a jsp if you can get away with it so almost everything in the app is fronted by an action. Now lets say I have a class that gets a bunch of stuff out of a db, caches it, etc for dropdowns or whatever. And let's further suppose that the page (or tile) I want to show is needing these dropdowns, but its really an entrance page to the workflow so I really don't need to do anything in my action (other than potentially set up the dropdown stuff which would mostly be something like static calls on my class) Wouldn't it be better to just use ForwardAction with a configurable setup item class? Yes, I can do it in an action I write, but now I have 2 classes to maintain instead of one. Al -Original Message- From: Shey Rab Pawo [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 09, 2005 12:56 PM To: Struts Users Mailing List; Ben Taylor Subject: Re: Eliminate Setup Actions Many people would suggest that using Actions in Struts would be preferrable whether or not you need to do any setup or any processing in the movement from one page to another in a website. I think of Actions as places to organize what needs to be done (processing the request) and providing any dynamic navigation needed with the ActionForward return class. With the forward being determined in the Action, this is the ideal place to manage or to delegate management of the setup as well. Thus, I don't see any value in doing setup prior to coming to the action. This would be desireable, I think, only if you did not want to use the Action at all. If you are going to use the Action, this is an unnecessary complication I think. I may not understand the point, however. Certainly there seems to be a lot of interest in doing this, that is, providing pre-action setup. I am not sure why. This thread confuses me. I don't see the point at all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
On Wed, 9 Mar 2005 14:07:04 -0500 (EST), Frank W. Zammetti [EMAIL PROTECTED] wrote: But do you see the point in setup functions *outside* an Action's code that occurs on the forward-level? Meaning, once an Action returns a forward, do some setup based on what forward was returned? Yes. I do, I think, depending on what that occurs on the foward-level means. If there is a generic setup tied to a forward, I would write a setup class with a setup method that returns the ActionForward that is relevant and leave all other complications out of the picture. I don't understand the point of the complications. This seems to be a regular sort of thing that does not need the complications to me. maybe there is setup that you want to perform regardless of which forward is returned by the Action... yes, it happens before the Action is executed, but it hardly matters whether it happens before or after execute() is called, as long as it happens regardles of the forward returned is the pertinent point). I would then just write a class that does the setup and whenever that logic is needed use the class. I just don't see why this is not all easy given the present code and wonder why more is needed. I don't see the need for the extra complications. What is the problem? -- No one ever went blind looking at the bright side of life. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
More (application-level) code isn't needed... it's just a question of making it declarative rather than programmatic, which is how so much of Struts already is. Here's an example from the example app posted to the Bugzilla ticket I referenced (ticket # 33935 if you want to download it and try it)... I wrote a class SetupClass1. It contains three methods, setupMethod1(), setupMethod2() and setupMethod3() (I don't win any contests for creative naming today!). Now... let's say that setupMethod1() reads from a database and creates an ArrayList that is used to populate a dropdown. Let's further say that this dropdown is on a couple of pages in the app. Clearly it makes sense to have this setup code in a separate class. Now, as you were saying, you could just use this class from the Actions manually, that works fine, and plenty of people do that. But, it's extra code, and redundant code if used in more than one Action, even if the redundant code amounts to: SetupClass1.setupMethod1(request); (assuming its a static method). Instead, my proposal, and what I posted to Buzilla accomplishes this, is to allow this: action path=/page1 type=com.omnytex.setupexample.action.TestAction forward name=defaultForward path=/result.jsp setupItem setupClass=com.omnytex.setupexample.setups.SetupClass1 setupMethod=setupMethod1 / /forward /action So now, whenever that forward is returned the method will be executed. It is passed request, so it does whatever it does, presumably sticks the ArrayList in request as per the example, and everything else goes on as before. It's just a declarative approach to the programmatic solution. Now, the code I submitted allows you to put the setupItem element within forwards as shown here (that's what I meant by at the forward-level). You can ALSO put it at the mapping level, and those items get executed BEFORE execute() is called (as opposed to after, in the case of the forward-level elements). In addition, you can add setupItems to global forwards just the same. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, March 9, 2005 2:20 pm, Shey Rab Pawo said: On Wed, 9 Mar 2005 14:07:04 -0500 (EST), Frank W. Zammetti [EMAIL PROTECTED] wrote: But do you see the point in setup functions *outside* an Action's code that occurs on the forward-level? Meaning, once an Action returns a forward, do some setup based on what forward was returned? Yes. I do, I think, depending on what that occurs on the foward-level means. If there is a generic setup tied to a forward, I would write a setup class with a setup method that returns the ActionForward that is relevant and leave all other complications out of the picture. I don't understand the point of the complications. This seems to be a regular sort of thing that does not need the complications to me. maybe there is setup that you want to perform regardless of which forward is returned by the Action... yes, it happens before the Action is executed, but it hardly matters whether it happens before or after execute() is called, as long as it happens regardles of the forward returned is the pertinent point). I would then just write a class that does the setup and whenever that logic is needed use the class. I just don't see why this is not all easy given the present code and wonder why more is needed. I don't see the need for the extra complications. What is the problem? -- No one ever went blind looking at the bright side of life. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
This is more, not less, code, is it not? You have: setupItem setupClass=com.omnytex.setupexample.setups.SetupClass1 setupMethod=setupMethod1 / which has to be used for all actions that use this, right? compared to: SetupClass1.setupMethod1(request) I don't see the less code point. Looks like more code to me, but just a different kind of code. This is also only achieved at the expense of reflection, etc. I don't see the advantage at all so far. I am probably missing the point. I tend to think that Struts has about the right complications with the declarative options available. More, I think, might not be good. I probably am missing the point, however. On Wed, 9 Mar 2005 14:29:08 -0500 (EST), Frank W. Zammetti [EMAIL PROTECTED] wrote: Now, as you were saying, you could just use this class from the Actions manually, that works fine, and plenty of people do that. But, it's extra code, and redundant code if used in more than one Action, even if the redundant code amounts to: SetupClass1.setupMethod1(request); (assuming its a static method). Instead, my proposal, and what I posted to Buzilla accomplishes this, is to allow this: action path=/page1 type=com.omnytex.setupexample.action.TestAction forward name=defaultForward path=/result.jsp setupItem setupClass=com.omnytex.setupexample.setups.SetupClass1 setupMethod=setupMethod1 / /forward /action -- No one ever went blind looking at the bright side of life. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
On Wed, March 9, 2005 3:02 pm, Shey Rab Pawo said: This is more, not less, code, is it not? You have: setupItem setupClass=com.omnytex.setupexample.setups.SetupClass1 setupMethod=setupMethod1 / which has to be used for all actions that use this, right? compared to: SetupClass1.setupMethod1(request) If you consider lines in an XML file to be code, then you might have a point :) But even then, the two lines convey the exact same information, just a difference of a few characters... remember that, as shown here, the second line requires an import as well. So: import com.omnytex.setupexample.setups.SetupClass1; ... SetupClass1.setupMethod1(request); That's 86 characters, whereas my approach is 97 characters. 11 characters is, *technically* more code, but I think we're getting a hair too anal here :) And again, that's only if you consider lines in an XML file to be code. Consider that my approach doesn't require a recompile if I need to change something, which is of course the attraction of ANY configuration file. This is also only achieved at the expense of reflection, etc. I don't see the advantage at all so far. I am probably missing the point. I tend to think that Struts has about the right complications with the declarative options available. More, I think, might not be good. I probably am missing the point, however. I concede the reflection point. I've always tried to stay away from reflection myself in the name of performance, but frankly reflection performance isn't the problem it used to be. And, remember that reflection is used A LOT throughout Struts (how do you think ActionForms get populated for example??), so what's a little more? If it means I don't have to recompile to change what setup functions get performed, its worth it to me. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, 9 Mar 2005 14:29:08 -0500 (EST), Frank W. Zammetti [EMAIL PROTECTED] wrote: Now, as you were saying, you could just use this class from the Actions manually, that works fine, and plenty of people do that. But, it's extra code, and redundant code if used in more than one Action, even if the redundant code amounts to: SetupClass1.setupMethod1(request); (assuming its a static method). Instead, my proposal, and what I posted to Buzilla accomplishes this, is to allow this: action path=/page1 type=com.omnytex.setupexample.action.TestAction forward name=defaultForward path=/result.jsp setupItem setupClass=com.omnytex.setupexample.setups.SetupClass1 setupMethod=setupMethod1 / /forward /action -- No one ever went blind looking at the bright side of life. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
On Wed, March 9, 2005 3:11 pm, Frank W. Zammetti said: On Wed, March 9, 2005 3:02 pm, Shey Rab Pawo said: This is more, not less, code, is it not? You have: setupItem setupClass=com.omnytex.setupexample.setups.SetupClass1 setupMethod=setupMethod1 / which has to be used for all actions that use this, right? Forgot to reply to that last line... yes, it has to be used for every action that used that setupItem, *or* every forward that uses it. But that's no different than having to have the actual line of code calling the static method in every class that needs it. Plus, this helps keep things separated better, especially with forwards... consider the case where an Action may return one of five different forwards. Each of those forwards may require different setup functions be called. But the setup functions are really associated with the JSP your going to, NOT the Action that just completed. Why should the Action have to execute setup for a page that comes *after* it? That's not really proper separation of responsibilities, right? I guess the argument isn't as strong for the actionmapping-level setups, but I think of those more as these have to get done no matter what happens, and with that in mind, why add code for it? Better to let Struts to it for me, just like I let Struts populate my ActionForm for me. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Eliminate Setup Actions
I think the real power here is NOT in whether it is more or less code, but the move to a declarative way of handling the setup. I can compare it to the bean factory portion of spring. Technically I may write more code to use Spring. I certainly have to include other resources (spring jars) to use it, but it is extremely powerful. Now everything is in an xml file that I can change easily. So I no longer want to use SetupClass1 and method1 instead I use SetupClass52. I just go in and change the descriptor and in a matter of minutes I have made ALL my changes in a single file, instead of in every action where I am using it. It's a matter of convenience. I have been there enough times, and I am sure others have, to know that changing that all in a single file is a LOT faster than going through hundreds of files searching for SetupClass1.setupMethod1(request). Or the worse case searching for that in a project that you got attached to at the last minute and need to make the change... are you sure you caught them all? Al -Original Message- From: Shey Rab Pawo [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 09, 2005 2:02 PM To: Frank W. Zammetti Cc: Struts Users Mailing List; Ben Taylor Subject: Re: Eliminate Setup Actions This is more, not less, code, is it not? You have: setupItem setupClass=com.omnytex.setupexample.setups.SetupClass1 setupMethod=setupMethod1 / which has to be used for all actions that use this, right? compared to: SetupClass1.setupMethod1(request) I don't see the less code point. Looks like more code to me, but just a different kind of code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
Frank, watch that anal talk, would you? I could do without that. :) My point was just that I don't see a problem and don't understand how this would help. -- No one ever went blind looking at the bright side of life. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
I can't state it any clearer than I have, or any clearer than another poster (I forget who) just did a few minutes ago. If for absolutely no other reason, convenience and ease of change are good justifications. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Wed, March 9, 2005 3:37 pm, Shey Rab Pawo said: Frank, watch that anal talk, would you? I could do without that. :) My point was just that I don't see a problem and don't understand how this would help. -- No one ever went blind looking at the bright side of life. - 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: Eliminate Setup Actions[Scanned]
We probably have beat this to death, Frank, but having the framework setup pages with declarations in the action mappings is not consistent with MVC to my way of thinking. I definitley would not do this. I like to keep things simpler. But, others seem to like it. So, maybe you have something there. I probably am just being resistent to change. No more to say on this for me. -- No one ever went blind looking at the bright side of life. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
Can you add this XML functionality to the struts-config please? Then I won't hate you:) BusinessApplication start read_client_mind write application for me while I surf web /read_client_mind /start deploy/ getPayCheckAndGoHome/ /BusinessApplication Frank W. Zammetti wrote the following on 3/9/2005 4:15 PM: On Wed, March 9, 2005 4:07 pm, Rick Reumann said: (Hope you take the right way Frank.. because it is very cool:) Of course I do Rick... YOU HATE ME!! :) Seriously though... I do agree with much of what you say... I've always been of the get those stupid XML files away from me and just write some CODE!... I guess my mindset is changing a little bit lately as I see more the benefit of the declarative approach. One more point to add to this... In my environment, we have a rather convoluted change management process in place. Any code that gets deployed to production takes on average 96 hours to get through it all. Painful to say the least. This isn't exactly unusual in large enterprise environments (maybe not quite THAT long though!). However, the people in charge of that process DO NOT have a problem with me changing config files and restarting the app any time I need to. So, for me, the more that is declarative the better. Certainly not every place is like that, it might even be the minority, but its not unheard of. Something like this could be a big help. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
An extension of the approach here is what we so with the Oracle ADF framework, namely that of associating a metadata XML file with the Action which drives the runtime framework to prepare the bindings for the page. So this is taking the whole declarative thing that much further by basically pushing all back end access into JSR 227 compliant data bindings. Duncan Frank W. Zammetti wrote: More (application-level) code isn't needed... it's just a question of making it declarative rather than programmatic, which is how so much of Struts already is. Here's an example from the example app posted to the Bugzilla ticket I referenced (ticket # 33935 if you want to download it and try it)... I wrote a class SetupClass1. It contains three methods, setupMethod1(), setupMethod2() and setupMethod3() (I don't win any contests for creative naming today!). Now... let's say that setupMethod1() reads from a database and creates an ArrayList that is used to populate a dropdown. Let's further say that this dropdown is on a couple of pages in the app. Clearly it makes sense to have this setup code in a separate class. Now, as you were saying, you could just use this class from the Actions manually, that works fine, and plenty of people do that. But, it's extra code, and redundant code if used in more than one Action, even if the redundant code amounts to: SetupClass1.setupMethod1(request); (assuming its a static method). Instead, my proposal, and what I posted to Buzilla accomplishes this, is to allow this: action path=/page1 type=com.omnytex.setupexample.action.TestAction forward name=defaultForward path=/result.jsp setupItem setupClass=com.omnytex.setupexample.setups.SetupClass1 setupMethod=setupMethod1 / /forward /action So now, whenever that forward is returned the method will be executed. It is passed request, so it does whatever it does, presumably sticks the ArrayList in request as per the example, and everything else goes on as before. It's just a declarative approach to the programmatic solution. Now, the code I submitted allows you to put the setupItem element within forwards as shown here (that's what I meant by at the forward-level). You can ALSO put it at the mapping level, and those items get executed BEFORE execute() is called (as opposed to after, in the case of the forward-level elements). In addition, you can add setupItems to global forwards just the same. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
Sorry, I haven't been following this whole thread, but when I saw this config example from Frank: action path=myAction type=com.omnytex.actions.MyAction setupItem class=com.omnytex.setup.MyActionSetup method=setupMethod1 / forward name=defaultForward path=page1.jsp setupItem class=com.omnytex.setup.MyDefaultSetup method=defSetup1 / /forward /action I wondered why not use chain? In Struts 1.3, you can specify a command in the action element which will be executed before Struts processes the action, forward, or include specified in the same element. I haven't done anything about it yet, but I've kind of been expecting to add a similar kind of configuration value to forward elements. It is probably the most straightforward way to plug-in the kind of page-prep behavior that I've hacked in to other apps. Since there is a DispatchCommand in commons-chain (the post 1.0, as yet unreleased version), you could achieve exactly this, with the only difference being that some of the configuration goes in another file -- a chain-config.xml If I missed something in other messages on this thread, please fill me in... 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: Eliminate Setup Actions
No Joe, you didn't miss anything :) I was already thinking about how easy this would be under 1.3 too. But, I'm hesitant to start playing with 1.3 until it's actually released (at least in beta). This is an easy add to 1.3, as you indicate, and I'm also looking forward to porting my StrutsWS project over to it since I think that will be a nice demonstration of why chain is cool. I just don't want to start playing with something that isn't really stabilized yet (close thought, right?). And besides, something like this seems to be getting a fair amount of interest, so someone would eventually want to back-port it if I started with 1.3. Since we both believe it will be quite easy under 1.3, why not start with the 1.x branch where it's a bit more work? :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, March 8, 2005 9:23 am, Joe Germuska said: Sorry, I haven't been following this whole thread, but when I saw this config example from Frank: action path=myAction type=com.omnytex.actions.MyAction setupItem class=com.omnytex.setup.MyActionSetup method=setupMethod1 / forward name=defaultForward path=page1.jsp setupItem class=com.omnytex.setup.MyDefaultSetup method=defSetup1 / /forward /action I wondered why not use chain? In Struts 1.3, you can specify a command in the action element which will be executed before Struts processes the action, forward, or include specified in the same element. I haven't done anything about it yet, but I've kind of been expecting to add a similar kind of configuration value to forward elements. It is probably the most straightforward way to plug-in the kind of page-prep behavior that I've hacked in to other apps. Since there is a DispatchCommand in commons-chain (the post 1.0, as yet unreleased version), you could achieve exactly this, with the only difference being that some of the configuration goes in another file -- a chain-config.xml If I missed something in other messages on this thread, please fill me in... 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
At 9:37 AM -0500 3/8/05, Frank W. Zammetti wrote: No Joe, you didn't miss anything :) I was already thinking about how easy this would be under 1.3 too. But, I'm hesitant to start playing with 1.3 until it's actually released (at least in beta). This is an easy add to 1.3, as you indicate, and I'm also looking forward to porting my StrutsWS project over to it since I think that will be a nice demonstration of why chain is cool. I just don't want to start playing with something that isn't really stabilized yet (close thought, right?). And besides, something like this seems to be getting a fair amount of interest, so someone would eventually want to back-port it if I started with 1.3. Since we both believe it will be quite easy under 1.3, why not start with the 1.x branch where it's a bit more work? :) I do think we're pretty close, although not much has happened since the last wave of what will 1.3.0 be discussions. I know I haven't had much time for development and documentation in the last few weeks. I guess I was just wondering how you were going to deal with some considerable changes to the XML configuration syntax. Certainly, it's possible to add Digester rules to handle XML extensions, and you could probably get away with simply leaving out a DOCTYPE declaration so as to avoid validation problems. (Extending the DTD is probably more trouble than its worth.) Then again, undertaking a new initiative in which people are interested using 1.3.0 functionality would help us to get people testing and verifying that code, which is an unglamorous but critical part of development. 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: Eliminate Setup Actions
On Tue, March 8, 2005 9:48 am, Joe Germuska said: I do think we're pretty close, although not much has happened since the last wave of what will 1.3.0 be discussions. I know I haven't had much time for development and documentation in the last few weeks. I know the feeling :) I'm actually surprised I have time today to play myself! I pulled down the nightly of 1.3 that was posted a week or two ago (I think I was the first to discover the problem with the Maven build not working). I haven't went back to it since. Glad to here its close though, I'm looking forward to touching it. I guess I was just wondering how you were going to deal with some considerable changes to the XML configuration syntax. Certainly, it's possible to add Digester rules to handle XML extensions, and you could probably get away with simply leaving out a DOCTYPE declaration so as to avoid validation problems. (Extending the DTD is probably more trouble than its worth.) You mean as far as 1.x goes? I'm just looking now to see how the config file is read in (haven't played with Digester at all yet). But yes, just dropping the doctype was how I was going to, temporarily, get around any validation problems. I figured either (a) what I do gets added to the core and the DTD gets updated at that point, or (b) people can use it as a contrib thing with the knowledge that they have to drop the doctype (or updated the DTD themselves and keep it local I suppose). Then again, undertaking a new initiative in which people are interested using 1.3.0 functionality would help us to get people testing and verifying that code, which is an unglamorous but critical part of development. Ah, there's the alterior motive :) Seriously though, I hear what your saying... But, since I can see using this functionality myself in current projects, and since they aren't going to move to 1.3 for a while even after the gold release, my itch at the moment is unfortunately not going to help achieve your goal. If my schedule stays light for a few more days though, I could see taking another crack at the current 1.3 and maybe doing both this and StrutsWS. Joe Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
On Tue, 8 Mar 2005 10:14:36 -0500 (EST), Frank W. Zammetti [EMAIL PROTECTED] wrote: You mean as far as 1.x goes? I'm just looking now to see how the config file is read in (haven't played with Digester at all yet). But yes, just dropping the doctype was how I was going to, temporarily, get around any validation problems. I figured either (a) what I do gets added to the core and the DTD gets updated at that point, or (b) people can use it as a contrib thing with the knowledge that they have to drop the doctype (or updated the DTD themselves and keep it local I suppose). Ok, thanks for clarifying that. For a while I got confused, because Joe was talking about extending the DTD and going around validation, when I thought you meant to look at contributing it to the core. On Tue, 8 Mar 2005 08:23:44 -0600, Joe Germuska [EMAIL PROTECTED] wrote: I haven't done anything about it yet, but I've kind of been expecting to add a similar kind of configuration value to forward elements. It is probably the most straightforward way to plug-in the kind of page-prep behavior that I've hacked in to other apps. And I've been silently wishing you'd add it, too. :) We've had discussions about this maybe twice before, and another time I lit the flame, you responded, but I wasn't able to follow through with the discussion. The first exchange on this I participated in, Joe brought up the idea of having renderers/controllers tied to forms, and my concern was having multiple forms needed for a single forward. Here's a busy config idea I came to based on those discussions: http://marc.theaimsgroup.com/?l=struts-devm=10791806471w=2 (Looking at that date, this was almost a full year ago.) Taking into consideration Chain and ActionContext, these could be implemented with commands specifically written for these purposes without having to implement another interface. A POJO leaning would require the method parameter that Frank has. I think either of these are preferrable to having a PageController or Renderer superclass/interface that earlier threads mentioned, but it might be helpful to review those messages as there were some ideas and considerations mentioned there. http://marc.theaimsgroup.com/?t=10647864064r=1w=2 http://marc.theaimsgroup.com/?t=11050294625r=1w=2 Hubert (I'm guessing further discussion on details can/should move to the dev list) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
LOL, sorry Frank, I didn't mean to drown you in documentation. :) On Tue, 8 Mar 2005 09:31:04 -0600, Hubert Rabago [EMAIL PROTECTED] wrote: On Tue, 8 Mar 2005 10:14:36 -0500 (EST), Frank W. Zammetti [EMAIL PROTECTED] wrote: it might be helpful to review those messages as there were some ideas and considerations mentioned there. http://marc.theaimsgroup.com/?t=10647864064r=1w=2 http://marc.theaimsgroup.com/?t=11050294625r=1w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
And I've been silently wishing you'd add it, too. :)
We've had discussions about this maybe twice before, and another time
I lit the flame, you responded, but I wasn't able to follow through
with the discussion.
Well, then, now you've gone and done it, Hubert... I've just
committed the basic support for per-forward commands.
I think the next step would be to write a simple command which looks
something like this:
public class FormPrepCommand implements Command {
private String formName; // property
private String formScope; // property
public boolean execute(Context context) {
if (this.formName != null) {
ActionContext actionCtx = (ActionContext) context;
ActionForm form = lookupForm(formName,formScope, actionCtx);
prepareForm(actionCtx, form);
return false;
}
}
protected ActionForm lookupForm(String formName, String formScope,
ActionContext ctx) {
// standard behavior for looking up a form and making sure its in
the right request/session scope
// classes would rarely override this; maybe it would be private.
}
protected abstract void prepareForm(ActionContext ctx, ActionForm form);
}
Then one could use one or more of these in a per-forward chain of
renders. Of course other commands could do non-form oriented setup.
Related to what I just checked in, I still like a model where rather
than configuring command and catalog on each ForwardConfig, a lookup
is done based on the path value of the ForwardConfig. No reason
not to have both, of course, but I just think my style would be to
have a catalog named page-prep and a different command in
process-view which worked this way.
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: Eliminate Setup Actions
For anyone interested, I have a Struts View demo which that allows dialogs to occur in Struts 1.3. This could work in Struts 1.2, but I haven't had the 3 minutes to write an extended RequestProcessor for current apps. Basically, a dialog allows objects to persist across HTTP requests. Please give any feedback if you decide to use it: http://members.aol.com/benedictpa/struts-view/ Thanks, Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
I just found this link which gives FAR more detail on Tiles Controllers -- http://www.theserverside.com/articles/article.tss?l=Tiles101 On Sat, 5 Mar 2005 13:15:44 -0600, Corey Probst [EMAIL PROTECTED] wrote: If your app is using tiles, take a look at Tile controllers. http://struts.apache.org/api/org/apache/struts/tiles/Controller.html The controller will get called right before rendering the jsp, allowing you to put your info into the request. Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Dave [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
You could call the action directly (instead of the .jsp) and have the action add the options to the request if they're not already there, then forward. - Original Message - From: Ben Taylor [EMAIL PROTECTED] To: Struts Users Mailing List user@struts.apache.org Sent: Saturday, March 05, 2005 12:03 AM Subject: Eliminate Setup Actions Hi, Can anyone tell me if there is an easy way to put information (required to populate drop down boxes using data from a db) in to the request, without having to write a setup Action for each page as is done here: http://www.reumann.net/struts/lesson2/step9.do . Thank you for any help! - 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: Eliminate Setup Actions
You could populate static combo boxes with data stored as application scope attributes that are set at app startup by either a ServletContextListener or a Struts PlugIn (those attributes will be available to any JSP in the app). Erik Ben Taylor wrote: Hi, Can anyone tell me if there is an easy way to put information (required to populate drop down boxes using data from a db) in to the request, without having to write a setup Action for each page as is done here: http://www.reumann.net/struts/lesson2/step9.do . Thank you for any help! - 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: Eliminate Setup Actions
If your app is using tiles, take a look at Tile controllers. http://struts.apache.org/api/org/apache/struts/tiles/Controller.html The controller will get called right before rendering the jsp, allowing you to put your info into the request. Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
Someone else made some good suggestions about listeners and plugins. These will work well if the dropdown contents are truly static. If however it might be the kind of values that you want to make sure are up-to-date, i.e., read from a database maybe... Then one simple solution is create yourself a class that is basically independant from your application that is used for setup for a paricular screen or set of screens. Create a static method for the setup, then from any Action associated with a page that needs that data, just call that static method at the start of the Action. Simple, one line of code per Action and one import (or none, if it's in the same package). I would create static members of the setup class for the attribute names, and make the static setup method(s) return something like an ArrayList (or whatever type you need), so that you can call it from your Actions with something like: request.setAttribute(MySetupClass.MY_ATTRIBUTE_NAME, MySetupClass.doSetup()); That way you aren't tied to it being a webapp, should you need to do a different presentation layer later. I think this is a decent, simple approach to this type of thing. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Ben Taylor wrote: Hi, Can anyone tell me if there is an easy way to put information (required to populate drop down boxes using data from a db) in to the request, without having to write a setup Action for each page as is done here: http://www.reumann.net/struts/lesson2/step9.do . Thank you for any help! - 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: Eliminate Setup Actions
I think this solution is the bomb. I once suggested a generic solution like this for Struts called StrutsState. No one was much interested, so I just built it for my own work. It is so helpful that I cannot express my gratitude toward myself to myself. ///;-) On Sat, 05 Mar 2005 14:27:08 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: Someone else made some good suggestions about listeners and plugins. These will work well if the dropdown contents are truly static. If however it might be the kind of values that you want to make sure are up-to-date, i.e., read from a database maybe... Then one simple solution is create yourself a class that is basically independant from your application that is used for setup for a paricular screen or set of screens. Create a static method for the setup, then from any Action associated with a page that needs that data, just call that static method at the start of the Action. Simple, one line of code per Action and one import (or none, if it's in the same package). I would create static members of the setup class for the attribute names, and make the static setup method(s) return something like an ArrayList (or whatever type you need), so that you can call it from your Actions with something like: request.setAttribute(MySetupClass.MY_ATTRIBUTE_NAME, MySetupClass.doSetup()); That way you aren't tied to it being a webapp, should you need to do a different presentation layer later. I think this is a decent, simple approach to this type of thing. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Ben Taylor wrote: Hi, Can anyone tell me if there is an easy way to put information (required to populate drop down boxes using data from a db) in to the request, without having to write a setup Action for each page as is done here: http://www.reumann.net/struts/lesson2/step9.do . Thank you for any help! - 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] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
I for one would be interested in such a thing. I was starting to think about how to do this in a generic enough way too... I was actually thinking of doing it declaratively, i.e., for each Action mapping you could specify a list of setup methods to call, and Struts would go ahead and do that right before it called your Action's execute(). I figured you'd specify the class and method to call, although even easier would be to write an actual SetupAction class, or something along those lines, with a known interface that all these classes would have to implement, then you would just specify the class and Struts would know what method to call. But, that would probably mean only one setup method per setup class, and I'm not sure that would be optimal. I'm kind of babbling here :), but the basic idea I do like. Did you post your StrutsState proposal anywhere? I'd be interested in seeing it. I wonder if we were thinking along the same lines? Then again, I know *someone* is going to point out that Shale (or I guess JSF generically?) already has this notion ingrained in it. That might well be true, and I know neither of us are the first people to mention such an idea (I've seen mention of this before numerous times), but I for one think such a thing added to classic Struts would be very nice indeed. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Dakota Jack wrote: I think this solution is the bomb. I once suggested a generic solution like this for Struts called StrutsState. No one was much interested, so I just built it for my own work. It is so helpful that I cannot express my gratitude toward myself to myself. ///;-) On Sat, 05 Mar 2005 14:27:08 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: Someone else made some good suggestions about listeners and plugins. These will work well if the dropdown contents are truly static. If however it might be the kind of values that you want to make sure are up-to-date, i.e., read from a database maybe... Then one simple solution is create yourself a class that is basically independant from your application that is used for setup for a paricular screen or set of screens. Create a static method for the setup, then from any Action associated with a page that needs that data, just call that static method at the start of the Action. Simple, one line of code per Action and one import (or none, if it's in the same package). I would create static members of the setup class for the attribute names, and make the static setup method(s) return something like an ArrayList (or whatever type you need), so that you can call it from your Actions with something like: request.setAttribute(MySetupClass.MY_ATTRIBUTE_NAME, MySetupClass.doSetup()); That way you aren't tied to it being a webapp, should you need to do a different presentation layer later. I think this is a decent, simple approach to this type of thing. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Ben Taylor wrote: Hi, Can anyone tell me if there is an easy way to put information (required to populate drop down boxes using data from a db) in to the request, without having to write a setup Action for each page as is done here: http://www.reumann.net/struts/lesson2/step9.do . Thank you for any help! - 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: Eliminate Setup Actions
... I figured you'd specify
the class and method to call, although even easier would be
to write an actual SetupAction class, or something along
those lines, with a known interface that all these classes
would have to implement, then you would just specify the
class and Struts would know what method to call.
Erm, what about the constructor? Or the static{} part?
Regards
Leon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
... I figured you'd specify
the class and method to call, although even easier would be
to write an actual SetupAction class, or something along
those lines, with a known interface that all these classes
would have to implement, then you would just specify the
class and Struts would know what method to call.
Erm, what about the constructor? Or the static{} part?
Regards
Leon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
Sure, that would work. But, then you are limiting the developer to
basically one setup per class, or forcing them to do some work that
Struts really should be doing...
If I were to add something like this to Struts (and I have enough
interest in this idea that I'd love to persue it, assuming there is some
general interest), one of the requirements in my mind would be the
ability to call any number of setup methods per mapping.
For instance, maybe I have a page with 10 different dropdowns. Maybe I
determine that the way I want to implement that setup is to have ten
different methods in my setup class and specify them all to execute in
the mapping. Sure, I could call all ten of them from the constructor,
but that just *feels* like a bit of a hack to me. I'd prefer a more
IoC-esque approach, and this feels like the exact opposite. I'd want to
be able to explitidly declare the ten methods I want executed (and in
the stated order of course) rather than having to code that
functionality into the setup class itself, which is what I'd be forced
to do in the constructor (ditto for a static block).
There is a debate in my mind whether the setup class should have to
implement some given interface... It makes sense to do so because then
Struts can be sure the class is of an appropriate type for the task.
But, to allow for multiple setup methods the interface would have to be
defined to include setupMethod1(), setupMethod2(), setupMethod3() and so
on. That's pretty obviously a bad design. So, I imagine the interface
would pretty much just be a tag interface, and we would have to assume
that if the developer implements the interface, then whatever methods
are present in the class are meant for setup. Like I said though,
there's a bit of debate in my own head on this point right now.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Leon Rosenberg wrote:
... I figured you'd specify
the class and method to call, although even easier would be
to write an actual SetupAction class, or something along
those lines, with a known interface that all these classes
would have to implement, then you would just specify the
class and Struts would know what method to call.
Erm, what about the constructor? Or the static{} part?
Regards
Leon
-
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: Eliminate Setup Actions
On Sat, 05 Mar 2005 17:56:40 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: Then again, I know *someone* is going to point out that Shale (or I guess JSF generically?) already has this notion ingrained in it. But of course! :-) In Shale, a ViewController bean (pretty much the equivalent of ActionForm+Action) has callback methods that the framework calls for you: - init() -- called if this page is going to either process a postback or be rendered - preprocess() - called if we are about to process a postback (form submit) for the corresponding page - prerender() - called if we are about to be rendered - destroy() - called if init() was ever called To the original question about getting rid of the setup action, the Shale approach is to put that kind of setup stuff (populating dropdown list options, etc.) in the prerender() method, which will be called *only* if we are the page that is going to be rendered -- thus avoiding needless work if you navigated somewhere else instead. For Struts 1.x, the setup method or setup helper class idea seems reasonable, unless you are using Tiles. In that case, use a Tiles Controller, which is almost the same thing as the Shale prerender() method -- it is called just before that tile is rendered, and is (again) the right place for this sort of setup behavior. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
You could use / write a common configuration framework, which would be
instantiated by the action servlet, and where all configuration objects are
stored / managed. An action would then obtain it's specific configuration
object
in constructor, or even better in execute(). Last one would allow to change
the configuration on the fly, without
restart or anything.
Actually we are using something like this but for services. It's based on
propertyfiles and a simple watcher thread, which checks all registered
files, and if they changes calls:
notifyConfigurationStarted();
setProperty(name, value) for each property in file
notifyConfigurationFinished();
it's absolutely simple, but works superb, we are using it to reconfigure
caches, switch databases switch legacy systems on and off.
Is it IoC enough for you?:-)
Regards
Leon
-Ursprüngliche Nachricht-
Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 6. März 2005 00:14
An: Struts Users Mailing List
Betreff: Re: Eliminate Setup Actions
Sure, that would work. But, then you are limiting the
developer to basically one setup per class, or forcing them
to do some work that Struts really should be doing...
If I were to add something like this to Struts (and I have
enough interest in this idea that I'd love to persue it,
assuming there is some general interest), one of the
requirements in my mind would be the ability to call any
number of setup methods per mapping.
For instance, maybe I have a page with 10 different
dropdowns. Maybe I determine that the way I want to
implement that setup is to have ten different methods in my
setup class and specify them all to execute in the mapping.
Sure, I could call all ten of them from the constructor, but
that just *feels* like a bit of a hack to me. I'd prefer a
more IoC-esque approach, and this feels like the exact
opposite. I'd want to be able to explitidly declare the ten
methods I want executed (and in the stated order of course)
rather than having to code that functionality into the setup
class itself, which is what I'd be forced to do in the
constructor (ditto for a static block).
There is a debate in my mind whether the setup class should
have to implement some given interface... It makes sense to
do so because then Struts can be sure the class is of an
appropriate type for the task.
But, to allow for multiple setup methods the interface would
have to be defined to include setupMethod1(), setupMethod2(),
setupMethod3() and so on. That's pretty obviously a bad
design. So, I imagine the interface would pretty much just
be a tag interface, and we would have to assume that if the
developer implements the interface, then whatever methods are
present in the class are meant for setup. Like I said
though, there's a bit of debate in my own head on this point
right now.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Leon Rosenberg wrote:
... I figured you'd specify
the class and method to call, although even easier would be
to write
an actual SetupAction class, or something along those lines, with a
known interface that all these classes would have to
implement, then
you would just specify the class and Struts would know what
method to
call.
Erm, what about the constructor? Or the static{} part?
Regards
Leon
-
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: Eliminate Setup Actions
You could use / write a common configuration framework, which would be
instantiated by the action servlet, and where all configuration objects are
stored / managed. An action would then obtain it's specific configuration
object
in constructor, or even better in execute(). Last one would allow to change
the configuration on the fly, without
restart or anything.
Actually we are using something like this but for services. It's based on
propertyfiles and a simple watcher thread, which checks all registered
files, and if they changes calls:
notifyConfigurationStarted();
setProperty(name, value) for each property in file
notifyConfigurationFinished();
it's absolutely simple, but works superb, we are using it to reconfigure
caches, switch databases switch legacy systems on and off.
Is it IoC enough for you?:-)
Regards
Leon
-Ursprüngliche Nachricht-
Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 6. März 2005 00:14
An: Struts Users Mailing List
Betreff: Re: Eliminate Setup Actions
Sure, that would work. But, then you are limiting the
developer to basically one setup per class, or forcing them
to do some work that Struts really should be doing...
If I were to add something like this to Struts (and I have
enough interest in this idea that I'd love to persue it,
assuming there is some general interest), one of the
requirements in my mind would be the ability to call any
number of setup methods per mapping.
For instance, maybe I have a page with 10 different
dropdowns. Maybe I determine that the way I want to
implement that setup is to have ten different methods in my
setup class and specify them all to execute in the mapping.
Sure, I could call all ten of them from the constructor, but
that just *feels* like a bit of a hack to me. I'd prefer a
more IoC-esque approach, and this feels like the exact
opposite. I'd want to be able to explitidly declare the ten
methods I want executed (and in the stated order of course)
rather than having to code that functionality into the setup
class itself, which is what I'd be forced to do in the
constructor (ditto for a static block).
There is a debate in my mind whether the setup class should
have to implement some given interface... It makes sense to
do so because then Struts can be sure the class is of an
appropriate type for the task.
But, to allow for multiple setup methods the interface would
have to be defined to include setupMethod1(), setupMethod2(),
setupMethod3() and so on. That's pretty obviously a bad
design. So, I imagine the interface would pretty much just
be a tag interface, and we would have to assume that if the
developer implements the interface, then whatever methods are
present in the class are meant for setup. Like I said
though, there's a bit of debate in my own head on this point
right now.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Leon Rosenberg wrote:
... I figured you'd specify
the class and method to call, although even easier would be
to write
an actual SetupAction class, or something along those lines, with a
known interface that all these classes would have to
implement, then
you would just specify the class and Struts would know what
method to
call.
Erm, what about the constructor? Or the static{} part?
Regards
Leon
-
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: Eliminate Setup Actions
...And I did in fact mean you when I wrote someone :) I generally like the overall idea behind ViewController beans as you describe. If there was one problem that I see it is that the prerender() method is specific to the page the bean is associated with. This can be viewed as good or bad... The good view is a nice encapsulation of the page-related functionality. Also, as you point out, it may serve to eliminate some unnecassery work in some cases, which is nice. The bad view is that if you have essentially the same dropdown on three different pages, as I understand it, you either (a) have to duplicate that setup code in three different beans, (b) call some common class from all three prerender() methods, or (c) call prerender() of one of the beans from prerender() of the other two (assuming that's even allowed). Of those options, (b) is the only one that doesn't make me immediately unhappy. But, even that one feels a bit more heavyweight and hacky than it could. But, don't take that as a criticism of Shale in any way. I'm just thinking along the lines of how I might like to implement it in 1.x, trying to see what ideas from Shale I might like to steal and which I might like to go a different way on :) Your comment about the Tiles Controller is very interesting... If I was to do this, I would think the proper way would be that it should work regardless of whether Tiles is used or not, and in the same way in either case. Clearly if I have to use a controller when using Tiles but something else when I'm not, that's not an optimal answer, to me anyway. I could also make the same argument about the controller as I made about the Shale prerender() method too, but its two different issues I think :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Craig McClanahan wrote: On Sat, 05 Mar 2005 17:56:40 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: Then again, I know *someone* is going to point out that Shale (or I guess JSF generically?) already has this notion ingrained in it. But of course! :-) In Shale, a ViewController bean (pretty much the equivalent of ActionForm+Action) has callback methods that the framework calls for you: - init() -- called if this page is going to either process a postback or be rendered - preprocess() - called if we are about to process a postback (form submit) for the corresponding page - prerender() - called if we are about to be rendered - destroy() - called if init() was ever called To the original question about getting rid of the setup action, the Shale approach is to put that kind of setup stuff (populating dropdown list options, etc.) in the prerender() method, which will be called *only* if we are the page that is going to be rendered -- thus avoiding needless work if you navigated somewhere else instead. For Struts 1.x, the setup method or setup helper class idea seems reasonable, unless you are using Tiles. In that case, use a Tiles Controller, which is almost the same thing as the Shale prerender() method -- it is called just before that tile is rendered, and is (again) the right place for this sort of setup behavior. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
I have no interest in Shale personally. And, I don't think this idea has been bounced around in that regard. The only interest I have in this in a request driven web MVC setup, which Shale (JSF) is not. Shale is an event driven framework like Echo and Tapestry and is essentially an attempt to make web programming available to those who cannot understand what is happening: tools, in other words. This is okay by me. But, I would rather do what works well than what serves those who have limited knowledge well. That much said. I don't think Shale is related too much to this. Not sure why you were thinking that. It was originally offered in relation to Jericho. Essentially it provides a set of interfaces between the model data (database, etc.) and the view data (page, request, session, application) scopes) which is not context but function based, sort of like AOP Data to coin a combo-term. I had the StrutsState posted on the wiki. The wiki keeps such information forever, of course, so it is still there: just a bit harder to get to and really old news. On Sat, 05 Mar 2005 17:56:40 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: I for one would be interested in such a thing. I was starting to think about how to do this in a generic enough way too... I was actually thinking of doing it declaratively, i.e., for each Action mapping you could specify a list of setup methods to call, and Struts would go ahead and do that right before it called your Action's execute(). I figured you'd specify the class and method to call, although even easier would be to write an actual SetupAction class, or something along those lines, with a known interface that all these classes would have to implement, then you would just specify the class and Struts would know what method to call. But, that would probably mean only one setup method per setup class, and I'm not sure that would be optimal. I'm kind of babbling here :), but the basic idea I do like. Did you post your StrutsState proposal anywhere? I'd be interested in seeing it. I wonder if we were thinking along the same lines? Then again, I know *someone* is going to point out that Shale (or I guess JSF generically?) already has this notion ingrained in it. That might well be true, and I know neither of us are the first people to mention such an idea (I've seen mention of this before numerous times), but I for one think such a thing added to classic Struts would be very nice indeed. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Dakota Jack wrote: I think this solution is the bomb. I once suggested a generic solution like this for Struts called StrutsState. No one was much interested, so I just built it for my own work. It is so helpful that I cannot express my gratitude toward myself to myself. ///;-) On Sat, 05 Mar 2005 14:27:08 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: Someone else made some good suggestions about listeners and plugins. These will work well if the dropdown contents are truly static. If however it might be the kind of values that you want to make sure are up-to-date, i.e., read from a database maybe... Then one simple solution is create yourself a class that is basically independant from your application that is used for setup for a paricular screen or set of screens. Create a static method for the setup, then from any Action associated with a page that needs that data, just call that static method at the start of the Action. Simple, one line of code per Action and one import (or none, if it's in the same package). I would create static members of the setup class for the attribute names, and make the static setup method(s) return something like an ArrayList (or whatever type you need), so that you can call it from your Actions with something like: request.setAttribute(MySetupClass.MY_ATTRIBUTE_NAME, MySetupClass.doSetup()); That way you aren't tied to it being a webapp, should you need to do a different presentation layer later. I think this is a decent, simple approach to this type of thing. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Ben Taylor wrote: Hi, Can anyone tell me if there is an easy way to put information (required to populate drop down boxes using data from a db) in to the request, without having to write a setup Action for each page as is done here: http://www.reumann.net/struts/lesson2/step9.do . Thank you for any help! - 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: Eliminate Setup Actions
Interesting... Honestly, when I read through it at first, my reaction
was geez, that's pretty complicated for a relatively simple concept,
but upon a second reading I realized it wasn't all that complicated.
However, it seems like we already have something along these lines: the
collection of ActionMappings read in at application startup. I'm not
sure about introducing a whole new collection of objects, and management
components to go along with it.
I like the idea of the Action in a sense inherently knowing which setup
object to get. That is intriguing. But, I think it goes against one of
my stated goals, that being that it might not just be a single method in
a single class that deals with setup for a particular page. You might
in fact be dealing with a number of different object and a number of
different methods in each. If we declaratively attach an object to an
Action whos purpose is to do setup, then you might have code duplicated
in various classes (imagine a dropdown that appears on three different
screens). Sure, you could have the setup object call some object that
has that common code, but isn't that making things more complex rather
than more simple?
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Leon Rosenberg wrote:
You could use / write a common configuration framework, which would be
instantiated by the action servlet, and where all configuration objects are
stored / managed. An action would then obtain it's specific configuration
object
in constructor, or even better in execute(). Last one would allow to change
the configuration on the fly, without
restart or anything.
Actually we are using something like this but for services. It's based on
propertyfiles and a simple watcher thread, which checks all registered
files, and if they changes calls:
notifyConfigurationStarted();
setProperty(name, value) for each property in file
notifyConfigurationFinished();
it's absolutely simple, but works superb, we are using it to reconfigure
caches, switch databases switch legacy systems on and off.
Is it IoC enough for you?:-)
Regards
Leon
-Ursprüngliche Nachricht-
Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 6. März 2005 00:14
An: Struts Users Mailing List
Betreff: Re: Eliminate Setup Actions
Sure, that would work. But, then you are limiting the
developer to basically one setup per class, or forcing them
to do some work that Struts really should be doing...
If I were to add something like this to Struts (and I have
enough interest in this idea that I'd love to persue it,
assuming there is some general interest), one of the
requirements in my mind would be the ability to call any
number of setup methods per mapping.
For instance, maybe I have a page with 10 different
dropdowns. Maybe I determine that the way I want to
implement that setup is to have ten different methods in my
setup class and specify them all to execute in the mapping.
Sure, I could call all ten of them from the constructor, but
that just *feels* like a bit of a hack to me. I'd prefer a
more IoC-esque approach, and this feels like the exact
opposite. I'd want to be able to explitidly declare the ten
methods I want executed (and in the stated order of course)
rather than having to code that functionality into the setup
class itself, which is what I'd be forced to do in the
constructor (ditto for a static block).
There is a debate in my mind whether the setup class should
have to implement some given interface... It makes sense to
do so because then Struts can be sure the class is of an
appropriate type for the task.
But, to allow for multiple setup methods the interface would
have to be defined to include setupMethod1(), setupMethod2(),
setupMethod3() and so on. That's pretty obviously a bad
design. So, I imagine the interface would pretty much just
be a tag interface, and we would have to assume that if the
developer implements the interface, then whatever methods are
present in the class are meant for setup. Like I said
though, there's a bit of debate in my own head on this point
right now.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Leon Rosenberg wrote:
... I figured you'd specify
the class and method to call, although even easier would be
to write
an actual SetupAction class, or something along those lines, with a
known interface that all these classes would have to
implement, then
you would just specify the class and Struts would know what
method to
call.
Erm, what about the constructor? Or the static{} part?
Regards
Leon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
.
-
To unsubscribe, e-mail: [EMAIL PROTECTED
Re: Eliminate Setup Actions
Ben, I don't want to bother raw Struts user's mailing list, but I would like to introduce OzStruts again. because all the Struts developers are struggling with this same issue again, again and again. I think this functionality must be prepared as part of web applicaiton framework. If you have options to use other frameworks with this function, it might be better than raw Struts. But if you need or want to use Struts, please take a look at OzStruts, which is small framework on top of Struts for page driven development. This mechanism has already been built into OzStruts as prepareRequiredProperty() method. Also you can use preListener() and postListener() to do some generic task too, such as page level security, etc. OzStruts is very simple framework, you can use your Struts knowledge as it is. I hope this would help you. Tak Can anyone tell me if there is an easy way to put information (required to populate drop down boxes using data from a db) in to the request, without having to write a setup Action for each page as is done here: http://www.reumann.net/struts/lesson2/step9.do . Thank you for any help! -- Tak Yoshida mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
LOL This reminds me of the Greek guy in My Big Fat Greek Wedding who attributes all ideas to Greeks. I think your idea is cool and was cool when previously presented, but it not only is not but cannot be part of Shale because of the basic structure of that framework. I don't think that Shale or JSF has any idea of providing this sort of bridge. And, I don't think what Craig discusses here is at all the same thing. Some businesses are built on attraction and some on promotion. ///;-) Craig, of course, did not say that Shale did the same thing. He said that Shale does something different with setup Actions, which an entirely different thing; like the Greek guy in the flick. ///;-) snip On Sat, 5 Mar 2005 15:25:07 -0800, Craig McClanahan [EMAIL PROTECTED] wrote: On Sat, 05 Mar 2005 17:56:40 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: Then again, I know *someone* is going to point out that Shale (or I guess JSF generically?) already has this notion ingrained in it. But of course! :-) /snip -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
I think that this is the virtue and the vice, isn't it? JSF is page-centric. It is essentially Swing on html. If you like Swing, you might love Shale/JSF. That is not a criticism. I like Swing and think that Shale/JSP is very interesting. Nothing like Struts and a crime to call itself anything in Struts, in my not too popular opinion, but very interesting. Anyway, I think that you have pretty much got the gist of the problems inherent in this sort of framework. It is not an alternative to what you have done. Its in a different neighborhood, in my opinion. snip On Sat, 05 Mar 2005 18:42:35 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: ...And I did in fact mean you when I wrote someone :) I generally like the overall idea behind ViewController beans as you describe. If there was one problem that I see it is that the prerender() method is specific to the page the bean is associated with. This can be viewed as good or bad... The good view is a nice encapsulation of the page-related functionality. Also, as you point out, it may serve to eliminate some unnecassery work in some cases, which is nice. The bad view is that if you have essentially the same dropdown on three different pages, as I understand it, you either (a) have to duplicate that setup code in three different beans, (b) call some common class from all three prerender() methods, or (c) call prerender() of one of the beans from prerender() of the other two (assuming that's even allowed). /snip -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
I mentioned Shale because of the whole prerender() idea that Craig talked about in another reply to this thread. I didn't know enough to specifically name the ViewController and prerender() methods though, I just remembered the basic concepts :) I think that aspect of Shale (and JSF too as I recall) is similar to what we're discussing. That's why I made the reference. I too haven't been terribly excited by what I've seen of Shale, and JSF as well. I can say the same for ASP.Net incidentally. I'm not sold on the whole event-drived model yet. However, I *AM* keeping an open mind , and I do see many of the things these technolgies are trying to do as being something I might be interested in down the road, just not right now. That's why I have an interest in making Struts classic better, even folding some of the ideas from those other technologies into it. That's why this thread caught my interest in the first place. :) I'll try and find the Wiki entry. Frankly, many times I can't find what I'm looking for on that thing, but I'll take a peek. Frank Dakota Jack wrote: I have no interest in Shale personally. And, I don't think this idea has been bounced around in that regard. The only interest I have in this in a request driven web MVC setup, which Shale (JSF) is not. Shale is an event driven framework like Echo and Tapestry and is essentially an attempt to make web programming available to those who cannot understand what is happening: tools, in other words. This is okay by me. But, I would rather do what works well than what serves those who have limited knowledge well. That much said. I don't think Shale is related too much to this. Not sure why you were thinking that. It was originally offered in relation to Jericho. Essentially it provides a set of interfaces between the model data (database, etc.) and the view data (page, request, session, application) scopes) which is not context but function based, sort of like AOP Data to coin a combo-term. I had the StrutsState posted on the wiki. The wiki keeps such information forever, of course, so it is still there: just a bit harder to get to and really old news. On Sat, 05 Mar 2005 17:56:40 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: I for one would be interested in such a thing. I was starting to think about how to do this in a generic enough way too... I was actually thinking of doing it declaratively, i.e., for each Action mapping you could specify a list of setup methods to call, and Struts would go ahead and do that right before it called your Action's execute(). I figured you'd specify the class and method to call, although even easier would be to write an actual SetupAction class, or something along those lines, with a known interface that all these classes would have to implement, then you would just specify the class and Struts would know what method to call. But, that would probably mean only one setup method per setup class, and I'm not sure that would be optimal. I'm kind of babbling here :), but the basic idea I do like. Did you post your StrutsState proposal anywhere? I'd be interested in seeing it. I wonder if we were thinking along the same lines? Then again, I know *someone* is going to point out that Shale (or I guess JSF generically?) already has this notion ingrained in it. That might well be true, and I know neither of us are the first people to mention such an idea (I've seen mention of this before numerous times), but I for one think such a thing added to classic Struts would be very nice indeed. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Dakota Jack wrote: I think this solution is the bomb. I once suggested a generic solution like this for Struts called StrutsState. No one was much interested, so I just built it for my own work. It is so helpful that I cannot express my gratitude toward myself to myself. ///;-) On Sat, 05 Mar 2005 14:27:08 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: Someone else made some good suggestions about listeners and plugins. These will work well if the dropdown contents are truly static. If however it might be the kind of values that you want to make sure are up-to-date, i.e., read from a database maybe... Then one simple solution is create yourself a class that is basically independant from your application that is used for setup for a paricular screen or set of screens. Create a static method for the setup, then from any Action associated with a page that needs that data, just call that static method at the start of the Action. Simple, one line of code per Action and one import (or none, if it's in the same package). I would create static members of the setup class for the attribute names, and make the static setup method(s) return something like an ArrayList (or whatever type you need), so that you can call it from your Actions with something like:
Re: Eliminate Setup Actions
Really interesting stuff, Leon. By making data that normally is static dynamic, you also do a lot more than is immediately evident. This is very exciting stuff, in my opinion. I originally tried to do this sort of thing with hot-deploy and classloaders. I am not sure that is not a good solution even yet. However, it sure is a lot simpler the way you do it and I have been using that sort of approach in some applications as well. snip On Sun, 6 Mar 2005 00:35:33 +0100, Leon Rosenberg [EMAIL PROTECTED] wrote: You could use / write a common configuration framework, which would be instantiated by the action servlet, and where all configuration objects are stored / managed. An action would then obtain it's specific configuration object in constructor, or even better in execute(). Last one would allow to change the configuration on the fly, without restart or anything. /snip -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
On Sat, 05 Mar 2005 18:42:35 -0500, Frank W. Zammetti
[EMAIL PROTECTED] wrote:
...And I did in fact mean you when I wrote someone :)
I generally like the overall idea behind ViewController beans as you
describe. If there was one problem that I see it is that the
prerender() method is specific to the page the bean is associated with.
This can be viewed as good or bad...
The good view is a nice encapsulation of the page-related
functionality. Also, as you point out, it may serve to eliminate some
unnecassery work in some cases, which is nice.
The bad view is that if you have essentially the same dropdown on
three different pages, as I understand it, you either (a) have to
duplicate that setup code in three different beans, (b) call some common
class from all three prerender() methods, or (c) call prerender() of one
of the beans from prerender() of the other two (assuming that's even
allowed).
If the domain data is truly shared across multiple pages, you
shouldn't be setting it up in the prerender() method -- or in a setup
action in Struts 1.x -- at all. Option (d) is best in that case:
bind your dropdown list component directly to a list of options that
lives in session scope (if it is unique per user) or in application
scope (if it is common to all users).
The example app for Shale illustrates precisely this approach for
populating dropdowns, if you want to see how it looks in code.
Of those options, (b) is the only one that doesn't make me immediately
unhappy. But, even that one feels a bit more heavyweight and hacky than
it could.
That one is still too much work.
But, don't take that as a criticism of Shale in any way. I'm just
thinking along the lines of how I might like to implement it in 1.x,
trying to see what ideas from Shale I might like to steal and which I
might like to go a different way on :)
Option (d) works great in Struts 1.x too :-).
Your comment about the Tiles Controller is very interesting... If I was
to do this, I would think the proper way would be that it should work
regardless of whether Tiles is used or not, and in the same way in
either case. Clearly if I have to use a controller when using Tiles but
something else when I'm not, that's not an optimal answer, to me anyway.
I could also make the same argument about the controller as I made
about the Shale prerender() method too, but its two different issues I
think :)
Use a Tiles controller (Struts 1.x) or Shale prerender() method
(Shale) *only* for the stuff that is unique to this particular page.
For example, consider a classic master-detail scenario like show me
all the orders for the selected customer. Where do you put the logic
that actually performs the appropriate database select (or whatever,
based on the persistence technology you're using)? That's right ...
this is where it goes, because it is unique setup for *this* page or
Tile.
By the way, Shale's ViewController support recently got extended to
subviews (i.e. things which are included by jsp:include or the
equivalent, which is what Tiles does under the covers). Therefore,
you'll be able to use exactly the same techniques on either a single
tile or the entire page, without having to learn two different APIs.
Anything you can do once and cache should be done once and cached :-).
No need to execute *any* logic if you can bind to them directly.
Struts:
!-- Assume form bean has a state property on it --
html:select ... property=state
!-- Assume appScopeBean is a Java class in application scope --
!-- with a getStateNames() method that returns an array of State --
!-- names, and a getStateAbbrs() method that returns an array of --
!-- State abbreviations --
html:options ... name=appScopeBean property=stateNames
labelName=appScopeBean labelProperty=stateAbbrs/
/html:select
Shale:
!-- Assume current customer bean has a state property on it --
h:selectOneMenu ... value=#{customer.state} ...
!-- Assume appScopeBean is a Java class in application scope --
!-- with a getStatesList() property that returns an array of
SelectItem --
!-- instances, whose label and value properties are the state --
!-- name and abbreviation, respectively --
f:selectItems value=#{appScopeBean.statesList}/
/h:selectOneMenu
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
I think, for me, all of this goes the opposite direction of where my mind is going, that is, a more service-oriented approach. If you view the setup functionality as a discrete service, then it is reasonable to say that particular service might be called from multiple places. For instance, you use a master-detail example... If it is really true that the list of master items, as well as the list of detail items, is something that will only exist on that page, then great, I wouldn't argue at all :) However, to me that looses some flexibility... If we say ok, we have a service that displays a list of master items, and we have amother service that displays a list of detail items, then the question of whether this is the only page that needs those services or not becomes moot. More importantly though, when another page is inevitably introduced later that needs them, I'm all set to provide that. I'm using the term service here, but I don't mean it in the sense of SOA or Web Services specifically. I simply mean the way you view a particular component... Rather than saying component X services page X, why not say component X provides service X, and if page X uses it, great, and if page Y later needs it, no problem. That's the mentality I'm approaching this from. I'm not sure anything you have said would preclude you from doing any of this within Shale for instance, but I *do* think it's not the same perspective on it (as Jack said, Shale is page-centric, but I'm looking at things from a decidedly not page-centric perspective). If you see the example configuration I posted a few minutes ago, I think that gives a much clearer idea of how I'm approaching this. Your comment about binding the list component to some session data is interesting, but I think leads you down a path of a component-based UI design, as JSF is (from my admittedly not full understanding of it). I think this is potentially a powerful paradigm shift, but that's exactly what it is: a paradigm shift. I'm not sure everyone is ready to go there yet. I can speak for myself certainly, and I am not. I remember the days of data-bound controls in my VB work (in my former MS life :) ), and we got away from that in end end, and I think it was the right thing to do. Now we're talking about going back to that, and I'm not sure I'm onboard with it yet... Jack made the comment (I'm paraphrasing) that this is all good for the tool vendors and for developers that don't have a full understanding of what's going on. I think I would have stated it a bit more dimplomatically, but I don't think he was far off the mark :) The day any half-assed developer can put together a web application using RAD tools is a day I do NOT look forward to, for the same reason I hated all the half-assed developers I knew that chruned out VB craplets like there was no tomorrow... God forbid something goes wrong under the covers and they have to actually look at code. Come to think of it, I have a great comic strip on my office wall at work... It's a web developer fainted on the floor with a group around him. One guy says give him some air, he'll be OK... he just accidentally saw some HTML generated by his WYSIWYG editor. That sums it up for me :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Craig McClanahan wrote: On Sat, 05 Mar 2005 18:42:35 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: ...And I did in fact mean you when I wrote someone :) I generally like the overall idea behind ViewController beans as you describe. If there was one problem that I see it is that the prerender() method is specific to the page the bean is associated with. This can be viewed as good or bad... The good view is a nice encapsulation of the page-related functionality. Also, as you point out, it may serve to eliminate some unnecassery work in some cases, which is nice. The bad view is that if you have essentially the same dropdown on three different pages, as I understand it, you either (a) have to duplicate that setup code in three different beans, (b) call some common class from all three prerender() methods, or (c) call prerender() of one of the beans from prerender() of the other two (assuming that's even allowed). If the domain data is truly shared across multiple pages, you shouldn't be setting it up in the prerender() method -- or in a setup action in Struts 1.x -- at all. Option (d) is best in that case: bind your dropdown list component directly to a list of options that lives in session scope (if it is unique per user) or in application scope (if it is common to all users). The example app for Shale illustrates precisely this approach for populating dropdowns, if you want to see how it looks in code. Of those options, (b) is the only one that doesn't make me immediately unhappy. But, even that one feels a bit more heavyweight and hacky than it could. That one is still
Re: Eliminate Setup Actions
That would actually fulfill the goals I had. Would you find that difficult to manage? No, surely not :-) I we were misunderstanding each other; actually you wrote I'm not sure about introducing a whole new collection of objects, and management components to go along with it. And I just replied, that I wouldn't like it either, but ist also unnecessary with my approach. However, I think we are d'accord here, and your config file extensions wouldn't add any managing effort, so they would be ok for me. The one thing your suggestion has over this is the dynamic nature of the configuration. That would be nice indeed :) However, since Struts configuration information is frozen anyway, I'm not sure it would be a big deal. The struts configuration is frozen indeed (even I know some guys who reload it in running webapp, to take advantage of resin's class-reloading features during development), but the underlying ressources aren't. If I have to populate a drop-down or something, ok, I probably have no need to change it. I give you another example, we have 4 different payment providers, we are working with. Sometimes they have maintenance, sometime they are just buggy, however, it happens twice a month, that i need to take one of them from the page. All I do is edit the configuration for payment and one minute later it disappears. I think there are more useful examples for reloading config thinkable. This would just be added to ActionMapping, so it's a fairly simple and straight-forward change. Then just a modification of RequestProcessor and we should be all set. This is true, it would fit into the current flow, as far as I know it. init() method. This would allow them to maybe get all the data they would need at the start, instead of having to do it with each call to a setup method. So, just like Actions, they would be shared. The down-side to this is that, like Actions again, they would have to be thread-safe. People might be tempted to call init() themselves to update the data, but that would be a Bad Thing(tm). I think people shouldn't have a chance to get to the setup objects. They would be instantiated by the instantiator only, be it request processor, or what ever. If people instantiate them later, they would be context-less, already used, and do no harm (pick one:-)) What do you think of this approach? I realize it doesn't have all the benefits of your idea, but I frankly think it would be easier to potentially get some traction with as far as getting added to Struts goes simply because it's not that big a change to Struts itself, not that big an addition. But, I think it would open up a world of flexibility for people. Thoughts? :) Actually I think both approaches could be well combined too. Your idea has the benefit of actually knowing which action uses which configuration. Since the people who develop an application and people who deploy it aren't always the same, having one place to look is a manageability advantage. What I actually don't like, is having setup classes. I think it's a bit too powerful for a simple action, and it looks ugly :-) The combination could be, that there is a ConfigurableAction you can extend, which communicates with the configuration framework, so you don't need to do it yourself, which gets it's configuration name from the mappings and provides some methods which a) can be overwritten do to the not-that-trivial-stuff b) are able to do the standard stuff theirself, like instantiating something and put it in the application scope. What do you think? Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
That would actually fulfill the goals I had. Would you find that difficult to manage? No, surely not :-) I we were misunderstanding each other; actually you wrote I'm not sure about introducing a whole new collection of objects, and management components to go along with it. And I just replied, that I wouldn't like it either, but ist also unnecessary with my approach. However, I think we are d'accord here, and your config file extensions wouldn't add any managing effort, so they would be ok for me. The one thing your suggestion has over this is the dynamic nature of the configuration. That would be nice indeed :) However, since Struts configuration information is frozen anyway, I'm not sure it would be a big deal. The struts configuration is frozen indeed (even I know some guys who reload it in running webapp, to take advantage of resin's class-reloading features during development), but the underlying ressources aren't. If I have to populate a drop-down or something, ok, I probably have no need to change it. I give you another example, we have 4 different payment providers, we are working with. Sometimes they have maintenance, sometime they are just buggy, however, it happens twice a month, that i need to take one of them from the page. All I do is edit the configuration for payment and one minute later it disappears. I think there are more useful examples for reloading config thinkable. This would just be added to ActionMapping, so it's a fairly simple and straight-forward change. Then just a modification of RequestProcessor and we should be all set. This is true, it would fit into the current flow, as far as I know it. init() method. This would allow them to maybe get all the data they would need at the start, instead of having to do it with each call to a setup method. So, just like Actions, they would be shared. The down-side to this is that, like Actions again, they would have to be thread-safe. People might be tempted to call init() themselves to update the data, but that would be a Bad Thing(tm). I think people shouldn't have a chance to get to the setup objects. They would be instantiated by the instantiator only, be it request processor, or what ever. If people instantiate them later, they would be context-less, already used, and do no harm (pick one:-)) What do you think of this approach? I realize it doesn't have all the benefits of your idea, but I frankly think it would be easier to potentially get some traction with as far as getting added to Struts goes simply because it's not that big a change to Struts itself, not that big an addition. But, I think it would open up a world of flexibility for people. Thoughts? :) Actually I think both approaches could be well combined too. Your idea has the benefit of actually knowing which action uses which configuration. Since the people who develop an application and people who deploy it aren't always the same, having one place to look is a manageability advantage. What I actually don't like, is having setup classes. I think it's a bit too powerful for a simple action, and it looks ugly :-) The combination could be, that there is a ConfigurableAction you can extend, which communicates with the configuration framework, so you don't need to do it yourself, which gets it's configuration name from the mappings and provides some methods which a) can be overwritten do to the not-that-trivial-stuff b) are able to do the standard stuff theirself, like instantiating something and put it in the application scope. What do you think? Regards Leon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eliminate Setup Actions
LOL dimplomatic (???) -- This is a Freudian feast! LOL ///;-) Once you really got going with half-assed, Frank, I think I am up on you on the scale today. ///;-) I actually have a lot of sympathy for the attempt to compete with Micro$. They are clever as all get out. However, I think the best way to do it is to provide a good framework rather than go tool oriented. Obviously smarter people than me disagree. snip On Sat, 05 Mar 2005 19:57:30 -0500, Frank W. Zammetti [EMAIL PROTECTED] wrote: Jack made the comment (I'm paraphrasing) that this is all good for the tool vendors and for developers that don't have a full understanding of what's going on. I think I would have stated it a bit more dimplomatically, but I don't think he was far off the mark :) The day any half-assed developer can put together a web application using RAD tools is a day I do NOT look forward to, for the same reason I hated all the half-assed developers I knew that chruned out VB craplets like there was no tomorrow... God forbid something goes wrong under the covers and they have to actually look at code. /snip -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
