struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Takhar, Sandeep" <Sandeep.Tak...@CIBC.ca>
Subject RE: Need advice on design decisions and architecture issues.
Date Thu, 08 Apr 2004 11:51:59 GMT
Anyone know if the lazy dynabean mentioned works on lists or not?  I can't imagine how it would.
 Same with nested beans.  I guess I might have to take a look and see what happens.

sandeep

-----Original Message-----
From: Niall Pemberton [mailto:niall.pemberton@blueyonder.co.uk]
Sent: Wednesday, April 07, 2004 9:16 PM
To: Struts Users Mailing List
Subject: Re: Need advice on design decisions and architecture issues.



Skip Hollowell wrote:

> This app will require a user to log in, and based upon who they are, they
> will have certain priveleges in the system.  Some of these priveleges may
be
> modified by a manager at anytime (user has processed their dollar limit
for
> the day, but needs a higher limit for whatever reason).
>
> The interface will be Tab based, and tabs will be enabled/disabled on
> per-user basis. Each tab will represent a page with a form (or several
> forms) of data that display things from the database and allow the user to
> update data in the database.  I also believe that since this is a
> customer-care application, that not more than 1 user will be working with
> any given set of customer data at any 1 time.
>
> Things I know so far.  We are using Struts 1.1 as the basic framework for
> the system.  We are using Tiles for piecing together the parts of the
> interface (tabBar, header, body, footer for each page).  It has also been
> suggested that we use SAIF (Interceptor Framework) to be able to process
> before every action whether the user is logged in, and what they are
allowed
> to do.  We could then also do some after-action processing as needed.
>
> Now the questions:
>
> 1. With my tabs, I have what turns out to be at least 30 actions, and will
> probable be closer to 60 when it is all said and done.  So I have created
> them all in the struts-config.xml as show below.  But then I am going to
> need form beans for each one, and a DynaValidatorActionForm for each,
won't
> I?  The granularity of this is nice, and I like the concept of keeping
> everything separated out, but is this overkill?  Is there a better way to
do
> this kind of work?  As you can see, some of this is related functionality,
> but just for different types of data.  Is there some way to use just 1
> Action for all these forms on my app?  (I would doubt it, but I want to
see
> what you have to say)

If your system has 30 completely different forms then its not overkill to
have 30 DynaValidatorActionForm's to represent them. If though sets of forms
shared alot of common data then maybe you can define a few generic forms and
reuse them with multiple actions - for example maybe your "PpiPlaceCall" and
"WifiPlaceCall" actions have almost the same data. Are you aware of the
difference between DynaValidatorForm and DynaValidatorActionForm? Just in
case you're not - DynaValidatorForm uses the form name and
DynaValidatorActionForm uses the action path to get the validation rules
from validation.xml .

so in struts-config.xml...

   <form-beans>
        <form-bean name="PlaceCallForm" dynamic="true"
                              type="o.a.s.v.DynaValidatorActionForm">
                  <form-property name="phoneNumber" ....>
                  <form-property name="caller" ....>
                  <form-property name="PpiField" ....>
                  <form-property name="WifiField" ....>
        </form-bean>
  </form-beans>

  <action   path="/PpiPlaceCall" name="PlaceCallForm"
       type="org.apache.struts.actions.ForwardAction"
      parameter=".ppi.placeCallLayout" />

 <action   path="/WifiPlaceCall" name="PlaceCallForm"
       type="org.apache.struts.actions.ForwardAction"
      parameter=".wifi.placeCallLayout" />

and in validation.xml...

    <form name="/PpiPlaceCall" >
           <field property="phoneNumber"....>
           <field property="caller"....>
           <field property="PpiField"....>
    </form>
    <form name="/WifiPlaceCall" >
           <field property="phoneNumber"....>
           <field property="caller"....>
           <field property="WifiField"....>
    </form>

A couple of alternatives to this though:

   1) LazyValidatorActionForm:
            http://www.niallp.pwp.blueyonder.co.uk

   2) Hubert's FormDef plugin
           http://www.rabago.net/struts/formdef/


> 2. Is SAIF the best (probably not) way to go for handling users and roles.
> How do you handle what a user is allowed to do and see in a struts based
> application?  What do I do if a user tries to hand code an URL and go to a
> part of the system he is not authorized for?  Right now I am looking at
the
> SAIF saying "not authorized" (which I already have) and then ... what?
> Redirecting them to the login page I would assume (if they are not logged
> in) or to the main (start) page if they are logged in.

Haven't used SAIF so I can't comment on it.

We use container managed security to control access to the webapp. Within
the webapp itself we have a rolled our own security to determine whether a
use is allowed to run a particular action and/or if they are allowed access
to the data that action is trying to process. All our jsp's are located
under the WEB-INF directory so a user cannot access them directly. Different
Actions need different security checks, some actions can be run by anyone
logged on (e.g. "change password" action) some check if the user is
authorised for the Action, some check if the user is authorised for the data
and some check both Action and Data. If the user tries to run an Action or
access data they are not authorised for then they get re-directed to a "Not
Authorized" page - as they are still "logged on" within the web app they can
then carry on navigating around the system afterwards. All our Actions
derive from a "base" action, containing the security logic, and configure
themseleves on which parts of the security checking to perform. We could
have plugged some of this logic into a filter or a custom request processor
rather than deriving all actions from a "base" Action - but it works well
for us at the moment.

Niall



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message