Funny you should mention that book. I *just* got that book this morning.
Plan to do some reading this week.

Thanks!



                                                                                       
                                                   
                      shirishchandra.sakh                                              
                                                   
                      [EMAIL PROTECTED]                To:       
[EMAIL PROTECTED]                                                 
                                                 cc:       (bcc: David Z. 
Pantich/OE/FirstEnergy)                                         
                      02/11/2003 11:11 AM        Subject:  RE: I have the same 
question but about Forms.                                  
                      Please respond to                                                
                                                   
                      "Struts Users                                                    
                                                   
                      Mailing List"                                                    
                                                   
                                                                                       
                                                   
                                                                                       
                                                   




I think this issue is very well explained by Ted in his book Struts In
Action..
As he says,Forms sghould be just treated as carriers of data till the data
is
validated and hold the data till in case same is required to be returned to
the
user.
So we should not waste too much time to design form classes but add
attributes
as and when required.

SO depending on u r system,U have to decide.
But what i have found works best is have a base form for all Aplication
which
has common properties (Like UserName,Company id etct etc which is required
for
each user..)And then extend forms per functionality(Like one super class
form
for 4 or 5 OrderFunctions ).
And also as u said, i also had to add common attributes at the module
level.But
this works best.

Hope this helps.
regards,
Shirish

-----Original Message-----
From: pantichd [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 11, 2003 5:06 PM
To: struts-user
Cc: pantichd
Subject: I have the same question but about Forms.



Hello,

Not sure if this deserves another thread or if I can attach it to this one.
I'm new to mailing lists so please be kind.  :  )

I'm working on a struts project now and going back and forth on whether to
just have one form for the whole system or have many forms.

In our case we put the common fields in a base form and created other forms
to extend that one. Each of those forms correspond to a specific section in
the system. The problem we're running into now is that we're finding more
and more common items and having to move them into the base form. Which
lead me to think about just having one form and not bothering with the
others.

Comments?






                      "Taylor Cowan"

                      <t.cowan@charter.        To:       "Struts Users
Mailing
List" <[EMAIL PROTECTED]>
                      net>                     cc:       (bcc: David Z.
Pantich/OE/FirstEnergy)
                                               Subject:  Opionions: fine or
course grained actions
                      02/07/2003 09:19

                      AM

                      Please respond to

                      "Struts Users

                      Mailing List"









I wanted to see what others in the struts community think about Action
granularity.  I've coded apps that are -extremely- fine grained, having one
Action per user event, like createPreferencesAction,
deletePreferencesAction, update...etc.  The fine grained approach yields
more than one action per screen, and contention for the struts config file
during development.  In the middle are apps that basically have one action
per screen that handles all the button clicks with a switch if/else block.
That's the moderate approach.  The last style is -extremely- coarse grained
in that there might only be one action for the entire app.  Coarse grained
has worked best for XML/XSLT type work flows and in some other situations.

What do you think about Action granularity, should it be very fine and thus
more "HTTP" like in nature, or more coarse grained having fewer URL's?

Taylor


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to