Re: DynaActionForm and the 'pull' model
Laurie Harper wrote: Nope, Dave nailed it. Re-read the requirement I described. The point is to avoid using actions to load the data and pass it to the view. If you re-read my description of what I mean by 'push' vs. 'pull' rather than simply saying the terms mean something different it might help. I think somebody mentioned this before, but I'll reiterate: you might want to think about something like Jython server pages or wrangling something Jython-esque into a custom tag body, etc. which would give you a full-on language that doesn't require compilation. If you provide reasonable hooks into your system from objects dropped in the app/session/request this might be a convenient way to support the functionality you want. That said, I'd feel like I had a safer system if things were handled via XML configs etc. rather than code, which can be risky. It depends on who your target audience is (sort of the languages for the masses vs. languages for smart people argument) and how much you trust 'em :) I was able to accomplish a LOT in a short amount of time by doing a fair amount of work in Jython and making Jython code loadable from a DB: we didn't have access to the production system, so making any quick tweaks was out of the question. Since it was the developers that were playing with the most dynamic code bits we could expose a lot of functionality without fear of somebody (purposefully or accidentally) doing the Wrong Thing. Your situation might be different, but it's an idea. I think I'll drop the topic now, before this degrades into a flame fest. Wuss!!! ;) *lol* Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
On 5/28/05, Laurie Harper [EMAIL PROTECTED] wrote: Thanks for the reference Craig; but unless I'm mis-reading you, that still leaves me with data lookup 'hard coded' in Java classes. My goal is to be able to change a page's data requirements without recompilation. If it would be OK to edit an XML configuration in concert with the page, then the Chain of Responsiblity might be useful. Each page can have a view command, which can be a chain of commands. When the data requirements of the page changes, the chain's configuration can be updated to add or subtract commands. Each command can be responsible for generating the content of a given control. The action just runs the chain and exposes the context to the page. If the chain changes, the context changes, but the Java code remains the same. Between iBATIS and Chain, we are able to make very significant changes to the content of a page, without touching the actual source code, just the XML configuration. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
This is a long thread, so it might be worth repeating that Laurie wants her (human) clients to be able to write Java code on the JSP page. She seems to call this data pulling. On 5/29/05, Ted Husted [EMAIL PROTECTED] wrote: On 5/28/05, Laurie Harper [EMAIL PROTECTED] wrote: Thanks for the reference Craig; but unless I'm mis-reading you, that still leaves me with data lookup 'hard coded' in Java classes. My goal is to be able to change a page's data requirements without recompilation. If it would be OK to edit an XML configuration in concert with the page, then the Chain of Responsiblity might be useful. Each page can have a view command, which can be a chain of commands. When the data requirements of the page changes, the chain's configuration can be updated to add or subtract commands. Each command can be responsible for generating the content of a given control. The action just runs the chain and exposes the context to the page. If the chain changes, the context changes, but the Java code remains the same. Between iBATIS and Chain, we are able to make very significant changes to the content of a page, without touching the actual source code, just the XML configuration. -Ted. - 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: DynaActionForm and the 'pull' model
I actually agree with Jack on this one. Ideally, you should architect your application into layers: +--+ | Application | +--+ | Business Objects | +--+ | DAO | +--+ | Persistence | +--+ The idea being that you can code the bottom three independent of the top one - as well as unit and system test them independently. The application-specific layer then does nothing but coordinate the conversation between the application and your business rules. In a Struts application, generally, the action classes are the place this coordination takes place. Doing things this way buys you a lot that is hard for me to convey in words. I'd strongly recommend using this approach though as it'll be far easier on you down the road. Regards, Eddie Bush - Original Message - From: Laurie Harper [EMAIL PROTECTED] To: user@struts.apache.org Sent: Sunday, May 22, 2005 7:36 PM Subject: Re: DynaActionForm and the 'pull' model There's no code in the JSPs, though you could make the argument that having the JSPs fetch the data they need, through whatever means, is putting application logic in the JSPs. And yes, this is generally not reommended. In this case it's minimal and the trade off is the flexibility it provides anyone writing or modifying the JSPs. It's the best way to provide an easily cusomizable solution without needing to provide Java source code. L. Dakota Jack wrote: You are just coding on the JSP page, which for reasons that have been discussed to death is a bad idea. If you like it, have at it. But, generally speaking this is a very bad idea. --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0521-4, 05/27/2005 Tested on: 5/28/2005 1:22:00 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
You will also find that JSTL, etc., are not really made for coding on the page and that the efficiency loss is huge. On 5/28/05, Eddie Bush [EMAIL PROTECTED] wrote: I actually agree with Jack on this one. Ideally, you should architect your application into layers: +--+ | Application | +--+ | Business Objects | +--+ | DAO | +--+ | Persistence | +--+ The idea being that you can code the bottom three independent of the top one - as well as unit and system test them independently. The application-specific layer then does nothing but coordinate the conversation between the application and your business rules. In a Struts application, generally, the action classes are the place this coordination takes place. Doing things this way buys you a lot that is hard for me to convey in words. I'd strongly recommend using this approach though as it'll be far easier on you down the road. Regards, Eddie Bush - Original Message - From: Laurie Harper [EMAIL PROTECTED] To: user@struts.apache.org Sent: Sunday, May 22, 2005 7:36 PM Subject: Re: DynaActionForm and the 'pull' model There's no code in the JSPs, though you could make the argument that having the JSPs fetch the data they need, through whatever means, is putting application logic in the JSPs. And yes, this is generally not reommended. In this case it's minimal and the trade off is the flexibility it provides anyone writing or modifying the JSPs. It's the best way to provide an easily cusomizable solution without needing to provide Java source code. L. Dakota Jack wrote: You are just coding on the JSP page, which for reasons that have been discussed to death is a bad idea. If you like it, have at it. But, generally speaking this is a very bad idea. --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0521-4, 05/27/2005 Tested on: 5/28/2005 1:22:00 PM avast! - copyright (c) 2000-2004 ALWIL Software. http://www.avast.com - 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: DynaActionForm and the 'pull' model
The View Helper pattern creates presentation *content* which requires processing of dynamic business data. The forces are that the business data assimillation requirements are nontrivial, embedding business logic in the view would promote a copy-and-paste type of reuse, you want a clean separation of labor between the software developers and the web production team, and one view is commonly used to respond to a particular business request. The solution is to have the view contain only formatting code, delegating its processing responsibilities to helper classes, implemented as Java Beans or custom tags. The helpers also store the view's intermediate data model and serve as business data adapters. In other words, these sorts of solutions have absolutely nothing to do with the View Helper pattern. They are, in fact, antithetical to that pattern. On 5/26/05, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/24/05, Laurie Harper [EMAIL PROTECTED] wrote: Nope, Dave nailed it. Re-read the requirement I described. The point is to avoid using actions to load the data and pass it to the view. If you re-read my description of what I mean by 'push' vs. 'pull' rather than simply saying the terms mean something different it might help. Laurie, (Sorry for the late response -- just getting back from vacation). You might want to take a look at how Shale approaches your pull requirement. http://wiki.apache.org/struts/StrutsShale/ Being JSF based, Shale encourages you to associate a single bean with each JSP page, where the bean can have more than one behavior (versus a Struts 1.x action where the only behavior is to process the submit). In particular, Shale supports a prerender() method that can be used to pull the data that this page knows it needs from the model -- and it sits right next to the logic (in a separate method) that processes the subsequent submit. In Struts 1.x terms, prerender() is where you'd do the things you currently do in a setup action, while the normal event handling method (called an action in JSF parlance, but it's a method instead of a class) does the follow-up updates to the model. In Struts 1.x, you see this same idea directly implemented in Tiles, via the Controller interface. It's also a dominant idea in ASP.Net, Tapestry, and Spring MVC -- and it's sorta immortalized in the J2EE design patterns lexicon as the View Helper pattern. I'd be interested to hear if this is close to what you had in mind, or if it was something else again. Craig McClanahan I think I'll drop the topic now, before this degrades into a flame fest. L. Dakota Jack wrote: I believe the point was nothing like this at all, Dave. Don't know why you thought it was. Seems like you just thought this stuff up separate to me. However, certainly I don't think that the issue whether or not you are writing a CMS is relevant to the issues discussed. I also have no idea why you went off on the XML stuff. This is simply an issue of where work on the model should be. Your discussion, so far as I can tell, is about something entirely different and I have no idea where you got these issues. If these are the issues, then you must be speaking some language with Ms. Harper that I don't know. On 5/23/05, Dave Newton [EMAIL PROTECTED] wrote: Dakota Jack wrote: Just use some framework, like Struts. Write your actions and your model to take are of this business and feed the data to the appropriate scopes and objects. I believe the point was that this isn't an option. - 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: DynaActionForm and the 'pull' model
For the most part I agree with DJ. I am a firm believer in the separation of concerns and the avoidance of business logic in the 'view'. BUT the event metaphor clouds the issue and as the thin clients become rich clients, the need to apply some business logic to enable 'richness' become the exception that proves the rule. This is probably more germane to DJ's response than to the original question. But since it is relatively rare that I agree with the majority of what DJ says...I thought I owed it to him. Michael Oliver CTO Alarius Systems LLC 6800 E. Lake Mead Blvd, #1096 Las Vegas, NV 89156 Phone:(702)643-7425 Fax:(702)974-0341 *Note new email changed from [EMAIL PROTECTED] -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Saturday, May 28, 2005 11:58 AM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: Re: DynaActionForm and the 'pull' model The View Helper pattern creates presentation *content* which requires processing of dynamic business data. The forces are that the business data assimillation requirements are nontrivial, embedding business logic in the view would promote a copy-and-paste type of reuse, you want a clean separation of labor between the software developers and the web production team, and one view is commonly used to respond to a particular business request. The solution is to have the view contain only formatting code, delegating its processing responsibilities to helper classes, implemented as Java Beans or custom tags. The helpers also store the view's intermediate data model and serve as business data adapters. In other words, these sorts of solutions have absolutely nothing to do with the View Helper pattern. They are, in fact, antithetical to that pattern. On 5/26/05, Craig McClanahan [EMAIL PROTECTED] wrote: On 5/24/05, Laurie Harper [EMAIL PROTECTED] wrote: Nope, Dave nailed it. Re-read the requirement I described. The point is to avoid using actions to load the data and pass it to the view. If you re-read my description of what I mean by 'push' vs. 'pull' rather than simply saying the terms mean something different it might help. Laurie, (Sorry for the late response -- just getting back from vacation). You might want to take a look at how Shale approaches your pull requirement. http://wiki.apache.org/struts/StrutsShale/ Being JSF based, Shale encourages you to associate a single bean with each JSP page, where the bean can have more than one behavior (versus a Struts 1.x action where the only behavior is to process the submit). In particular, Shale supports a prerender() method that can be used to pull the data that this page knows it needs from the model -- and it sits right next to the logic (in a separate method) that processes the subsequent submit. In Struts 1.x terms, prerender() is where you'd do the things you currently do in a setup action, while the normal event handling method (called an action in JSF parlance, but it's a method instead of a class) does the follow-up updates to the model. In Struts 1.x, you see this same idea directly implemented in Tiles, via the Controller interface. It's also a dominant idea in ASP.Net, Tapestry, and Spring MVC -- and it's sorta immortalized in the J2EE design patterns lexicon as the View Helper pattern. I'd be interested to hear if this is close to what you had in mind, or if it was something else again. Craig McClanahan I think I'll drop the topic now, before this degrades into a flame fest. L. Dakota Jack wrote: I believe the point was nothing like this at all, Dave. Don't know why you thought it was. Seems like you just thought this stuff up separate to me. However, certainly I don't think that the issue whether or not you are writing a CMS is relevant to the issues discussed. I also have no idea why you went off on the XML stuff. This is simply an issue of where work on the model should be. Your discussion, so far as I can tell, is about something entirely different and I have no idea where you got these issues. If these are the issues, then you must be speaking some language with Ms. Harper that I don't know. On 5/23/05, Dave Newton [EMAIL PROTECTED] wrote: Dakota Jack wrote: Just use some framework, like Struts. Write your actions and your model to take are of this business and feed the data to the appropriate scopes and objects. I believe the point was that this isn't an option. - 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
Re: DynaActionForm and the 'pull' model
Thanks for the reference Craig; but unless I'm mis-reading you, that still leaves me with data lookup 'hard coded' in Java classes. My goal is to be able to change a page's data requirements without recompilation. I'll take a look at Shale though and see if it has anything to help in that context. L. Craig McClanahan wrote: Laurie, (Sorry for the late response -- just getting back from vacation). You might want to take a look at how Shale approaches your pull requirement. http://wiki.apache.org/struts/StrutsShale/ Being JSF based, Shale encourages you to associate a single bean with each JSP page, where the bean can have more than one behavior (versus a Struts 1.x action where the only behavior is to process the submit). In particular, Shale supports a prerender() method that can be used to pull the data that this page knows it needs from the model -- and it sits right next to the logic (in a separate method) that processes the subsequent submit. In Struts 1.x terms, prerender() is where you'd do the things you currently do in a setup action, while the normal event handling method (called an action in JSF parlance, but it's a method instead of a class) does the follow-up updates to the model. In Struts 1.x, you see this same idea directly implemented in Tiles, via the Controller interface. It's also a dominant idea in ASP.Net, Tapestry, and Spring MVC -- and it's sorta immortalized in the J2EE design patterns lexicon as the View Helper pattern. I'd be interested to hear if this is close to what you had in mind, or if it was something else again. Craig McClanahan I think I'll drop the topic now, before this degrades into a flame fest. L. Dakota Jack wrote: I believe the point was nothing like this at all, Dave. Don't know why you thought it was. Seems like you just thought this stuff up separate to me. However, certainly I don't think that the issue whether or not you are writing a CMS is relevant to the issues discussed. I also have no idea why you went off on the XML stuff. This is simply an issue of where work on the model should be. Your discussion, so far as I can tell, is about something entirely different and I have no idea where you got these issues. If these are the issues, then you must be speaking some language with Ms. Harper that I don't know. On 5/23/05, Dave Newton [EMAIL PROTECTED] wrote: Dakota Jack wrote: Just use some framework, like Struts. Write your actions and your model to take are of this business and feed the data to the appropriate scopes and objects. I believe the point was that this isn't an option. - 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: DynaActionForm and the 'pull' model
On 5/24/05, Laurie Harper [EMAIL PROTECTED] wrote: Nope, Dave nailed it. Re-read the requirement I described. The point is to avoid using actions to load the data and pass it to the view. If you re-read my description of what I mean by 'push' vs. 'pull' rather than simply saying the terms mean something different it might help. Laurie, (Sorry for the late response -- just getting back from vacation). You might want to take a look at how Shale approaches your pull requirement. http://wiki.apache.org/struts/StrutsShale/ Being JSF based, Shale encourages you to associate a single bean with each JSP page, where the bean can have more than one behavior (versus a Struts 1.x action where the only behavior is to process the submit). In particular, Shale supports a prerender() method that can be used to pull the data that this page knows it needs from the model -- and it sits right next to the logic (in a separate method) that processes the subsequent submit. In Struts 1.x terms, prerender() is where you'd do the things you currently do in a setup action, while the normal event handling method (called an action in JSF parlance, but it's a method instead of a class) does the follow-up updates to the model. In Struts 1.x, you see this same idea directly implemented in Tiles, via the Controller interface. It's also a dominant idea in ASP.Net, Tapestry, and Spring MVC -- and it's sorta immortalized in the J2EE design patterns lexicon as the View Helper pattern. I'd be interested to hear if this is close to what you had in mind, or if it was something else again. Craig McClanahan I think I'll drop the topic now, before this degrades into a flame fest. L. Dakota Jack wrote: I believe the point was nothing like this at all, Dave. Don't know why you thought it was. Seems like you just thought this stuff up separate to me. However, certainly I don't think that the issue whether or not you are writing a CMS is relevant to the issues discussed. I also have no idea why you went off on the XML stuff. This is simply an issue of where work on the model should be. Your discussion, so far as I can tell, is about something entirely different and I have no idea where you got these issues. If these are the issues, then you must be speaking some language with Ms. Harper that I don't know. On 5/23/05, Dave Newton [EMAIL PROTECTED] wrote: Dakota Jack wrote: Just use some framework, like Struts. Write your actions and your model to take are of this business and feed the data to the appropriate scopes and objects. I believe the point was that this isn't an option. - 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: DynaActionForm and the 'pull' model
Dakota Jack wrote: [...] and am not interested in Dave's little flame bit. You were interested enough to assume that what I said was flame bait and respond passive-aggresively, when really all I said was that it was obvious that we weren't talking about the same thing. Now for a _better_ example of flame bait check out your original response to my post where you went on at length about how I had no idea what the issue was and that I must have been conversing with Laurie in a different language. *sigh* Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
Dakota Jack wrote: If these are the issues, then you must be speaking some language with Ms. Harper that I don't know. Of that I have little doubt. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
That's an interesting approach, though I think a much more complicated solution than I need. My objective isn't to allow clients to script actions or otherwise modify their behaviour, but to make that unnecessary. This approach would certainly allow one to provide much more power if that were needed though. L. Frank W. Zammetti wrote: Rather than pollute the view (if one chooses to perceive it that way... I'm staying away from that debate!), why not introduce some sort of scripting engine into the mix? I'm not really sure precisely where because I don't know your project, but I say this based on your comment: True, at development time. But it's a lot easier if you don't *have* the source code to the model or rest of the system. Think of something like Microsoft Excel... you don't have access to the source code obviously, but it exposes are rather rich object model that you can manipulate through scripting. This lets you customize the app in essence in just about any way you want without needing the source. It also is arguably better architecturally than allowing someone to alter the dialog resources of the app (not a perfect analogy I realize, but hopefully close enough to get the point across). There is the scripted Actions project specifically for Struts, there's Jelly that might be applicable, the BSF, etc. Something along those lines is almost tailor-made for the the client needs to modify our product in some way situation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
Michael Jouravlev wrote: You do realize, that JSP _is_ a part of app source code, do you? And Err, well, yes... ;-) the more you put into JSP, the more this supposedly dumb JSP page will look like real code? If you ship without source code, you'd rather precompile the JSPs. That would make the task of customizing the application somewhat harder! :-) The point is that the customer can edit the JSPs but I don't want them to have to edit and recompile action classes in order to achieve the customizations they need. So yes, they get some 'source code' (the JSPs) but not the rest. I should also perhaps clarify that I do use the normal action proceessing model for handling inputs; the pull model is used mainly for simple view operations. The problem at hand is how to translate between the view objects used for exposing data to the JSP and the form beans used when submitting it for update. The view object can't be used for storing form inputs if validation fails, since they are typed data structures. Hence, on first load, the page obtains a view to display; on subsequent re-loads due to validation failing, it needs to use the form bean instead of the view object. Once the form is submitted successfully, I handle transfering the content of the form bean into the view and, from there, to the domain model all server-side. No problem there. L. Now, to your problem. I will try to think right while I am typing. First of all, I haven't actually used dynaforms, so no advices here. Now, you want your input to go to action form? Why? Apparently, because you want Struts to parse request data, and to perform automatic validation. OK. So you need to associate form bean with every incoming request, but you do not want to redefine form beans, hence dynaform. Struts uses getters and setters to put values into the form (at least if it is not a dynamic form), so you can use getters and setters to direct where the data goes... I am not sure how do you do this with dynabean, but with regular bean you would have your getter pulling data from your view object, and the setter storing data in the form field. Then, after validation, you would type-convert and copy values from form fields to your view object. Or... you can still pull data from your view object and display values using bean:write. But the tags themselves will have property pointing to the form bean. I am not sure how this will work, but if you were able to print values from view object, and submit them to the form bean, then you'd just copy them to view object, and _then_ validate them. Then, if needed, you would redisplay data again from the view object, which contains updated data (possibly incorrect, but who cares, this view object is a _copy_ of a real object anyway, right?). In this case you do not need getters in the form bean. Because there are no getters, this pull from view object, submit to action form might work. I have not really tried it. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
It doesn't help to say 'your terms do not have the meaning you've defined them to have for purposes of this discuession' and conclude that the following arguments are invalide. Re-read the requirement I stated below. Your concluding comments do not in any way address it. L. Dakota Jack wrote: On 5/23/05, Laurie Harper [EMAIL PROTECTED] wrote: Dakota Jack wrote: You cannot talk about request objects and ignore the client. The requests come from the client. Sure, but I'm not talking about request objects. A request to http://host/myapp/something.jsp (with no query parameters) contains no request data, but the JSP still has to display information. What I'm taling about is how that information is retrieved from the backend. A string containing a protocol (http) a URL (host) and a number of other identification matters (myapp, something.jsp) whether having query parameters or not is not a request. All sorts of data goes with a request on all occasions which enable the communications in for example, http to take place. Absolutely, which is why it's important when using pull to keep it simple and make sure data retrieval is as declarative as possible. I'm certainly not advocating that JSPs should be making JDBC calls or anything. I repeat, again, you are not using the terms pull, or push, or request the way they are used. Your use is idiosyncratic. There is not hing declarative about your approach either. This is not what declarative means in this context. As I said in my previous post, you need to understand the design constraints. No approach solves every solution, no design rule is inviolate. I'm using a pull model to solve a very specific requirement: that the data displayed on a JSP page should be able to be changed /from the JSP page/, without access to the application source code. This is not, again, a pull/push issue. Pull and push are relationships between client and server. Your relationship is between the view and the model. This also is not related to design constraints or design rules. This is just coding on the JSP page and is really not a good idea. It is such a bad idea that whole technologies are invented to avoid it. If you are running a mom and pop show, this is not important. In that case, not much would be important. But, in the craft of programming, which admittedly is not rocket science, it is important. I can see why it looks, at first glance, like I'm doing something badly wrong but, in the light of that requirement, I'm not aware of another approach that's workable. Feel free to suggest alternatives if you have them :-) Just use some framework, like Struts. Write your actions and your model to take are of this business and feed the data to the appropriate scopes and objects. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
Nope, Dave nailed it. Re-read the requirement I described. The point is to avoid using actions to load the data and pass it to the view. If you re-read my description of what I mean by 'push' vs. 'pull' rather than simply saying the terms mean something different it might help. I think I'll drop the topic now, before this degrades into a flame fest. L. Dakota Jack wrote: I believe the point was nothing like this at all, Dave. Don't know why you thought it was. Seems like you just thought this stuff up separate to me. However, certainly I don't think that the issue whether or not you are writing a CMS is relevant to the issues discussed. I also have no idea why you went off on the XML stuff. This is simply an issue of where work on the model should be. Your discussion, so far as I can tell, is about something entirely different and I have no idea where you got these issues. If these are the issues, then you must be speaking some language with Ms. Harper that I don't know. On 5/23/05, Dave Newton [EMAIL PROTECTED] wrote: Dakota Jack wrote: Just use some framework, like Struts. Write your actions and your model to take are of this business and feed the data to the appropriate scopes and objects. I believe the point was that this isn't an option. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
Sorry, Laurie, but if you are going to define your own meanings for request and so on, then I just don't have time to learn how you are speaking, even if what you said was enticing. I am not saying you are wrong, just that I would prefer to use terms in a standard way to avoid having to learn idiosyncratic usage. The bottom line, however, is that I am not open at this stage in my career to suggestions that putting code into JSP pages is a good idea without a bang up and clear argument for that option. I don't see it here. On 5/24/05, Laurie Harper [EMAIL PROTECTED] wrote: Sure, but I'm not talking about request objects. A request to http://host/myapp/something.jsp (with no query parameters) contains no request data, but the JSP still has to display information. What I'm taling about is how that information is retrieved from the backend. -- 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: DynaActionForm and the 'pull' model
Okay, Laurie. I did miss that you were somehow setting it up so that clients could actually modify your JSP pages directly. That surprises me and I missed it. Good for Dave, he caught that. I still don't see where you said that, but if that is the project, then I certainly have no more to say and am not interested in Dave's little flame bit. Sorry for missing your point. On 5/24/05, Laurie Harper [EMAIL PROTECTED] wrote: Nope, Dave nailed it. Re-read the requirement I described. The point is to avoid using actions to load the data and pass it to the view. If you re-read my description of what I mean by 'push' vs. 'pull' rather than simply saying the terms mean something different it might help. I think I'll drop the topic now, before this degrades into a flame fest. L. Dakota Jack wrote: I believe the point was nothing like this at all, Dave. Don't know why you thought it was. Seems like you just thought this stuff up separate to me. However, certainly I don't think that the issue whether or not you are writing a CMS is relevant to the issues discussed. I also have no idea why you went off on the XML stuff. This is simply an issue of where work on the model should be. Your discussion, so far as I can tell, is about something entirely different and I have no idea where you got these issues. If these are the issues, then you must be speaking some language with Ms. Harper that I don't know. On 5/23/05, Dave Newton [EMAIL PROTECTED] wrote: Dakota Jack wrote: Just use some framework, like Struts. Write your actions and your model to take are of this business and feed the data to the appropriate scopes and objects. I believe the point was that this isn't an option. - 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: DynaActionForm and the 'pull' model
If you want to discuss this, I have a number of things to say. If you
find that argumentative, then I won't offer anything more. Having
JSPs fetch data indeed is putting application logic in the JSPs.
This does not give you flexibility. Quite the opposite, it ties your
model and you view down by coupling them. Rather than give you
flexibility it hamstrings you.
This also is no easier than writing the code where it should be, in the model.
On 5/22/05, Laurie Harper [EMAIL PROTECTED] wrote:
There's no code in the JSPs, though you could make the argument that
having the JSPs fetch the data they need, through whatever means, is
putting application logic in the JSPs. And yes, this is generally not
reommended. In this case it's minimal and the trade off is the
flexibility it provides anyone writing or modifying the JSPs. It's the
best way to provide an easily cusomizable solution without needing to
provide Java source code.
L.
Dakota Jack wrote:
You are just coding on the JSP page, which for reasons that have been
discussed to death is a bad idea. If you like it, have at it. But,
generally speaking this is a very bad idea.
On 5/19/05, Laurie Harper [EMAIL PROTECTED] wrote:
Adam Hardy wrote:
Laurie,
my chosen option would be to use your view objects as form objects,
where you modify the view object by adding string-typed getters and
setters for every property.
I'm not really keen to 'pollute' the view objects with String-type
derived properties just for the HTML presentation; the view objects are
how any client (web app, web service, Swing GUI, etc) would interact
with the application. This also implies having String-to-model
conversion code scattered through the view objects...
I don't really get what you mean in your (2).
This is what I decided to try first. I threw together a prototype last
night, and it seams to work well. Basically, the idea is:
- extend the view API to include 'View.toMap(Map props)' and 'void
View.fromMap(Map props)' on each view class
- you can then do view.fromMap(form.getMap()) and
view.toMap(form.getMap()) to translate between views and form beans
- add a custom tag which takes a form bean and a view and loads the
form's map from the view (I've implemented this so it can lookup the
form bean from an enclosing html:form/ tag, so you only have to pass
in the view)
Now, my JSPs can do something like this:
jsp:useBean id=view class=MyViewBean/
... setup view (e.g. populate from db) ...
x:loadForm view=${view}/
Now, the form bean associated with the enclosing form is populated from
the view object. On subsequent page loads, I can skip the loadForm tag,
and the form bean has the data from the previous submission.
I still need to do some more testing, but this seems to be working nicely.
I think the parameter handling issue is hugely debatable. I've lost
count of the number of discussions I have had about it.
Yeah, lots of options here :-)
Alot depends on where you get your view objects from. Are they the data
transfer object pattern?
Roughly, yes. There's a 'service layer' that interacts with the domain
model (business objects). It returns view objects which are POJOs
containing the state from the business objects but not the behaviour.
Whatever, try to keep it as simple as possible.
Always good advice! The trick is remembering who to keep it simple for,
me or the end user ;-)
L.
Adam
On 18/05/05 20:45nbsp;Laurie Harper wrote:
[Appologies for the long post; hopefully it'll spark some interesting
discussion though.]
Does anybody develop with Struts using a 'pull' model (where JSPs 'pull'
in the data they need, rather than having it 'pushed' to them by a
calling action)? I've been doing this successfully for some time with
applications that only use forms for capturing new data, no editting of
existing data. Now that I come to add the ability to update existing
data to an application, I've hit a limitation in my design. I'm hoping
others have encountered the same issue, or have suggestions for dealing
with it.
Here's the problem: I generally have a JSP for capturing new data, which
will use a DynaActionForm to manage the form inputs through multiple
edit-validate cycles until the form data is accepted and committed to
the database. For display of existing data, a different JSP is used
which 'pulls' the data in (using a custom tag or by instantiating a
bean). This JSP is fronted by a simple ActionForward. The page renders
the data as pulled from the database. For the sake of simplicity, assume
this 'pull' step puts a POJO bean into some scope (request usually);
call this the view object.
Now, if I want to be able to edit that data, the form needs to render
the data from the view object the first time it loads, but from the
ActionForm instance on subsequent loads (after validation fails). The
submit action, when it succeeds, then
Re: DynaActionForm and the 'pull' model
You cannot talk about request objects and ignore the client. The requests come from the client. Any data coming to a JSP comes in the same way. This is not pull and this is not push. The data comes from some class existing in some scope: page, request, session, application. You are not doing anything new. You are just doing the old stuff badly, I believe. I only say that to be helpful as I can be and not to belittle you or anything like that. Your cases has the JSP more than requesting the data. Your case has the JSP in charge of getting the data. That is very different. Any data coming to a JSP must be requested, i.e. gotten from some call from the JSP page. Your pages does more, viz. instantiates the objects, etc. which provide the data on the JSP page. Again, your idea that way is flexible is not true. You are less able to customize with your approach because you have all sorts of disparate code tied to each other. If you have a variable on a JSP page be a logical reference to data, then the physical source of that data becomes irrelevant. You, however, make direct references rather than logical references and tie down your code completely. The coupling is the problem. Coupling leads to fragile, rigid, code which is expensive to maintain. I hope this is helpful, and realize that I am just stating my opinion. I don't think you are at all right, but certainly am willing to listen to what you have to say. On 5/22/05, Laurie Harper [EMAIL PROTECTED] wrote: You're bluring the distinction between client-side behaviour and server-side behaviour a little there. Ignore the client side for the moment; I'm talking only about how the application works on the server. The issue is about how the JSP gets access to the data it needs to display. Normally, as you say, there would be an action or some other server-side component which executes before the JSP and places data into some scope which the JSP then retrieves. That's what I'm refering to as a 'push' model, in that there is some component pushing data out to the JSP. In my case, I want the JSP to get access to the data by explicitly requesting it -- i.e. 'pulling in' the data it needs. As I noted in my other reply to you, this could be seen as breaking the MVC paradigm by putting application logic in the JSP. There's some truth in that. The reason I do it is quite simple. By having the JSPs aquire the data they need in this way, it is much easier to customize the application after it is delivered. Page flow can be changed, additional information can be shown on an existing page, and so, all without modifying Java code. That means I can deliver a highly customizable product. It's a trade-off: I bend MVC encapsulation, but gain a significant benefit. So, 'pull', in the context of this discussion, just refers to how the JSP gets acces to the data it needs. In my implementation, the JSPs instantiate beans which represent a view of the data they need. The beans then do the work of interacting with the backend (via a service layer). So the data access is really still in the controller part of the application, it's just being triggered by the JSPs rather than by a Struts action. In a way, you can think of it as using the JSPs to declaratively describe what data they will use rather than having to have an action or other component know in advance. L. Dakota Jack wrote: A few thoughts: (1) The push/pull dichotomy really does not apply to what you are talking about. That relationship is between the client and the server and has more to do with the nature of the protocol, viz. HTTP, being employed in a browser context. (2) Likewise, some of the other things you say seem to not track the semantics of the actual problem space. For example, JSPs never capture data but are used to create dynamic HTML in the response. The data always comes from the request object which only indirectly is related to the prior JSP page and the form elements available on that page. We could always put together a request object without any JSP at all and scoot it off to the server. Hackers, of course, do just that. (3) A JSP page fronted by a simple ActionForward cannot be populated unless you have something put the populating bean in some scope. Presumably that activity has to somehow be explained. Why you do not what to use an ActionForm or this is not clear. I do many things, of course, without the ActionForm participating, but the Action or the ActionForm must be doing something. A simple ActionForward cannot give you a bean with the data you need. Something is wrong with this description. I would guess that you have some Action put the bean into scope. This has nothing to do with pull as that term is normally used in the push/pull discussions outside Dr. Dolittle's push-pull llama. (4) When you say there is no custom action to populate the bean but that it is
Re: DynaActionForm and the 'pull' model
Dakota Jack wrote: You cannot talk about request objects and ignore the client. The requests come from the client. Sure, but I'm not talking about request objects. A request to http://host/myapp/something.jsp (with no query parameters) contains no request data, but the JSP still has to display information. What I'm taling about is how that information is retrieved from the backend. Any data coming to a JSP comes in the same way. This is not pull and this is not push. The data comes from some class existing in some scope: page, request, session, application. You are not doing anything new. You are just doing the old stuff badly, I believe. I only say that to be helpful as I can be and not to belittle you or anything like that. Your cases has the JSP more than requesting the data. Your case has the JSP in charge of getting the data. That is very different. Any data coming to a JSP must be requested, i.e. gotten from some call from the JSP page. Your pages does more, viz. instantiates the objects, etc. which provide the data on the JSP page. Again, your idea that way is flexible is not true. You are less able to customize with your approach because you have all sorts of disparate code tied to each other. If you have a variable on a JSP page be a logical reference to data, then the physical source of that data becomes irrelevant. You, however, make direct references rather than logical references and tie down your code completely. JSPs access data through page/request/session scoped variables, just like yours do. With a push methodology, a JSP may assume that there will be a request scoped variable 'user' which references a bean of type UserView. It renders the page by making reference to the properties of this bean through the 'user' variable. The only difference with a pull methodology is that, somewhere in the JSP, there is a jsp:useBean class=UserView/. The rest of the JSP is written exactly as it would have been using a pull methodology. There's no 'disparate code' and the references to data are no more or less direct than when using push. The coupling is the problem. Coupling leads to fragile, rigid, code which is expensive to maintain. Absolutely, which is why it's important when using pull to keep it simple and make sure data retrieval is as declarative as possible. I'm certainly not advocating that JSPs should be making JDBC calls or anything. I hope this is helpful, and realize that I am just stating my opinion. I don't think you are at all right, but certainly am willing to listen to what you have to say. As I said in my previous post, you need to understand the design constraints. No approach solves every solution, no design rule is inviolate. I'm using a pull model to solve a very specific requirement: that the data displayed on a JSP page should be able to be changed /from the JSP page/, without access to the application source code. I can see why it looks, at first glance, like I'm doing something badly wrong but, in the light of that requirement, I'm not aware of another approach that's workable. Feel free to suggest alternatives if you have them :-) L. On 5/22/05, Laurie Harper [EMAIL PROTECTED] wrote: You're bluring the distinction between client-side behaviour and server-side behaviour a little there. Ignore the client side for the moment; I'm talking only about how the application works on the server. The issue is about how the JSP gets access to the data it needs to display. Normally, as you say, there would be an action or some other server-side component which executes before the JSP and places data into some scope which the JSP then retrieves. That's what I'm refering to as a 'push' model, in that there is some component pushing data out to the JSP. In my case, I want the JSP to get access to the data by explicitly requesting it -- i.e. 'pulling in' the data it needs. As I noted in my other reply to you, this could be seen as breaking the MVC paradigm by putting application logic in the JSP. There's some truth in that. The reason I do it is quite simple. By having the JSPs aquire the data they need in this way, it is much easier to customize the application after it is delivered. Page flow can be changed, additional information can be shown on an existing page, and so, all without modifying Java code. That means I can deliver a highly customizable product. It's a trade-off: I bend MVC encapsulation, but gain a significant benefit. So, 'pull', in the context of this discussion, just refers to how the JSP gets acces to the data it needs. In my implementation, the JSPs instantiate beans which represent a view of the data they need. The beans then do the work of interacting with the backend (via a service layer). So the data access is really still in the controller part of the application, it's just being triggered by the JSPs rather than by a Struts action. In a way, you can think of it as using the JSPs to
Re: DynaActionForm and the 'pull' model
Dakota Jack wrote:
If you want to discuss this, I have a number of things to say. If you
So I see on your other reply ;-)
find that argumentative, then I won't offer anything more. Having
No, I'm happy to discuss; it's always worth hearing another person's
perspective.
JSPs fetch data indeed is putting application logic in the JSPs.
This does not give you flexibility. Quite the opposite, it ties your
model and you view down by coupling them. Rather than give you
flexibility it hamstrings you.
That's somewhat true from a development perspective; there's a design
constraint in effect here that you're missing, though (see below).
This also is no easier than writing the code where it should be, in the model.
True, at development time. But it's a lot easier if you don't *have* the
source code to the model or rest of the system. Consider a comercial
product implemented on Struts and JSPs. You build the product and ship
it to customers. You don't ship the source code -- that's proprietary --
but you do ship the JSPs and you want the customers to be able to
locally customize the application.
This is where the pull approach provides a great deal of flexibility.
There are a lot of things you might want your customers to be able to do
by way of customization that are simply not possible using a push
methodology.
L.
On 5/22/05, Laurie Harper [EMAIL PROTECTED] wrote:
There's no code in the JSPs, though you could make the argument that
having the JSPs fetch the data they need, through whatever means, is
putting application logic in the JSPs. And yes, this is generally not
reommended. In this case it's minimal and the trade off is the
flexibility it provides anyone writing or modifying the JSPs. It's the
best way to provide an easily cusomizable solution without needing to
provide Java source code.
L.
Dakota Jack wrote:
You are just coding on the JSP page, which for reasons that have been
discussed to death is a bad idea. If you like it, have at it. But,
generally speaking this is a very bad idea.
On 5/19/05, Laurie Harper [EMAIL PROTECTED] wrote:
Adam Hardy wrote:
Laurie,
my chosen option would be to use your view objects as form objects,
where you modify the view object by adding string-typed getters and
setters for every property.
I'm not really keen to 'pollute' the view objects with String-type
derived properties just for the HTML presentation; the view objects are
how any client (web app, web service, Swing GUI, etc) would interact
with the application. This also implies having String-to-model
conversion code scattered through the view objects...
I don't really get what you mean in your (2).
This is what I decided to try first. I threw together a prototype last
night, and it seams to work well. Basically, the idea is:
- extend the view API to include 'View.toMap(Map props)' and 'void
View.fromMap(Map props)' on each view class
- you can then do view.fromMap(form.getMap()) and
view.toMap(form.getMap()) to translate between views and form beans
- add a custom tag which takes a form bean and a view and loads the
form's map from the view (I've implemented this so it can lookup the
form bean from an enclosing html:form/ tag, so you only have to pass
in the view)
Now, my JSPs can do something like this:
jsp:useBean id=view class=MyViewBean/
... setup view (e.g. populate from db) ...
x:loadForm view=${view}/
Now, the form bean associated with the enclosing form is populated from
the view object. On subsequent page loads, I can skip the loadForm tag,
and the form bean has the data from the previous submission.
I still need to do some more testing, but this seems to be working nicely.
I think the parameter handling issue is hugely debatable. I've lost
count of the number of discussions I have had about it.
Yeah, lots of options here :-)
Alot depends on where you get your view objects from. Are they the data
transfer object pattern?
Roughly, yes. There's a 'service layer' that interacts with the domain
model (business objects). It returns view objects which are POJOs
containing the state from the business objects but not the behaviour.
Whatever, try to keep it as simple as possible.
Always good advice! The trick is remembering who to keep it simple for,
me or the end user ;-)
L.
Adam
On 18/05/05 20:45nbsp;Laurie Harper wrote:
[Appologies for the long post; hopefully it'll spark some interesting
discussion though.]
Does anybody develop with Struts using a 'pull' model (where JSPs 'pull'
in the data they need, rather than having it 'pushed' to them by a
calling action)? I've been doing this successfully for some time with
applications that only use forms for capturing new data, no editting of
existing data. Now that I come to add the ability to update existing
data to an application, I've hit a limitation in my design. I'm hoping
others have encountered the same issue, or have suggestions for dealing
with it.
Here's the
Re: DynaActionForm and the 'pull' model
Rather than pollute the view (if one chooses to perceive it that way...
I'm staying away from that debate!), why not introduce some sort of
scripting engine into the mix? I'm not really sure precisely where
because I don't know your project, but I say this based on your comment:
True, at development time. But it's a lot easier if you don't *have* the
source code to the model or rest of the system.
Think of something like Microsoft Excel... you don't have access to the
source code obviously, but it exposes are rather rich object model that
you can manipulate through scripting. This lets you customize the app in
essence in just about any way you want without needing the source. It
also is arguably better architecturally than allowing someone to alter the
dialog resources of the app (not a perfect analogy I realize, but
hopefully close enough to get the point across).
There is the scripted Actions project specifically for Struts, there's
Jelly that might be applicable, the BSF, etc.
Something along those lines is almost tailor-made for the the client
needs to modify our product in some way situation.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Mon, May 23, 2005 2:20 pm, Laurie Harper said:
Dakota Jack wrote:
If you want to discuss this, I have a number of things to say. If you
So I see on your other reply ;-)
find that argumentative, then I won't offer anything more. Having
No, I'm happy to discuss; it's always worth hearing another person's
perspective.
JSPs fetch data indeed is putting application logic in the JSPs.
This does not give you flexibility. Quite the opposite, it ties your
model and you view down by coupling them. Rather than give you
flexibility it hamstrings you.
That's somewhat true from a development perspective; there's a design
constraint in effect here that you're missing, though (see below).
This also is no easier than writing the code where it should be, in the
model.
True, at development time. But it's a lot easier if you don't *have* the
source code to the model or rest of the system. Consider a comercial
product implemented on Struts and JSPs. You build the product and ship
it to customers. You don't ship the source code -- that's proprietary --
but you do ship the JSPs and you want the customers to be able to
locally customize the application.
This is where the pull approach provides a great deal of flexibility.
There are a lot of things you might want your customers to be able to do
by way of customization that are simply not possible using a push
methodology.
L.
On 5/22/05, Laurie Harper [EMAIL PROTECTED] wrote:
There's no code in the JSPs, though you could make the argument that
having the JSPs fetch the data they need, through whatever means, is
putting application logic in the JSPs. And yes, this is generally not
reommended. In this case it's minimal and the trade off is the
flexibility it provides anyone writing or modifying the JSPs. It's the
best way to provide an easily cusomizable solution without needing to
provide Java source code.
L.
Dakota Jack wrote:
You are just coding on the JSP page, which for reasons that have been
discussed to death is a bad idea. If you like it, have at it. But,
generally speaking this is a very bad idea.
On 5/19/05, Laurie Harper [EMAIL PROTECTED] wrote:
Adam Hardy wrote:
Laurie,
my chosen option would be to use your view objects as form objects,
where you modify the view object by adding string-typed getters and
setters for every property.
I'm not really keen to 'pollute' the view objects with String-type
derived properties just for the HTML presentation; the view objects
are
how any client (web app, web service, Swing GUI, etc) would interact
with the application. This also implies having String-to-model
conversion code scattered through the view objects...
I don't really get what you mean in your (2).
This is what I decided to try first. I threw together a prototype last
night, and it seams to work well. Basically, the idea is:
- extend the view API to include 'View.toMap(Map props)' and 'void
View.fromMap(Map props)' on each view class
- you can then do view.fromMap(form.getMap()) and
view.toMap(form.getMap()) to translate between views and form beans
- add a custom tag which takes a form bean and a view and loads the
form's map from the view (I've implemented this so it can lookup the
form bean from an enclosing html:form/ tag, so you only have to pass
in the view)
Now, my JSPs can do something like this:
jsp:useBean id=view class=MyViewBean/
... setup view (e.g. populate from db) ...
x:loadForm view=${view}/
Now, the form bean associated with the enclosing form is populated
from
the view object. On subsequent page loads, I can skip the loadForm
tag,
and the form bean has the data from the previous submission.
I still need to do some more testing, but this seems to be working
nicely.
I think the
Re: DynaActionForm and the 'pull' model
On 5/23/05, Laurie Harper [EMAIL PROTECTED] wrote: Dakota Jack wrote: You cannot talk about request objects and ignore the client. The requests come from the client. Sure, but I'm not talking about request objects. A request to http://host/myapp/something.jsp (with no query parameters) contains no request data, but the JSP still has to display information. What I'm taling about is how that information is retrieved from the backend. A string containing a protocol (http) a URL (host) and a number of other identification matters (myapp, something.jsp) whether having query parameters or not is not a request. All sorts of data goes with a request on all occasions which enable the communications in for example, http to take place. Absolutely, which is why it's important when using pull to keep it simple and make sure data retrieval is as declarative as possible. I'm certainly not advocating that JSPs should be making JDBC calls or anything. I repeat, again, you are not using the terms pull, or push, or request the way they are used. Your use is idiosyncratic. There is not hing declarative about your approach either. This is not what declarative means in this context. As I said in my previous post, you need to understand the design constraints. No approach solves every solution, no design rule is inviolate. I'm using a pull model to solve a very specific requirement: that the data displayed on a JSP page should be able to be changed /from the JSP page/, without access to the application source code. This is not, again, a pull/push issue. Pull and push are relationships between client and server. Your relationship is between the view and the model. This also is not related to design constraints or design rules. This is just coding on the JSP page and is really not a good idea. It is such a bad idea that whole technologies are invented to avoid it. If you are running a mom and pop show, this is not important. In that case, not much would be important. But, in the craft of programming, which admittedly is not rocket science, it is important. I can see why it looks, at first glance, like I'm doing something badly wrong but, in the light of that requirement, I'm not aware of another approach that's workable. Feel free to suggest alternatives if you have them :-) Just use some framework, like Struts. Write your actions and your model to take are of this business and feed the data to the appropriate scopes and objects. -- 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: DynaActionForm and the 'pull' model
Dakota Jack wrote: Just use some framework, like Struts. Write your actions and your model to take are of this business and feed the data to the appropriate scopes and objects. I believe the point was that this isn't an option. It seems to me, in this case, that the client wants more control over the application, but for various reasons won't be writing Actions, etc. Therefore another way in to the system needs to be provided, whatever vernacular anybody wants to use. To me it looks like a place where a different delivery mechanism, like XML, and subsequent transformation might be more appropriate: more service-oriented rather than page-oriented. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
JSPs fetch data indeed is putting application logic in the JSPs. This does not give you flexibility. Quite the opposite, it ties your model and you view down by coupling them. Rather than give you flexibility it hamstrings you. So what? These two will always be related unless you use simple meaningless DTOs with no relation to business objects. I personally do not use this type of DTO, I prefer to use real business objects in the view. I don't care that it ties view to the model. But at least I get readable, understandable code and I get business rules. Oh, right, I use business objects for input too, in this example they are used solely for output... But Laurie said, that it is not a real business object, it is just a view object, so view is actually not tied that tight to the model. Consider a comercial product implemented on Struts and JSPs. You build the product and ship it to customers. You don't ship the source code -- that's proprietary -- but you do ship the JSPs and you want the customers to be able to locally customize the application. You do realize, that JSP _is_ a part of app source code, do you? And the more you put into JSP, the more this supposedly dumb JSP page will look like real code? If you ship without source code, you'd rather precompile the JSPs. Now, to your problem. I will try to think right while I am typing. First of all, I haven't actually used dynaforms, so no advices here. Now, you want your input to go to action form? Why? Apparently, because you want Struts to parse request data, and to perform automatic validation. OK. So you need to associate form bean with every incoming request, but you do not want to redefine form beans, hence dynaform. Struts uses getters and setters to put values into the form (at least if it is not a dynamic form), so you can use getters and setters to direct where the data goes... I am not sure how do you do this with dynabean, but with regular bean you would have your getter pulling data from your view object, and the setter storing data in the form field. Then, after validation, you would type-convert and copy values from form fields to your view object. Or... you can still pull data from your view object and display values using bean:write. But the tags themselves will have property pointing to the form bean. I am not sure how this will work, but if you were able to print values from view object, and submit them to the form bean, then you'd just copy them to view object, and _then_ validate them. Then, if needed, you would redisplay data again from the view object, which contains updated data (possibly incorrect, but who cares, this view object is a _copy_ of a real object anyway, right?). In this case you do not need getters in the form bean. Because there are no getters, this pull from view object, submit to action form might work. I have not really tried it. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
Normally, Camilo, when you have a question you start your own thread. On 5/23/05, Camilo Quevedo [EMAIL PROTECTED] wrote: Hi, I'm trying to create a struts application, but it seams that when i ask for a user input (html:form) it doesn't,t recognize the special characters. How can I configure my application so that it accepts special character?? So far I've done this: i my jsp I put %@ page contentType=text/html;charset=UTF-8 language=java % and in my action I used, request.setCharacterEncoding(UTF-8); and it still doesn't work. What can I do?? Camilo - 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: DynaActionForm and the 'pull' model
I believe the point was nothing like this at all, Dave. Don't know why you thought it was. Seems like you just thought this stuff up separate to me. However, certainly I don't think that the issue whether or not you are writing a CMS is relevant to the issues discussed. I also have no idea why you went off on the XML stuff. This is simply an issue of where work on the model should be. Your discussion, so far as I can tell, is about something entirely different and I have no idea where you got these issues. If these are the issues, then you must be speaking some language with Ms. Harper that I don't know. On 5/23/05, Dave Newton [EMAIL PROTECTED] wrote: Dakota Jack wrote: Just use some framework, like Struts. Write your actions and your model to take are of this business and feed the data to the appropriate scopes and objects. I believe the point was that this isn't an option. -- 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: DynaActionForm and the 'pull' model
Okay, Michael. If this is what you like, good luck. I am stopping the conversation from my side if it is staying at this level. On 5/23/05, Michael Jouravlev [EMAIL PROTECTED] wrote: JSPs fetch data indeed is putting application logic in the JSPs. This does not give you flexibility. Quite the opposite, it ties your model and you view down by coupling them. Rather than give you flexibility it hamstrings you. So what? These two will always be related unless you use simple meaningless DTOs with no relation to business objects. I personally do not use this type of DTO, I prefer to use real business objects in the view. I don't care that it ties view to the model. But at least I get readable, understandable code and I get business rules. Oh, right, I use business objects for input too, in this example they are used solely for output... But Laurie said, that it is not a real business object, it is just a view object, so view is actually not tied that tight to the model. Consider a comercial product implemented on Struts and JSPs. You build the product and ship it to customers. You don't ship the source code -- that's proprietary -- but you do ship the JSPs and you want the customers to be able to locally customize the application. You do realize, that JSP _is_ a part of app source code, do you? And the more you put into JSP, the more this supposedly dumb JSP page will look like real code? If you ship without source code, you'd rather precompile the JSPs. Now, to your problem. I will try to think right while I am typing. First of all, I haven't actually used dynaforms, so no advices here. Now, you want your input to go to action form? Why? Apparently, because you want Struts to parse request data, and to perform automatic validation. OK. So you need to associate form bean with every incoming request, but you do not want to redefine form beans, hence dynaform. Struts uses getters and setters to put values into the form (at least if it is not a dynamic form), so you can use getters and setters to direct where the data goes... I am not sure how do you do this with dynabean, but with regular bean you would have your getter pulling data from your view object, and the setter storing data in the form field. Then, after validation, you would type-convert and copy values from form fields to your view object. Or... you can still pull data from your view object and display values using bean:write. But the tags themselves will have property pointing to the form bean. I am not sure how this will work, but if you were able to print values from view object, and submit them to the form bean, then you'd just copy them to view object, and _then_ validate them. Then, if needed, you would redisplay data again from the view object, which contains updated data (possibly incorrect, but who cares, this view object is a _copy_ of a real object anyway, right?). In this case you do not need getters in the form bean. Because there are no getters, this pull from view object, submit to action form might work. I have not really tried it. Michael. - 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: DynaActionForm and the 'pull' model
A few thoughts: (1) The push/pull dichotomy really does not apply to what you are talking about. That relationship is between the client and the server and has more to do with the nature of the protocol, viz. HTTP, being employed in a browser context. (2) Likewise, some of the other things you say seem to not track the semantics of the actual problem space. For example, JSPs never capture data but are used to create dynamic HTML in the response. The data always comes from the request object which only indirectly is related to the prior JSP page and the form elements available on that page. We could always put together a request object without any JSP at all and scoot it off to the server. Hackers, of course, do just that. (3) A JSP page fronted by a simple ActionForward cannot be populated unless you have something put the populating bean in some scope. Presumably that activity has to somehow be explained. Why you do not what to use an ActionForm or this is not clear. I do many things, of course, without the ActionForm participating, but the Action or the ActionForm must be doing something. A simple ActionForward cannot give you a bean with the data you need. Something is wrong with this description. I would guess that you have some Action put the bean into scope. This has nothing to do with pull as that term is normally used in the push/pull discussions outside Dr. Dolittle's push-pull llama. (4) When you say there is no custom action to populate the bean but that it is pulled from the page, I can only think that you mean you have the code that should be in the model on the JSP page. If so, this is not pull and is not a good idea. Is that right? If not, then I don't know where the so-called pull data is coming from. -- 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: DynaActionForm and the 'pull' model
You are just coding on the JSP page, which for reasons that have been
discussed to death is a bad idea. If you like it, have at it. But,
generally speaking this is a very bad idea.
On 5/19/05, Laurie Harper [EMAIL PROTECTED] wrote:
Adam Hardy wrote:
Laurie,
my chosen option would be to use your view objects as form objects,
where you modify the view object by adding string-typed getters and
setters for every property.
I'm not really keen to 'pollute' the view objects with String-type
derived properties just for the HTML presentation; the view objects are
how any client (web app, web service, Swing GUI, etc) would interact
with the application. This also implies having String-to-model
conversion code scattered through the view objects...
I don't really get what you mean in your (2).
This is what I decided to try first. I threw together a prototype last
night, and it seams to work well. Basically, the idea is:
- extend the view API to include 'View.toMap(Map props)' and 'void
View.fromMap(Map props)' on each view class
- you can then do view.fromMap(form.getMap()) and
view.toMap(form.getMap()) to translate between views and form beans
- add a custom tag which takes a form bean and a view and loads the
form's map from the view (I've implemented this so it can lookup the
form bean from an enclosing html:form/ tag, so you only have to pass
in the view)
Now, my JSPs can do something like this:
jsp:useBean id=view class=MyViewBean/
... setup view (e.g. populate from db) ...
x:loadForm view=${view}/
Now, the form bean associated with the enclosing form is populated from
the view object. On subsequent page loads, I can skip the loadForm tag,
and the form bean has the data from the previous submission.
I still need to do some more testing, but this seems to be working nicely.
I think the parameter handling issue is hugely debatable. I've lost
count of the number of discussions I have had about it.
Yeah, lots of options here :-)
Alot depends on where you get your view objects from. Are they the data
transfer object pattern?
Roughly, yes. There's a 'service layer' that interacts with the domain
model (business objects). It returns view objects which are POJOs
containing the state from the business objects but not the behaviour.
Whatever, try to keep it as simple as possible.
Always good advice! The trick is remembering who to keep it simple for,
me or the end user ;-)
L.
Adam
On 18/05/05 20:45nbsp;Laurie Harper wrote:
[Appologies for the long post; hopefully it'll spark some interesting
discussion though.]
Does anybody develop with Struts using a 'pull' model (where JSPs 'pull'
in the data they need, rather than having it 'pushed' to them by a
calling action)? I've been doing this successfully for some time with
applications that only use forms for capturing new data, no editting of
existing data. Now that I come to add the ability to update existing
data to an application, I've hit a limitation in my design. I'm hoping
others have encountered the same issue, or have suggestions for dealing
with it.
Here's the problem: I generally have a JSP for capturing new data, which
will use a DynaActionForm to manage the form inputs through multiple
edit-validate cycles until the form data is accepted and committed to
the database. For display of existing data, a different JSP is used
which 'pulls' the data in (using a custom tag or by instantiating a
bean). This JSP is fronted by a simple ActionForward. The page renders
the data as pulled from the database. For the sake of simplicity, assume
this 'pull' step puts a POJO bean into some scope (request usually);
call this the view object.
Now, if I want to be able to edit that data, the form needs to render
the data from the view object the first time it loads, but from the
ActionForm instance on subsequent loads (after validation fails). The
submit action, when it succeeds, then rebuilds the view object from the
form data and submits it to the service/domain layer via a 'store'
operation.
Note that there is no custom action to populate the form bean; form data
is pulled by the JSP page for editting just as for display. The reason
for this is that it should be possible to build new forms/pages without
modifying Java code. That's a basic requirement for this application.
So, the question is, how do I (a) populate the form bean from the JSP
and (b) determine when to do so? Some options I've considered:
1) write a custom tag that looks up the form bean and view object in the
appropriate scope and uses BeanUtils.describe() or some other method to
fill out the form bean; this would probably require the view objects to
expose a describe() method returning a Map since view objects represent
structured data (a view object may have properties that are themselves
view objects)
2) write a 'form
Re: DynaActionForm and the 'pull' model
There's no code in the JSPs, though you could make the argument that
having the JSPs fetch the data they need, through whatever means, is
putting application logic in the JSPs. And yes, this is generally not
reommended. In this case it's minimal and the trade off is the
flexibility it provides anyone writing or modifying the JSPs. It's the
best way to provide an easily cusomizable solution without needing to
provide Java source code.
L.
Dakota Jack wrote:
You are just coding on the JSP page, which for reasons that have been
discussed to death is a bad idea. If you like it, have at it. But,
generally speaking this is a very bad idea.
On 5/19/05, Laurie Harper [EMAIL PROTECTED] wrote:
Adam Hardy wrote:
Laurie,
my chosen option would be to use your view objects as form objects,
where you modify the view object by adding string-typed getters and
setters for every property.
I'm not really keen to 'pollute' the view objects with String-type
derived properties just for the HTML presentation; the view objects are
how any client (web app, web service, Swing GUI, etc) would interact
with the application. This also implies having String-to-model
conversion code scattered through the view objects...
I don't really get what you mean in your (2).
This is what I decided to try first. I threw together a prototype last
night, and it seams to work well. Basically, the idea is:
- extend the view API to include 'View.toMap(Map props)' and 'void
View.fromMap(Map props)' on each view class
- you can then do view.fromMap(form.getMap()) and
view.toMap(form.getMap()) to translate between views and form beans
- add a custom tag which takes a form bean and a view and loads the
form's map from the view (I've implemented this so it can lookup the
form bean from an enclosing html:form/ tag, so you only have to pass
in the view)
Now, my JSPs can do something like this:
jsp:useBean id=view class=MyViewBean/
... setup view (e.g. populate from db) ...
x:loadForm view=${view}/
Now, the form bean associated with the enclosing form is populated from
the view object. On subsequent page loads, I can skip the loadForm tag,
and the form bean has the data from the previous submission.
I still need to do some more testing, but this seems to be working nicely.
I think the parameter handling issue is hugely debatable. I've lost
count of the number of discussions I have had about it.
Yeah, lots of options here :-)
Alot depends on where you get your view objects from. Are they the data
transfer object pattern?
Roughly, yes. There's a 'service layer' that interacts with the domain
model (business objects). It returns view objects which are POJOs
containing the state from the business objects but not the behaviour.
Whatever, try to keep it as simple as possible.
Always good advice! The trick is remembering who to keep it simple for,
me or the end user ;-)
L.
Adam
On 18/05/05 20:45nbsp;Laurie Harper wrote:
[Appologies for the long post; hopefully it'll spark some interesting
discussion though.]
Does anybody develop with Struts using a 'pull' model (where JSPs 'pull'
in the data they need, rather than having it 'pushed' to them by a
calling action)? I've been doing this successfully for some time with
applications that only use forms for capturing new data, no editting of
existing data. Now that I come to add the ability to update existing
data to an application, I've hit a limitation in my design. I'm hoping
others have encountered the same issue, or have suggestions for dealing
with it.
Here's the problem: I generally have a JSP for capturing new data, which
will use a DynaActionForm to manage the form inputs through multiple
edit-validate cycles until the form data is accepted and committed to
the database. For display of existing data, a different JSP is used
which 'pulls' the data in (using a custom tag or by instantiating a
bean). This JSP is fronted by a simple ActionForward. The page renders
the data as pulled from the database. For the sake of simplicity, assume
this 'pull' step puts a POJO bean into some scope (request usually);
call this the view object.
Now, if I want to be able to edit that data, the form needs to render
the data from the view object the first time it loads, but from the
ActionForm instance on subsequent loads (after validation fails). The
submit action, when it succeeds, then rebuilds the view object from the
form data and submits it to the service/domain layer via a 'store'
operation.
Note that there is no custom action to populate the form bean; form data
is pulled by the JSP page for editting just as for display. The reason
for this is that it should be possible to build new forms/pages without
modifying Java code. That's a basic requirement for this application.
So, the question is, how do I (a) populate the form bean from the JSP
and (b) determine when to do so? Some options I've considered:
1) write a custom tag that looks up the form bean and view object in
Re: DynaActionForm and the 'pull' model
You're bluring the distinction between client-side behaviour and server-side behaviour a little there. Ignore the client side for the moment; I'm talking only about how the application works on the server. The issue is about how the JSP gets access to the data it needs to display. Normally, as you say, there would be an action or some other server-side component which executes before the JSP and places data into some scope which the JSP then retrieves. That's what I'm refering to as a 'push' model, in that there is some component pushing data out to the JSP. In my case, I want the JSP to get access to the data by explicitly requesting it -- i.e. 'pulling in' the data it needs. As I noted in my other reply to you, this could be seen as breaking the MVC paradigm by putting application logic in the JSP. There's some truth in that. The reason I do it is quite simple. By having the JSPs aquire the data they need in this way, it is much easier to customize the application after it is delivered. Page flow can be changed, additional information can be shown on an existing page, and so, all without modifying Java code. That means I can deliver a highly customizable product. It's a trade-off: I bend MVC encapsulation, but gain a significant benefit. So, 'pull', in the context of this discussion, just refers to how the JSP gets acces to the data it needs. In my implementation, the JSPs instantiate beans which represent a view of the data they need. The beans then do the work of interacting with the backend (via a service layer). So the data access is really still in the controller part of the application, it's just being triggered by the JSPs rather than by a Struts action. In a way, you can think of it as using the JSPs to declaratively describe what data they will use rather than having to have an action or other component know in advance. L. Dakota Jack wrote: A few thoughts: (1) The push/pull dichotomy really does not apply to what you are talking about. That relationship is between the client and the server and has more to do with the nature of the protocol, viz. HTTP, being employed in a browser context. (2) Likewise, some of the other things you say seem to not track the semantics of the actual problem space. For example, JSPs never capture data but are used to create dynamic HTML in the response. The data always comes from the request object which only indirectly is related to the prior JSP page and the form elements available on that page. We could always put together a request object without any JSP at all and scoot it off to the server. Hackers, of course, do just that. (3) A JSP page fronted by a simple ActionForward cannot be populated unless you have something put the populating bean in some scope. Presumably that activity has to somehow be explained. Why you do not what to use an ActionForm or this is not clear. I do many things, of course, without the ActionForm participating, but the Action or the ActionForm must be doing something. A simple ActionForward cannot give you a bean with the data you need. Something is wrong with this description. I would guess that you have some Action put the bean into scope. This has nothing to do with pull as that term is normally used in the push/pull discussions outside Dr. Dolittle's push-pull llama. (4) When you say there is no custom action to populate the bean but that it is pulled from the page, I can only think that you mean you have the code that should be in the model on the JSP page. If so, this is not pull and is not a good idea. Is that right? If not, then I don't know where the so-called pull data is coming from. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
On 19/05/05 21:29nbsp;Laurie Harper wrote: my chosen option would be to use your view objects as form objects, where you modify the view object by adding string-typed getters and setters for every property. I'm not really keen to 'pollute' the view objects with String-type derived properties just for the HTML presentation; the view objects are how any client (web app, web service, Swing GUI, etc) would interact with the application. This also implies having String-to-model conversion code scattered through the view objects... OK, valid point, but you then go on to say that you have a method on your view object to provide all the string-typed properties in a map to your form bean or get them from your form bean. I think what you are doing is mixing and matching the struts-paradigm (front servlet pattern) with what JSF wants to do. Which is actually a good idea because (a) I thinks struts needs something more and (b) I don't like the JSF point-and-click .NET wanna-be approach. By the way this isn't my only reply - I wanted to split the subject - I am posting again with questions about your design. From a design perspective, there's something niggling me about your view objects. The view whether it is a GUI or HTTP is basically a framework or layer that should provide an API for stuff like string-to-type conversion. So I agree you should not pollute the view objects with such code. It's just semantics I guess - they're not really 'view objects' - they're DTOs. I guess you put the data together from various data object in the back end, right? What I am aiming for is a DynaActionForm that I can configure in xml but including type info. There would also be a validation mechanism - do you want a validation error if the type cast fails? etc. form-bean name=libraryForm type=org.apache.struts.validator.AdamsDynaValidatorForm form-property name=sectionId type=java.lang.String cast=java.lang.Integer validate=true / /form-bean You could populate it with BeanUtils or with your toMap() method. I guess this is only one step removed from what you've got anyway. It's just encapsulated within the formbean and view layer framework. Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
On 19/05/05 21:29nbsp;Laurie Harper wrote:
This is what I decided to try first. I threw together a prototype last
night, and it seams to work well. Basically, the idea is:
- extend the view API to include 'View.toMap(Map props)' and 'void
View.fromMap(Map props)' on each view class
- you can then do view.fromMap(form.getMap()) and
view.toMap(form.getMap()) to translate between views and form beans
- add a custom tag which takes a form bean and a view and loads the
form's map from the view (I've implemented this so it can lookup the
form bean from an enclosing html:form/ tag, so you only have to pass
in the view)
Now, my JSPs can do something like this:
jsp:useBean id=view class=MyViewBean/
... setup view (e.g. populate from db) ...
x:loadForm view=${view}/
Now, the form bean associated with the enclosing form is populated from
the view object. On subsequent page loads, I can skip the loadForm tag,
and the form bean has the data from the previous submission.
You skip the whole tag? Using JSTL or something in the JSP? How do you
tell? Can you do that inside the loadForm tag to keep the JSP cleaner?
Surely though you need some items of data just for display (which wont
be resubmitted with the form because you didn't put them in form fields)
and you can also use the view object to check whether you need to save
(if nothing changed)?
BTW how does your viewbean behave? Does it call the back end when it is
instantiated, or just when it decides it needs the data?
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
Adam Hardy wrote: I'm not really keen to 'pollute' the view objects with String-type derived properties just for the HTML presentation; the view objects are how any client (web app, web service, Swing GUI, etc) would interact with the application. This also implies having String-to-model conversion code scattered through the view objects... OK, valid point, but you then go on to say that you have a method on your view object to provide all the string-typed properties in a map to your form bean or get them from your form bean. I think what you are doing is mixing and matching the struts-paradigm (front servlet pattern) with what JSF wants to do. Which is actually a good idea because (a) I thinks struts needs something more and (b) I don't like the JSF point-and-click .NET wanna-be approach. That's exactly right; the traditional Struts paradigm is 'push', where there are actions which feed data into the request before the JSP is called. What I'm working with is 'pull' where the JSPs aquire the data they need themselves. Struts becomes the mediator for page flow and operations which modify state on the server. Pure view operations have minimal dependance on Struts. By the way this isn't my only reply - I wanted to split the subject - I am posting again with questions about your design. From a design perspective, there's something niggling me about your view objects. The view whether it is a GUI or HTTP is basically a framework or layer that should provide an API for stuff like string-to-type conversion. So I agree you should not pollute the view objects with such code. It's just semantics I guess - they're not really 'view objects' - they're DTOs. I guess you put the data together from various data object in the back end, right? That's right, yes. The methods for translating to/from Maps of Strings is a convenience for the presentation layer on top. The advantage of making the view objects / DTOs responsible for this is it reduces coupling. The presentation layer can be less intimately entwined with the view layer ;-) What I am aiming for is a DynaActionForm that I can configure in xml but including type info. There would also be a validation mechanism - do you want a validation error if the type cast fails? etc. form-bean name=libraryForm type=org.apache.struts.validator.AdamsDynaValidatorForm form-property name=sectionId type=java.lang.String cast=java.lang.Integer validate=true / /form-bean You could populate it with BeanUtils or with your toMap() method. I guess this is only one step removed from what you've got anyway. It's just encapsulated within the formbean and view layer framework. Yeah, that would be a good abstraction. But it does mean that the view / DTO objects and the Struts configuration have to be kept closely in sync. I think some sort of typed form bean would be a good general solution, though; I suspect a lot of people would find this approach appealing -- I'd probably have adopted it in my case if it had existed already! L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
Adam Hardy wrote:
On 19/05/05 21:29nbsp;Laurie Harper wrote:
This is what I decided to try first. I threw together a prototype last
night, and it seams to work well. Basically, the idea is:
- extend the view API to include 'View.toMap(Map props)' and 'void
View.fromMap(Map props)' on each view class
- you can then do view.fromMap(form.getMap()) and
view.toMap(form.getMap()) to translate between views and form beans
- add a custom tag which takes a form bean and a view and loads the
form's map from the view (I've implemented this so it can lookup the
form bean from an enclosing html:form/ tag, so you only have to pass
in the view)
Now, my JSPs can do something like this:
jsp:useBean id=view class=MyViewBean/
... setup view (e.g. populate from db) ...
x:loadForm view=${view}/
Now, the form bean associated with the enclosing form is populated
from the view object. On subsequent page loads, I can skip the
loadForm tag, and the form bean has the data from the previous
submission.
You skip the whole tag? Using JSTL or something in the JSP? How do you
tell? Can you do that inside the loadForm tag to keep the JSP cleaner?
I haven't settled on a mechanism for deciding yet; I'm leaning towards
just having a query parameter reload=true or something, then using
notPresent to wrap the loadForm tag.
Surely though you need some items of data just for display (which wont
be resubmitted with the form because you didn't put them in form fields)
and you can also use the view object to check whether you need to save
(if nothing changed)?
Yes, quite likely, and using the pull model I can always get the data I
need at the point where I need it. All this is just a mechanism on top
of that to enable form data to be round-tripped cleanly.
BTW how does your viewbean behave? Does it call the back end when it is
instantiated, or just when it decides it needs the data?
I have a service layer which implements the business transactions the
system supports. It's responsible for using a DAO to load domain data
and transfer it into view objects. So basically, the view objects / DTOs
are the data encapsulation mechanism for interacting with the service
layer.
From the presentation layer's perspective, the view objects are how it
invokes data retrival operations on the service layer. So in my JSP I
say 'use bean User, set view to loginId' and the bean takes care of
calling the UserService.lookupUser(userId) method and populating itself.
Or something like that, the design is still emerging as I prototype :)
L.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
Adam Hardy wrote: I'm not really keen to 'pollute' the view objects with String-type derived properties just for the HTML presentation; the view objects are how any client (web app, web service, Swing GUI, etc) would interact with the application. This also implies having String-to-model conversion code scattered through the view objects... OK, valid point, but you then go on to say that you have a method on your view object to provide all the string-typed properties in a map to your form bean or get them from your form bean. I think what you are doing is mixing and matching the struts-paradigm (front servlet pattern) with what JSF wants to do. Which is actually a good idea because (a) I thinks struts needs something more and (b) I don't like the JSF point-and-click .NET wanna-be approach. That's exactly right; the traditional Struts paradigm is 'push', where there are actions which feed data into the request before the JSP is called. What I'm working with is 'pull' where the JSPs aquire the data they need themselves. Struts becomes the mediator for page flow and operations which modify state on the server. Pure view operations have minimal dependance on Struts. By the way this isn't my only reply - I wanted to split the subject - I am posting again with questions about your design. From a design perspective, there's something niggling me about your view objects. The view whether it is a GUI or HTTP is basically a framework or layer that should provide an API for stuff like string-to-type conversion. So I agree you should not pollute the view objects with such code. It's just semantics I guess - they're not really 'view objects' - they're DTOs. I guess you put the data together from various data object in the back end, right? That's right, yes. The methods for translating to/from Maps of Strings is a convenience for the presentation layer on top. The advantage of making the view objects / DTOs responsible for this is it reduces coupling. The presentation layer can be less intimately entwined with the view layer ;-) What I am aiming for is a DynaActionForm that I can configure in xml but including type info. There would also be a validation mechanism - do you want a validation error if the type cast fails? etc. form-bean name=libraryForm type=org.apache.struts.validator.AdamsDynaValidatorForm form-property name=sectionId type=java.lang.String cast=java.lang.Integer validate=true / /form-bean You could populate it with BeanUtils or with your toMap() method. I guess this is only one step removed from what you've got anyway. It's just encapsulated within the formbean and view layer framework. Yeah, that would be a good abstraction. But it does mean that the view / DTO objects and the Struts configuration have to be kept closely in sync. I think some sort of typed form bean would be a good general solution, though; I suspect a lot of people would find this approach appealing -- I'd probably have adopted it in my case if it had existed already! L. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
Adam Hardy wrote:
Laurie,
my chosen option would be to use your view objects as form objects,
where you modify the view object by adding string-typed getters and
setters for every property.
I'm not really keen to 'pollute' the view objects with String-type
derived properties just for the HTML presentation; the view objects are
how any client (web app, web service, Swing GUI, etc) would interact
with the application. This also implies having String-to-model
conversion code scattered through the view objects...
I don't really get what you mean in your (2).
This is what I decided to try first. I threw together a prototype last
night, and it seams to work well. Basically, the idea is:
- extend the view API to include 'View.toMap(Map props)' and 'void
View.fromMap(Map props)' on each view class
- you can then do view.fromMap(form.getMap()) and
view.toMap(form.getMap()) to translate between views and form beans
- add a custom tag which takes a form bean and a view and loads the
form's map from the view (I've implemented this so it can lookup the
form bean from an enclosing html:form/ tag, so you only have to pass
in the view)
Now, my JSPs can do something like this:
jsp:useBean id=view class=MyViewBean/
... setup view (e.g. populate from db) ...
x:loadForm view=${view}/
Now, the form bean associated with the enclosing form is populated from
the view object. On subsequent page loads, I can skip the loadForm tag,
and the form bean has the data from the previous submission.
I still need to do some more testing, but this seems to be working nicely.
I think the parameter handling issue is hugely debatable. I've lost
count of the number of discussions I have had about it.
Yeah, lots of options here :-)
Alot depends on where you get your view objects from. Are they the data
transfer object pattern?
Roughly, yes. There's a 'service layer' that interacts with the domain
model (business objects). It returns view objects which are POJOs
containing the state from the business objects but not the behaviour.
Whatever, try to keep it as simple as possible.
Always good advice! The trick is remembering who to keep it simple for,
me or the end user ;-)
L.
Adam
On 18/05/05 20:45nbsp;Laurie Harper wrote:
[Appologies for the long post; hopefully it'll spark some interesting
discussion though.]
Does anybody develop with Struts using a 'pull' model (where JSPs 'pull'
in the data they need, rather than having it 'pushed' to them by a
calling action)? I've been doing this successfully for some time with
applications that only use forms for capturing new data, no editting of
existing data. Now that I come to add the ability to update existing
data to an application, I've hit a limitation in my design. I'm hoping
others have encountered the same issue, or have suggestions for dealing
with it.
Here's the problem: I generally have a JSP for capturing new data, which
will use a DynaActionForm to manage the form inputs through multiple
edit-validate cycles until the form data is accepted and committed to
the database. For display of existing data, a different JSP is used
which 'pulls' the data in (using a custom tag or by instantiating a
bean). This JSP is fronted by a simple ActionForward. The page renders
the data as pulled from the database. For the sake of simplicity, assume
this 'pull' step puts a POJO bean into some scope (request usually);
call this the view object.
Now, if I want to be able to edit that data, the form needs to render
the data from the view object the first time it loads, but from the
ActionForm instance on subsequent loads (after validation fails). The
submit action, when it succeeds, then rebuilds the view object from the
form data and submits it to the service/domain layer via a 'store'
operation.
Note that there is no custom action to populate the form bean; form data
is pulled by the JSP page for editting just as for display. The reason
for this is that it should be possible to build new forms/pages without
modifying Java code. That's a basic requirement for this application.
So, the question is, how do I (a) populate the form bean from the JSP
and (b) determine when to do so? Some options I've considered:
1) write a custom tag that looks up the form bean and view object in the
appropriate scope and uses BeanUtils.describe() or some other method to
fill out the form bean; this would probably require the view objects to
expose a describe() method returning a Map since view objects represent
structured data (a view object may have properties that are themselves
view objects)
2) write a 'form manager' bean JSPs can use to say 'populate this form
bean with data from this view object'. The form bean manager then does
the work that is usually done in actions in the traditional 'push'
model. To avoid excessive coupling, a describe() method on the view
objects would be a good idea (otherwise the manager class would have to
know the view - form bean mapping rules for every view object and form
DynaActionForm and the 'pull' model
[Appologies for the long post; hopefully it'll spark some interesting
discussion though.]
Does anybody develop with Struts using a 'pull' model (where JSPs 'pull'
in the data they need, rather than having it 'pushed' to them by a
calling action)? I've been doing this successfully for some time with
applications that only use forms for capturing new data, no editting of
existing data. Now that I come to add the ability to update existing
data to an application, I've hit a limitation in my design. I'm hoping
others have encountered the same issue, or have suggestions for dealing
with it.
Here's the problem: I generally have a JSP for capturing new data, which
will use a DynaActionForm to manage the form inputs through multiple
edit-validate cycles until the form data is accepted and committed to
the database. For display of existing data, a different JSP is used
which 'pulls' the data in (using a custom tag or by instantiating a
bean). This JSP is fronted by a simple ActionForward. The page renders
the data as pulled from the database. For the sake of simplicity, assume
this 'pull' step puts a POJO bean into some scope (request usually);
call this the view object.
Now, if I want to be able to edit that data, the form needs to render
the data from the view object the first time it loads, but from the
ActionForm instance on subsequent loads (after validation fails). The
submit action, when it succeeds, then rebuilds the view object from the
form data and submits it to the service/domain layer via a 'store'
operation.
Note that there is no custom action to populate the form bean; form data
is pulled by the JSP page for editting just as for display. The reason
for this is that it should be possible to build new forms/pages without
modifying Java code. That's a basic requirement for this application.
So, the question is, how do I (a) populate the form bean from the JSP
and (b) determine when to do so? Some options I've considered:
1) write a custom tag that looks up the form bean and view object in the
appropriate scope and uses BeanUtils.describe() or some other method to
fill out the form bean; this would probably require the view objects to
expose a describe() method returning a Map since view objects represent
structured data (a view object may have properties that are themselves
view objects)
2) write a 'form manager' bean JSPs can use to say 'populate this form
bean with data from this view object'. The form bean manager then does
the work that is usually done in actions in the traditional 'push'
model. To avoid excessive coupling, a describe() method on the view
objects would be a good idea (otherwise the manager class would have to
know the view - form bean mapping rules for every view object and form
in the system).
3) always render the form using the view object and have the submit
action update the view object with the form data before validating. This
wont work since view objects have typed properties and I wouldn't be
able to 'round trip' invalid inputs (the same reason form beans usually
only use String properties).
4) seperate create, edit and view operations into different JSPs. Appart
from the duplication of markup that introduces, it only helps for the
create (always use the form bean) and view (always use the view object)
cases; edit is still 'broken'.
I'm leaning toward the form manager (option 2) so a JSP might look like:
jsp:useBean var=view class=.../
jsp:useBean var=mgr class=...FormManager/
jsp:setProperty name=mgr property=form value=${the form bean}/
jsp:setProperty name=mgr property=view value=${view}/
The form manager would take an instance of DynaActionForm and update its
map of properties from the view. (I'm assuming the form bean is mutable
in this way!) I'd still need to know when to invoke the form manager I
suppose, but that's easier to solve with a request parameter or other
'state' tracker.
Anyone got any better approaches?
L.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DynaActionForm and the 'pull' model
Laurie,
my chosen option would be to use your view objects as form objects,
where you modify the view object by adding string-typed getters and
setters for every property. I don't really get what you mean in your (2).
I think the parameter handling issue is hugely debatable. I've lost
count of the number of discussions I have had about it.
Alot depends on where you get your view objects from. Are they the data
transfer object pattern?
Whatever, try to keep it as simple as possible.
Adam
On 18/05/05 20:45nbsp;Laurie Harper wrote:
[Appologies for the long post; hopefully it'll spark some interesting
discussion though.]
Does anybody develop with Struts using a 'pull' model (where JSPs 'pull'
in the data they need, rather than having it 'pushed' to them by a
calling action)? I've been doing this successfully for some time with
applications that only use forms for capturing new data, no editting of
existing data. Now that I come to add the ability to update existing
data to an application, I've hit a limitation in my design. I'm hoping
others have encountered the same issue, or have suggestions for dealing
with it.
Here's the problem: I generally have a JSP for capturing new data, which
will use a DynaActionForm to manage the form inputs through multiple
edit-validate cycles until the form data is accepted and committed to
the database. For display of existing data, a different JSP is used
which 'pulls' the data in (using a custom tag or by instantiating a
bean). This JSP is fronted by a simple ActionForward. The page renders
the data as pulled from the database. For the sake of simplicity, assume
this 'pull' step puts a POJO bean into some scope (request usually);
call this the view object.
Now, if I want to be able to edit that data, the form needs to render
the data from the view object the first time it loads, but from the
ActionForm instance on subsequent loads (after validation fails). The
submit action, when it succeeds, then rebuilds the view object from the
form data and submits it to the service/domain layer via a 'store'
operation.
Note that there is no custom action to populate the form bean; form data
is pulled by the JSP page for editting just as for display. The reason
for this is that it should be possible to build new forms/pages without
modifying Java code. That's a basic requirement for this application.
So, the question is, how do I (a) populate the form bean from the JSP
and (b) determine when to do so? Some options I've considered:
1) write a custom tag that looks up the form bean and view object in the
appropriate scope and uses BeanUtils.describe() or some other method to
fill out the form bean; this would probably require the view objects to
expose a describe() method returning a Map since view objects represent
structured data (a view object may have properties that are themselves
view objects)
2) write a 'form manager' bean JSPs can use to say 'populate this form
bean with data from this view object'. The form bean manager then does
the work that is usually done in actions in the traditional 'push'
model. To avoid excessive coupling, a describe() method on the view
objects would be a good idea (otherwise the manager class would have to
know the view - form bean mapping rules for every view object and form
in the system).
3) always render the form using the view object and have the submit
action update the view object with the form data before validating. This
wont work since view objects have typed properties and I wouldn't be
able to 'round trip' invalid inputs (the same reason form beans usually
only use String properties).
4) seperate create, edit and view operations into different JSPs. Appart
from the duplication of markup that introduces, it only helps for the
create (always use the form bean) and view (always use the view object)
cases; edit is still 'broken'.
I'm leaning toward the form manager (option 2) so a JSP might look like:
jsp:useBean var=view class=.../
jsp:useBean var=mgr class=...FormManager/
jsp:setProperty name=mgr property=form value=${the form bean}/
jsp:setProperty name=mgr property=view value=${view}/
The form manager would take an instance of DynaActionForm and update its
map of properties from the view. (I'm assuming the form bean is mutable
in this way!) I'd still need to know when to invoke the form manager I
suppose, but that's easier to solve with a request parameter or other
'state' tracker.
Anyone got any better approaches?
L.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
