Re: Custom Actions? (was RE: Benefits of Dynaforms)
Yes, but only if something unusual happens. In the normal course, the struts-config routings fall through. The core idea is that the abstractions belong to *my* application interface. The struts-config is implementing these abstractions on behalf of the greater application. Just as the language abstraction in the Application Resources do not belong to Struts, but are a resource that Struts can share with others. =Ted. 11/27/2002 9:31:50 PM, John Yu [EMAIL PROTECTED] wrote: Ted, So, with respect to the routing instructions, you create a common abstraction (success, failure, etc) describing the exit path of the business process. Gotcha. Thanks. -- John At 06:50 pm 27-11-2002, you wrote: The Actions are generic, but the ActionMappings are not =:0) The ActionMapping passes command tokens to the standard Action so that it knows which business process to invoke. The business facade returns a result object with can carry messages, data, and/or dispatch advice. The messages are Struts-compatible, but mainly because the Struts messsaging API is based on the standard java.util package. So while I'm passing back a message token and several runtime parameters to be merged against the Application Resources, I'm not really using the Struts messaging. I'm using standard messaging, which Struts *also* uses. The data comes back as a collection or as a single form. By default, the Action places collections in request scope under a standard token. By default, if there is an ActionForm in play, the Action repopulates it when a single-form is returned. The very versatile BeanUtils.copyProperties makes it very easy to roundtrip ActionForms and typed JavaBeans. In the rare case when there is any dispatch advice, it generally comes back as a token (e.g. success, failure). This is a continuation of what we do with the messages. We give them names to represent the general idea and let other components fill in the implementation details. In this case, the implementation detail is a URI. But the business facade doesn't know or care about that. Initially, I wasn't keen on the last bit myself. But I developed portions of this to work with the Adalon GUI by Synthis. My coding partner insisted that we do this, and in retrospect, I've come to agree with the idea. Conceptually, Struts is simply the presentation-tier controller. Ideally, there should also be a controller that lives above Struts that could be compatible with multiple platforms (or even multiple frameworks). Like message resources, the application controller can work in terms of simple logical names and let lower components fill in the implementation details. In practice, Struts provides many design artifacts that could exist at a higher level. This is a Good Thing, since it lets simple applications use them directly and sophisticated applications use them as adapters. For the most part, I'm still using the struts-config as my primary controller configuration. But something we all keep wishing for is a more sophisticated workflow controller that would live above Struts. The only responsibility of the struts-config would then be to match the control tokens (success, failure, glockenspiel) with the appropriate URIs. So, from my perspective, Struts knows which tokens my application controller expects. But my application controller has no clue that Struts even exists. Coincidentally, my (conceptual) application controller uses the same design paradigm as the struts-config, just like it uses the same design paradigm for messaging -- but only because great minds think alike =:0) -Ted. 11/26/2002 8:59:49 PM, John Yu [EMAIL PROTECTED] wrote: If the Action is truly generic, how do you avoid returning presentation-specific information in the result objects? e.g. A routing instruction would be something like a forward name . (Am I correct?) If so, the business process knows about configuration in the struts-config.xml. Doesn't the presentation/business-tier boundary become blur? Isn't the business process now becoming an extension of an Action and part of the presentation-layer? (Consider: how to reuse this business process, say in Velocity, and still make use of its result object?) Have I missed something? -- John Basically, I'm putting my business tier behind a facade, and using the ActionMapping decorator to tell the standard Action which operation to invoke. The facade provides a consistent interface and minimizes what the Struts tier needs to know about each operation. -Ted. 11/22/2002 9:47:43 AM, Andre Beskrowni [EMAIL PROTECTED] wrote: ok, this one sentence in ted's post caught my eye: I rarely write custom Actions any more. whoah. how is this possible? most of our web pages represent some sort of database operation: displaying, creating, updating, or deleting. i can see how you can minimize the amount of code that would vary in individual Action classes, but i don't
Re: Custom Actions? (was RE: Benefits of Dynaforms)
The Actions are generic, but the ActionMappings are not =:0) The ActionMapping passes command tokens to the standard Action so that it knows which business process to invoke. The business facade returns a result object with can carry messages, data, and/or dispatch advice. The messages are Struts-compatible, but mainly because the Struts messsaging API is based on the standard java.util package. So while I'm passing back a message token and several runtime parameters to be merged against the Application Resources, I'm not really using the Struts messaging. I'm using standard messaging, which Struts *also* uses. The data comes back as a collection or as a single form. By default, the Action places collections in request scope under a standard token. By default, if there is an ActionForm in play, the Action repopulates it when a single-form is returned. The very versatile BeanUtils.copyProperties makes it very easy to roundtrip ActionForms and typed JavaBeans. In the rare case when there is any dispatch advice, it generally comes back as a token (e.g. success, failure). This is a continuation of what we do with the messages. We give them names to represent the general idea and let other components fill in the implementation details. In this case, the implementation detail is a URI. But the business facade doesn't know or care about that. Initially, I wasn't keen on the last bit myself. But I developed portions of this to work with the Adalon GUI by Synthis. My coding partner insisted that we do this, and in retrospect, I've come to agree with the idea. Conceptually, Struts is simply the presentation-tier controller. Ideally, there should also be a controller that lives above Struts that could be compatible with multiple platforms (or even multiple frameworks). Like message resources, the application controller can work in terms of simple logical names and let lower components fill in the implementation details. In practice, Struts provides many design artifacts that could exist at a higher level. This is a Good Thing, since it lets simple applications use them directly and sophisticated applications use them as adapters. For the most part, I'm still using the struts-config as my primary controller configuration. But something we all keep wishing for is a more sophisticated workflow controller that would live above Struts. The only responsibility of the struts-config would then be to match the control tokens (success, failure, glockenspiel) with the appropriate URIs. So, from my perspective, Struts knows which tokens my application controller expects. But my application controller has no clue that Struts even exists. Coincidentally, my (conceptual) application controller uses the same design paradigm as the struts-config, just like it uses the same design paradigm for messaging -- but only because great minds think alike =:0) -Ted. 11/26/2002 8:59:49 PM, John Yu [EMAIL PROTECTED] wrote: If the Action is truly generic, how do you avoid returning presentation-specific information in the result objects? e.g. A routing instruction would be something like a forward name . (Am I correct?) If so, the business process knows about configuration in the struts-config.xml. Doesn't the presentation/business-tier boundary become blur? Isn't the business process now becoming an extension of an Action and part of the presentation-layer? (Consider: how to reuse this business process, say in Velocity, and still make use of its result object?) Have I missed something? -- John Basically, I'm putting my business tier behind a facade, and using the ActionMapping decorator to tell the standard Action which operation to invoke. The facade provides a consistent interface and minimizes what the Struts tier needs to know about each operation. -Ted. 11/22/2002 9:47:43 AM, Andre Beskrowni [EMAIL PROTECTED] wrote: ok, this one sentence in ted's post caught my eye: I rarely write custom Actions any more. whoah. how is this possible? most of our web pages represent some sort of database operation: displaying, creating, updating, or deleting. i can see how you can minimize the amount of code that would vary in individual Action classes, but i don't see how could eliminate the need for subclassing altogether. maybe i'm just completely misunderstanding here. could you elaborate on your process? thanks, ab -- John Yu Scioworks Technologies e: [EMAIL PROTECTED] w: +(65) 873 5989 w: http://www.scioworks.com m: +(65) 9782 9610 -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Custom Actions? (was RE: Benefits of Dynaforms)
At 04:40 am 23-11-2002, you wrote: The idea behind a Struts Action is that it suppose to give you a place to call your business logic components. Rather than call various business processes through a subclass, I continue the decorator pattern by declaring the process to call as part of the ActionMapping. I then use a standard Action which automatically populates the designed business bean and invokes the business process. The business process returns a specialized result object that the standard Action analyzes. The result object has properties that can return messsages, data, and/or new routing instructions to the Action. Ted, If the Action is truly generic, how do you avoid returning presentation-specific information in the result objects? e.g. A routing instruction would be something like a forward name . (Am I correct?) If so, the business process knows about configuration in the struts-config.xml. Doesn't the presentation/business-tier boundary become blur? Isn't the business process now becoming an extension of an Action and part of the presentation-layer? (Consider: how to reuse this business process, say in Velocity, and still make use of its result object?) Have I missed something? -- John Basically, I'm putting my business tier behind a facade, and using the ActionMapping decorator to tell the standard Action which operation to invoke. The facade provides a consistent interface and minimizes what the Struts tier needs to know about each operation. -Ted. 11/22/2002 9:47:43 AM, Andre Beskrowni [EMAIL PROTECTED] wrote: ok, this one sentence in ted's post caught my eye: I rarely write custom Actions any more. whoah. how is this possible? most of our web pages represent some sort of database operation: displaying, creating, updating, or deleting. i can see how you can minimize the amount of code that would vary in individual Action classes, but i don't see how could eliminate the need for subclassing altogether. maybe i'm just completely misunderstanding here. could you elaborate on your process? thanks, ab -- John Yu Scioworks Technologies e: [EMAIL PROTECTED] w: +(65) 873 5989 w: http://www.scioworks.com m: +(65) 9782 9610 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Benefits of Dynaforms
Sounds like there are many benefits to using DynaForms but is there any downside ? For instance, not having explicit getters means using a generic get method that has return type Object. This in turn means having to use typecasts to cast from Object to some other type The drawbacks of typecasting are the extra run-time overhead plus the possibility of a ClassCastException. I think its a common tradeoff (flexibility versus type-safety). The Ofbiz project (www.ofbiz.org) also pushes the idea of using XML configuration files to define what kind of data is used in the application. It seems like more of an end-to-end solution though than Struts since Ofbiz facilitates automatic construction of the presentation, business, and data access layers all via XML configuration. I didn't see any mention of Ofbiz in the archives and was just wondering if there's been any discussion about this ? Nick -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 6:45 PM To: Struts Developers List Subject: Re: Benefits of Dynaforms 11/20/2002 3:09:36 AM, Erik Hatcher [EMAIL PROTECTED] wrote: As for DynaActionForm's I still don't get their benefit. Do you use them? Or right ActionForm subclasses? Its even less code to write to do a form bean for me, because my IDE generates all the getter/setters, and being able to generate validation.xml makes it so worthwhile. :) The nice thing about DynaForms is that they are a simple solution to a simple problem: I just want to store and validate some simple properties on the presentation layer before passing them up to the business tier. Sure some tools can make JavaBeans very easy to write. DynaBeans are just another one of those tools, and a GUI independant tool at that. It doesn't matter if you are using Eclipse or IntelliJ or JBuilder. A DynaBean is a DynaBean. And before long, I'm sure the IDEs will be helping you code DynaBeans too =:0) The truly excellent part is that you can extend DynaActionForm to create complex helper properties when you need them, or just use the base class when you don't. YMTD. But here's the kicker: With the help of the Validator and a handful of standard Actions, DynaBeans open the door to doing the ~entire~ presentation tier via XML configuration files. I rarely write custom Actions any more. With DynaBeans, I may also be able to get out of writing custom ActionForms. Ideally, a framework like Struts should just be passing gestures and data back and forth between the presentation pages and business tier. IMHO, doing any real programming in Struts is an engineering compromise. Architecturally, we should be trying to help developers avoid as many necessary evils as possible. DynaBeans serve that purpose by making it possible to avoid creating and maintaining yet-another Java class, which, in practice, often encroaches on the business tier. Before DynaBeans, that practice was unavoidable (or at least caused greater evils). With DynaBeans, there is a real possibility that you could code the Struts portion of an application entirely through XML configuration files, and keep all the real programming on the business tier. Here's another kicker: Components like the Validator aren't just for the web tier. You could also be using the Commons Validator in the business tier, which opens the door to a common Validator configuration shared by Struts and the business tier. DynaBeans also have the potential of being the missing buffer we need for data-entry. What about a DynaBean class that included a shadow String field with every dynamic property? (All we need is another map.) If we integrated a DynaBeanBuffer subclass with the Validator, we could then declare field-level validations for our properties. A validate method on the DynaBean could check each of its buffers, and transfer the datea if validation passed, but raise a flag if it didn't. We could then finally use the same bean on the Web tier as we do on the business tier. This sort of thing is a bear to code with conventional JavaBean, but might be worth doing with something like the DynaBean. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Benefits of Dynaforms
Let me just emphasize the downsides that I mentioned already... using DynaForms would mean that I would be hand-coding struts-config.xml and validation.xml. By writing a ValidatorActionForm Java class for all my forms I have to do neither now, and XDoclet is automatically generating these configuration files for me. If anyone is doing something slicker or more automated with this stuff, I'd love to hear about it, but so far I've not encountered anyone accomplishing it to this degree. Erik Afshartous, Nick wrote: Sounds like there are many benefits to using DynaForms but is there any downside ? For instance, not having explicit getters means using a generic get method that has return type Object. This in turn means having to use typecasts to cast from Object to some other type The drawbacks of typecasting are the extra run-time overhead plus the possibility of a ClassCastException. I think its a common tradeoff (flexibility versus type-safety). The Ofbiz project (www.ofbiz.org) also pushes the idea of using XML configuration files to define what kind of data is used in the application. It seems like more of an end-to-end solution though than Struts since Ofbiz facilitates automatic construction of the presentation, business, and data access layers all via XML configuration. I didn't see any mention of Ofbiz in the archives and was just wondering if there's been any discussion about this ? Nick -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 6:45 PM To: Struts Developers List Subject: Re: Benefits of Dynaforms 11/20/2002 3:09:36 AM, Erik Hatcher [EMAIL PROTECTED] wrote: As for DynaActionForm's I still don't get their benefit. Do you use them? Or right ActionForm subclasses? Its even less code to write to do a form bean for me, because my IDE generates all the getter/setters, and being able to generate validation.xml makes it so worthwhile. :) The nice thing about DynaForms is that they are a simple solution to a simple problem: I just want to store and validate some simple properties on the presentation layer before passing them up to the business tier. Sure some tools can make JavaBeans very easy to write. DynaBeans are just another one of those tools, and a GUI independant tool at that. It doesn't matter if you are using Eclipse or IntelliJ or JBuilder. A DynaBean is a DynaBean. And before long, I'm sure the IDEs will be helping you code DynaBeans too =:0) The truly excellent part is that you can extend DynaActionForm to create complex helper properties when you need them, or just use the base class when you don't. YMTD. But here's the kicker: With the help of the Validator and a handful of standard Actions, DynaBeans open the door to doing the ~entire~ presentation tier via XML configuration files. I rarely write custom Actions any more. With DynaBeans, I may also be able to get out of writing custom ActionForms. Ideally, a framework like Struts should just be passing gestures and data back and forth between the presentation pages and business tier. IMHO, doing any real programming in Struts is an engineering compromise. Architecturally, we should be trying to help developers avoid as many necessary evils as possible. DynaBeans serve that purpose by making it possible to avoid creating and maintaining yet-another Java class, which, in practice, often encroaches on the business tier. Before DynaBeans, that practice was unavoidable (or at least caused greater evils). With DynaBeans, there is a real possibility that you could code the Struts portion of an application entirely through XML configuration files, and keep all the real programming on the business tier. Here's another kicker: Components like the Validator aren't just for the web tier. You could also be using the Commons Validator in the business tier, which opens the door to a common Validator configuration shared by Struts and the business tier. DynaBeans also have the potential of being the missing buffer we need for data-entry. What about a DynaBean class that included a shadow String field with every dynamic property? (All we need is another map.) If we integrated a DynaBeanBuffer subclass with the Validator, we could then declare field-level validations for our properties. A validate method on the DynaBean could check each of its buffers, and transfer the datea if validation passed, but raise a flag if it didn't. We could then finally use the same bean on the Web tier as we do on the business tier. This sort of thing is a bear to code with conventional JavaBean, but might be worth doing with something like the DynaBean. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Benefits of Dynaforms
Can you create a small sample application to demonstrate how easy it is? Create a project from the struts-example to do this. I've done this a few times with other issues/concepts (jsp under web-inf, bundle from the database, etc). I'll host the download if you want, or we can get into the struts project on sf.net. Just some ideas -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens? - Seymour Cray (1925-1996), father of supercomputing -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED]] Sent: Monday, November 25, 2002 11:12 AM To: Struts Developers List Subject: Re: Benefits of Dynaforms Let me just emphasize the downsides that I mentioned already... using DynaForms would mean that I would be hand-coding struts-config.xml and validation.xml. By writing a ValidatorActionForm Java class for all my forms I have to do neither now, and XDoclet is automatically generating these configuration files for me. If anyone is doing something slicker or more automated with this stuff, I'd love to hear about it, but so far I've not encountered anyone accomplishing it to this degree. Erik Afshartous, Nick wrote: Sounds like there are many benefits to using DynaForms but is there any downside ? For instance, not having explicit getters means using a generic get method that has return type Object. This in turn means having to use typecasts to cast from Object to some other type The drawbacks of typecasting are the extra run-time overhead plus the possibility of a ClassCastException. I think its a common tradeoff (flexibility versus type-safety). The Ofbiz project (www.ofbiz.org) also pushes the idea of using XML configuration files to define what kind of data is used in the application. It seems like more of an end-to-end solution though than Struts since Ofbiz facilitates automatic construction of the presentation, business, and data access layers all via XML configuration. I didn't see any mention of Ofbiz in the archives and was just wondering if there's been any discussion about this ? Nick -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 6:45 PM To: Struts Developers List Subject: Re: Benefits of Dynaforms 11/20/2002 3:09:36 AM, Erik Hatcher [EMAIL PROTECTED] wrote: As for DynaActionForm's I still don't get their benefit. Do you use them? Or right ActionForm subclasses? Its even less code to write to do a form bean for me, because my IDE generates all the getter/setters, and being able to generate validation.xml makes it so worthwhile. :) The nice thing about DynaForms is that they are a simple solution to a simple problem: I just want to store and validate some simple properties on the presentation layer before passing them up to the business tier. Sure some tools can make JavaBeans very easy to write. DynaBeans are just another one of those tools, and a GUI independant tool at that. It doesn't matter if you are using Eclipse or IntelliJ or JBuilder. A DynaBean is a DynaBean. And before long, I'm sure the IDEs will be helping you code DynaBeans too =:0) The truly excellent part is that you can extend DynaActionForm to create complex helper properties when you need them, or just use the base class when you don't. YMTD. But here's the kicker: With the help of the Validator and a handful of standard Actions, DynaBeans open the door to doing the ~entire~ presentation tier via XML configuration files. I rarely write custom Actions any more. With DynaBeans, I may also be able to get out of writing custom ActionForms. Ideally, a framework like Struts should just be passing gestures and data back and forth between the presentation pages and business tier. IMHO, doing any real programming in Struts is an engineering compromise. Architecturally, we should be trying to help developers avoid as many necessary evils as possible. DynaBeans serve that purpose by making it possible to avoid creating and maintaining yet-another Java class, which, in practice, often encroaches on the business tier. Before DynaBeans, that practice was unavoidable (or at least caused greater evils). With DynaBeans, there is a real possibility that you could code the Struts portion of an application entirely through XML configuration files, and keep all the real programming on the business tier. Here's another kicker: Components like the Validator aren't just for the web tier. You could also be using the Commons Validator in the business tier, which opens the door to a common Validator configuration shared by Struts and the business tier. DynaBeans also have the potential of being the missing buffer we need for data-entry. What about a DynaBean class
Re: Benefits of Dynaforms
Yup, no problem. In fact, its been my plan all along to get this example posted online. The folks that have attended the Complete Programmer symposiums where I've spoken and also the folks that attended my ApacheCon presentation already have access to it (or could e-mail me to get it). I've just finally gotten back home and settling in for the holidays without travel, and I'll have something up by the end of the week. Erik James Mitchell wrote: Can you create a small sample application to demonstrate how easy it is? Create a project from the struts-example to do this. I've done this a few times with other issues/concepts (jsp under web-inf, bundle from the database, etc). I'll host the download if you want, or we can get into the struts project on sf.net. Just some ideas -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens? - Seymour Cray (1925-1996), father of supercomputing -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED]] Sent: Monday, November 25, 2002 11:12 AM To: Struts Developers List Subject: Re: Benefits of Dynaforms Let me just emphasize the downsides that I mentioned already... using DynaForms would mean that I would be hand-coding struts-config.xml and validation.xml. By writing a ValidatorActionForm Java class for all my forms I have to do neither now, and XDoclet is automatically generating these configuration files for me. If anyone is doing something slicker or more automated with this stuff, I'd love to hear about it, but so far I've not encountered anyone accomplishing it to this degree. Erik Afshartous, Nick wrote: Sounds like there are many benefits to using DynaForms but is there any downside ? For instance, not having explicit getters means using a generic get method that has return type Object. This in turn means having to use typecasts to cast from Object to some other type The drawbacks of typecasting are the extra run-time overhead plus the possibility of a ClassCastException. I think its a common tradeoff (flexibility versus type-safety). The Ofbiz project (www.ofbiz.org) also pushes the idea of using XML configuration files to define what kind of data is used in the application. It seems like more of an end-to-end solution though than Struts since Ofbiz facilitates automatic construction of the presentation, business, and data access layers all via XML configuration. I didn't see any mention of Ofbiz in the archives and was just wondering if there's been any discussion about this ? Nick -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 6:45 PM To: Struts Developers List Subject: Re: Benefits of Dynaforms 11/20/2002 3:09:36 AM, Erik Hatcher [EMAIL PROTECTED] wrote: As for DynaActionForm's I still don't get their benefit. Do you use them? Or right ActionForm subclasses? Its even less code to write to do a form bean for me, because my IDE generates all the getter/setters, and being able to generate validation.xml makes it so worthwhile. :) The nice thing about DynaForms is that they are a simple solution to a simple problem: I just want to store and validate some simple properties on the presentation layer before passing them up to the business tier. Sure some tools can make JavaBeans very easy to write. DynaBeans are just another one of those tools, and a GUI independant tool at that. It doesn't matter if you are using Eclipse or IntelliJ or JBuilder. A DynaBean is a DynaBean. And before long, I'm sure the IDEs will be helping you code DynaBeans too =:0) The truly excellent part is that you can extend DynaActionForm to create complex helper properties when you need them, or just use the base class when you don't. YMTD. But here's the kicker: With the help of the Validator and a handful of standard Actions, DynaBeans open the door to doing the ~entire~ presentation tier via XML configuration files. I rarely write custom Actions any more. With DynaBeans, I may also be able to get out of writing custom ActionForms. Ideally, a framework like Struts should just be passing gestures and data back and forth between the presentation pages and business tier. IMHO, doing any real programming in Struts is an engineering compromise. Architecturally, we should be trying to help developers avoid as many necessary evils as possible. DynaBeans serve that purpose by making it possible to avoid creating and maintaining yet-another Java class, which, in practice, often encroaches on the business tier. Before DynaBeans, that practice was unavoidable (or at least caused greater evils). With DynaBeans, there is a real possibility that you could code the Struts portion of an application entirely through XML configuration files, and keep all the real programming on the business tier. Here's another kicker: Components like the Validator aren't just
Custom Actions? (was RE: Benefits of Dynaforms)
ok, this one sentence in ted's post caught my eye: I rarely write custom Actions any more. whoah. how is this possible? most of our web pages represent some sort of database operation: displaying, creating, updating, or deleting. i can see how you can minimize the amount of code that would vary in individual Action classes, but i don't see how could eliminate the need for subclassing altogether. maybe i'm just completely misunderstanding here. could you elaborate on your process? thanks, ab Ideally, a framework like Struts should just be passing gestures and data back and forth between the presentation pages and business tier. IMHO, doing any real programming in Struts is an engineering compromise. Architecturally, we should be trying to help developers avoid as many necessary evils as possible. DynaBeans serve that purpose by making it possible to avoid creating and maintaining yet-another Java class, which, in practice, often encroaches on the business tier. Before DynaBeans, that practice was unavoidable (or at least caused greater evils). With DynaBeans, there is a real possibility that you could code the Struts portion of an application entirely through XML configuration files, and keep all the real programming on the business tier. Here's another kicker: Components like the Validator aren't just for the web tier. You could also be using the Commons Validator in the business tier, which opens the door to a common Validator configuration shared by Struts and the business tier. DynaBeans also have the potential of being the missing buffer we need for data-entry. What about a DynaBean class that included a shadow String field with every dynamic property? (All we need is another map.) If we integrated a DynaBeanBuffer subclass with the Validator, we could then declare field-level validations for our properties. A validate method on the DynaBean could check each of its buffers, and transfer the datea if validation passed, but raise a flag if it didn't. We could then finally use the same bean on the Web tier as we do on the business tier. This sort of thing is a bear to code with conventional JavaBean, but might be worth doing with something like the DynaBean. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Custom Actions? (was RE: Benefits of Dynaforms)
Can anyone point me to the apis for dynaforms (beans) fs -Original Message- From: Andre Beskrowni [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 9:48 AM To: 'Struts Developers List' Subject: Custom Actions? (was RE: Benefits of Dynaforms) ok, this one sentence in ted's post caught my eye: I rarely write custom Actions any more. whoah. how is this possible? most of our web pages represent some sort of database operation: displaying, creating, updating, or deleting. i can see how you can minimize the amount of code that would vary in individual Action classes, but i don't see how could eliminate the need for subclassing altogether. maybe i'm just completely misunderstanding here. could you elaborate on your process? thanks, ab Ideally, a framework like Struts should just be passing gestures and data back and forth between the presentation pages and business tier. IMHO, doing any real programming in Struts is an engineering compromise. Architecturally, we should be trying to help developers avoid as many necessary evils as possible. DynaBeans serve that purpose by making it possible to avoid creating and maintaining yet-another Java class, which, in practice, often encroaches on the business tier. Before DynaBeans, that practice was unavoidable (or at least caused greater evils). With DynaBeans, there is a real possibility that you could code the Struts portion of an application entirely through XML configuration files, and keep all the real programming on the business tier. Here's another kicker: Components like the Validator aren't just for the web tier. You could also be using the Commons Validator in the business tier, which opens the door to a common Validator configuration shared by Struts and the business tier. DynaBeans also have the potential of being the missing buffer we need for data-entry. What about a DynaBean class that included a shadow String field with every dynamic property? (All we need is another map.) If we integrated a DynaBeanBuffer subclass with the Validator, we could then declare field-level validations for our properties. A validate method on the DynaBean could check each of its buffers, and transfer the datea if validation passed, but raise a flag if it didn't. We could then finally use the same bean on the Web tier as we do on the business tier. This sort of thing is a bear to code with conventional JavaBean, but might be worth doing with something like the DynaBean. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Custom Actions? (was RE: Benefits of Dynaforms)
dynabeans: http://jakarta.apache.org/commons/beanutils/api/org/apache/commons/beanutils /package-summary.html dynaforms: http://jakarta.apache.org/struts/api/org/apache/struts/action/package-summar y.html -Original Message- From: Satterwhite, Frank [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 9:56 AM To: 'Struts Developers List' Subject: RE: Custom Actions? (was RE: Benefits of Dynaforms) Can anyone point me to the apis for dynaforms (beans) fs -Original Message- From: Andre Beskrowni [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 9:48 AM To: 'Struts Developers List' Subject: Custom Actions? (was RE: Benefits of Dynaforms) ok, this one sentence in ted's post caught my eye: I rarely write custom Actions any more. whoah. how is this possible? most of our web pages represent some sort of database operation: displaying, creating, updating, or deleting. i can see how you can minimize the amount of code that would vary in individual Action classes, but i don't see how could eliminate the need for subclassing altogether. maybe i'm just completely misunderstanding here. could you elaborate on your process? thanks, ab Ideally, a framework like Struts should just be passing gestures and data back and forth between the presentation pages and business tier. IMHO, doing any real programming in Struts is an engineering compromise. Architecturally, we should be trying to help developers avoid as many necessary evils as possible. DynaBeans serve that purpose by making it possible to avoid creating and maintaining yet-another Java class, which, in practice, often encroaches on the business tier. Before DynaBeans, that practice was unavoidable (or at least caused greater evils). With DynaBeans, there is a real possibility that you could code the Struts portion of an application entirely through XML configuration files, and keep all the real programming on the business tier. Here's another kicker: Components like the Validator aren't just for the web tier. You could also be using the Commons Validator in the business tier, which opens the door to a common Validator configuration shared by Struts and the business tier. DynaBeans also have the potential of being the missing buffer we need for data-entry. What about a DynaBean class that included a shadow String field with every dynamic property? (All we need is another map.) If we integrated a DynaBeanBuffer subclass with the Validator, we could then declare field-level validations for our properties. A validate method on the DynaBean could check each of its buffers, and transfer the datea if validation passed, but raise a flag if it didn't. We could then finally use the same bean on the Web tier as we do on the business tier. This sort of thing is a bear to code with conventional JavaBean, but might be worth doing with something like the DynaBean. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Custom Actions? (was RE: Benefits of Dynaforms)
The idea behind a Struts Action is that it suppose to give you a place to call your business logic components. Rather than call various business processes through a subclass, I continue the decorator pattern by declaring the process to call as part of the ActionMapping. I then use a standard Action which automatically populates the designed business bean and invokes the business process. The business process returns a specialized result object that the standard Action analyzes. The result object has properties that can return messsages, data, and/or new routing instructions to the Action. Basically, I'm putting my business tier behind a facade, and using the ActionMapping decorator to tell the standard Action which operation to invoke. The facade provides a consistent interface and minimizes what the Struts tier needs to know about each operation. -Ted. 11/22/2002 9:47:43 AM, Andre Beskrowni [EMAIL PROTECTED] wrote: ok, this one sentence in ted's post caught my eye: I rarely write custom Actions any more. whoah. how is this possible? most of our web pages represent some sort of database operation: displaying, creating, updating, or deleting. i can see how you can minimize the amount of code that would vary in individual Action classes, but i don't see how could eliminate the need for subclassing altogether. maybe i'm just completely misunderstanding here. could you elaborate on your process? thanks, ab Ideally, a framework like Struts should just be passing gestures and data back and forth between the presentation pages and business tier. IMHO, doing any real programming in Struts is an engineering compromise. Architecturally, we should be trying to help developers avoid as many necessary evils as possible. DynaBeans serve that purpose by making it possible to avoid creating and maintaining yet-another Java class, which, in practice, often encroaches on the business tier. Before DynaBeans, that practice was unavoidable (or at least caused greater evils). With DynaBeans, there is a real possibility that you could code the Struts portion of an application entirely through XML configuration files, and keep all the real programming on the business tier. Here's another kicker: Components like the Validator aren't just for the web tier. You could also be using the Commons Validator in the business tier, which opens the door to a common Validator configuration shared by Struts and the business tier. DynaBeans also have the potential of being the missing buffer we need for data-entry. What about a DynaBean class that included a shadow String field with every dynamic property? (All we need is another map.) If we integrated a DynaBeanBuffer subclass with the Validator, we could then declare field-level validations for our properties. A validate method on the DynaBean could check each of its buffers, and transfer the datea if validation passed, but raise a flag if it didn't. We could then finally use the same bean on the Web tier as we do on the business tier. This sort of thing is a bear to code with conventional JavaBean, but might be worth doing with something like the DynaBean. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
