Bob, Are you involved in the development of the workflow proposal?
-----Original Message----- From: Robert Williams [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 11:50 AM To: Struts Users Mailing List Subject: Re: Struts Improvement Proposal: Logic Extensibility I have looked at the Workflow stuff and will probably use it. It will work great for the problem mentioned here. However, I will be making some changes/extensions to it to make it easier to use. It is a little too low level "out-of-the-box." Extending it has been easy since all of the basics are there. The base design looks great - a good start - but needs to be flushed out. bob ----- Original Message ----- From: "Phase Web and Multimedia" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Friday, April 26, 2002 12:21 PM Subject: RE: Struts Improvement Proposal: Logic Extensibility > Peter do you know anything about the workflow proposal and if it addresses > this issue. I don't want to carry on about this if something standard is in > the works. Also, let's move this discussion over the the developer group. I > was a bad boy and started a discussion on the dev and the user. Bad posting > edicate :-). > > Brandon Goodin > Phase Web and Multimedia > P (406) 862-2245 > F (406) 862-0354 > [EMAIL PROTECTED] > http://www.phase.ws > > -----Original Message----- > From: Peter Pilgrim [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 10:06 AM > To: Struts Users Mailing List > Subject: Re: Struts Improvement Proposal: Logic Extensibility > > > > > I got the XML completely wrong, haven't I > > <struts-config > xmlns:struts="http://jakarta.apache.org/struts/struts-config.dtd"; > xmlns xmls:acme="http://www.acme.com/acton-processor"; > > > ... > > <struts:extensions> > <!-- within the struts extension body tag we can handle additions --> > <acme:processor> > <acme:process-group name="check-login-and-authorize"> > <acme:process-action name="com.mydomain.LoginCheck"> > <acme:process-action name="com.mydomain.UserAuthorize"> > <acme:/process-group> > <acme:/processor> > <struts:extensions> > > ... > > > </struts-config> > > Extension are recognised inside a <struts:extension> tag. > > In this way nobody is forced to use the <acme:processor> tags. > Developer add other extension or replace the existing one with > better extensions, or delete a deprecated extension. > > All extension are then optionally and downloadable and plug-in able. > > Unless my understanding my of XML and namespaces is completely wrong > this should in theory work in principle? > > -- > Peter Pilgrim ++44 (0)207-545-9923 > > ............................................ Swamped under electronic mails > > > ---------------------------------------- Message > History ---------------------------------------- > > > From: Peter Pilgrim/DMGIT/DMG UK/DeuBa@DMG UK on 26/04/2002 14:27 CET > > Please respond to "Struts Users Mailing List" > <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > cc: > Subject: Re: Struts Improvement Proposal: Logic Extensibility > > > > > > So why do not subclass Action and make another abstract > AcmeSecureAction of your self that does the login check and > the authorise. > > There is real danger that your other action may accidentally > miss the security check, if say a newbie developer forgets > add the process-group tags. > > If you want to add this to the struts-config XML then the > Struts Digester code needs changing. I would suggest looking at > ways that the digester code could be expanded with namespaces > > <xmlns xmls:acme="http://www.acme.com/aciton-processor"; > > <acme:processor> > <acme:process-group name="check-login-and-authorize"> > <acme:process-action name="com.mydomain.LoginCheck"> > <acme:process-action name="com.mydomain.UserAuthorize"> > <acme:/process-group> > <acme:/processor> > > Some sort of factory interface I guess. and additionally > ActionServlet init parameters > > digesterExtension=com.acme.struts.digester.ActionProcessor > > -- > Peter Pilgrim ++44 (0)207-545-9923 > > ............................................ Swamped under electronic mails > > > ---------------------------------------- Message > History ---------------------------------------- > > > From: [EMAIL PROTECTED] on 26/04/2002 07:46 AST > > Please respond to "Struts Users Mailing List" > <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > cc: > Subject: Re: Struts Improvement Proposal: Logic Extensibility > > > > > > So for example, if I wanted to ensure a user was logged in, then check > their authorizatoin for a particular URI, could I do something like: > > <processor> > <process-group name="check-login-and-authorize"> > <process-action name="com.mydomain.LoginCheck"> > <process-action name="com.mydomain.UserAuthorize"> > </process-group> > </processor> > > Then I could reuse this logic without having to embed it in each action > class. > > Is this what you're proposing? Do I understand correctly? > > > > > > > > > "Phase Web and Multimedia" <[EMAIL PROTECTED]> on 04/25/2002 05:36:57 PM > > Please respond to "Struts Users Mailing List" > <[EMAIL PROTECTED]> > > To: "Struts User" <[EMAIL PROTECTED]> > cc: > Subject: Struts Improvement Proposal: Logic Extensibility > > > Okay here is the idea I proposed earlier ("Struts (MVC) Shortcomings?") in > more solid thought. > > My hope in this is to provide an non-hard-coding mechanism to take > advantage > of reusable logic without having to forward around to a bunch of Action > classes (which doesn't work anyways). > > Here is my proposal: > > An action mapping could have an associated Process Config specified in the > <set-property> of the action class. Something like: > <set-property name="processor" value="processa" /> > > An associated config file called processor.xml could be set up to define > process patterns that have names associated with the value attribute of the > set-property. Something like: > <processor> > <process-group name="processa"> > <process-action name="com.mydomain.ProcessThisA"> > <process-action name="com.mydomain.ProcessThisB"> > </process-group> > <process-groupname="processb"> > <process-action name="com.mydomain.ProcessThisB"> > <process-action name="com.mydomain.ProcessThisC"> > </process-group> > <process-groupname="processd"> > <process-action name="com.mydomain.ProcessThisX"> > <process-action name="com.mydomain.ProcessThisC"> > <process-action name="com.mydomain.ProcessThisN"> > </process-group> > </processor> > > This config info could be placed into the Application Scope at the app > startup using the plugin mechanism of Struts 1.1. > > When an Action is called it would look to see what "process group" it needs > to call and using reflection to perform the specified chain of processing > in > the order specified in the process-groupname config. > > A process class would conform to an interface and would have access to > everything that the Action has access to. This way any errors or scoped > beans/Attributes that need to be set can be set from within the process > class. Also, the process class could access other logic beans for sql and > such. > > Any unique coding that needs to happen can still be contained in an Action > class. But for code that is reusable. This would be very nice. > > Brandon Goodin > Phase Web and Multimedia > P (406) 862-2245 > F (406) 862-0354 > [EMAIL PROTECTED] > http://www.phase.ws > > > -- > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > > > > > > > -------------------------------------------------------------------------- - > This e-mail message (including attachments, if any) is intended for the use > of the individual or entity to which it is addressed and may contain > information that is privileged, proprietary , confidential and exempt from > disclosure. If you are not the intended recipient, you are notified that > any dissemination, distribution or copying of this communication is > strictly prohibited. If you have received this communication in error, > please notify the sender and erase this e-mail message immediately. > -------------------------------------------------------------------------- - > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > > > -- > 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]>
