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]>
