Yeah, those were the days (sigh).  I suspected that was what you meant, but
couldn't resist.....



-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 9:33 AM
To: [EMAIL PROTECTED]
Subject: RE: Struts Design/construction process. question


I'd like to apologize for that comment...  I did not mean it as a bad 
thing...

I guess I just liken the old mainframes with the old programming 
methodologies that involved tons of upfront planning and an pretty 
unflexible design once programming started.  Back when the project 
delivery times were in years, not weeks...

:)


-----Original Message-----
From: Jerry.Jalenak [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 10:19 AM
To: struts-user
Subject: RE: Struts Design/construction process. question


As an 'old mainframe programmer' I resent this.....  (:-)



-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 13, 2002 8:52 AM
To: [EMAIL PROTECTED]
Subject: RE: Struts Design/construction process. question



I tend to agree on this.  I have only done a few things in struts, but 
have been programming for quite a while.  The idea of pumping everything 

out in seperate development projects just out right scares me.  If this 
was to have any chance of working out you would need:

(1) A horrendous amount of upfront planning
(2) Program requirements that don't change at all
(3) A programming team that would not quit during an upfront design this 

heavy


All in all, if its a large project you could probably dub it a death 
march project.

#1 is too terrible to consider, #2 is just plain silly, #3... well...

Personally, iterative development has worked in most of the projects I 
have been on and run.  

Thats all from here...

PS. Are the project managers old mainframe programmers or something? 



-----Original Message-----
From: josephb [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 12, 2002 7:54 PM
To: struts-user
Subject: RE: Struts Design/construction process. question


This reminds me of the adage a former professor of mine used to preach:
"It is much easier to build a program than to give birth to one."

The "pump out a list of components" and "while bringing the page to 
life"
parts of your message make it sound an awful lot like your project
management is involved in obstetrics in addition to software 
development. :)

Seriously, though, you *will* run into problems doing things this way.  
For
instance, having a junior developer create 60 form beans for the 
expected
inputs on each page has several implications:

1.  Your action developers will have to modify the beans anyway most 
likely
because the form bean developer cannot know things like whether an array 

or
a List is more appropriate for collection data in a particular instance
(this usually depends on the Action).

2. A naming convention for the beans must be established or madness will
ensue.

3. It may make sense to re-use a form bean for different jsps, or nest 
form
beans depending on the implementation of the action classes.  The form 
bean
developer will not know the nature of this implementation ahead of time 
and
thus cannot make these decisions.

b.t.w., there are tools (or you can build your own) for generating basic
ActionForm beans, so this is not really an issue anyway.


> I have always assumed that the action classes would be completed
> at the same
> time that the page is converted to jsp/struts.

Add "ActionForm classes" to the above statement and you are entirely
correct.  We tend to view an Action, its ActionForm, and the 
presentation
logic (i.e., Struts tags) in their associated JSP(s) as an "action 
module"
of sorts, and a single developer is resonsible for these components.  
Things
become very messy when you try to split the JSP, ActionForm, and Action 
work
to different developers, IMHO.


My $.02  ( more like $1.02?)


peace,

Joe Barefoot


> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 12, 2002 4:16 PM
> To: [EMAIL PROTECTED]
> Subject: Struts Design/construction process. question
>
>
>
>
> This is our *FIRST* Struts project and we are putting together a
> construction
> plan.
>
> I would like to find out how other projects divide the work
> between developers.
> Our project management would like to see a developer pump out a 
list(s) of
> disconnected components and have one person "connect" them together.
>
> Our page layout is well in place, and I can create a list of form 
beans.
> *note - we are not using dynabeans.
>
> So... our HMTL guy can go ahead a create the 60 pages in one shot.
> A junior developer can create 60 form beans....
>
> If you are not using something like Junit, is it practical to
> design and create
> many action classes ahead of time?
>
> I have always assumed that the action classes would be completed
> at the same
> time that the page is converted to jsp/struts.
> I would have already created a generic template (that would
> compile and run ),
> so it seems to me that the final code in the perform method
> would be added while brining the page to life.
>
> I would enjoy hearing other stories.
>
>
>
> --
> 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]>


This transmission (and any information attached to it) may be 
confidential and is intended solely for the use of the individual or 
entity to which it is addressed. If you are not the intended recipient 
or the person responsible for delivering the transmission to the 
intended recipient, be advised that you have received this transmission 
in error and that any use, dissemination, forwarding, printing, or 
copying of this information is strictly prohibited. If you have received 
this transmission in error, please immediately notify LabOne at 
(800)388-4675.



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

Reply via email to