No, just working with it as a user. bob
----- Original Message ----- From: "Phase Web and Multimedia" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Friday, April 26, 2002 12:59 PM Subject: RE: Struts Improvement Proposal: Logic Extensibility > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
