struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@btinternet.com>
Subject RE: Struts Design/construction process. question
Date Thu, 13 Jun 2002 16:51:02 GMT
I saw this thread and thought..."great, flame war...", but you guys are too
nice.

IMHO I suggest you learn from the guru before trying this next time:

  http://www.IamMarkGalbreath.org/FlameWar/HowTo/AnnoyTheHellOutOfEveryone

Niall

P.S. 'old (35?) mainframe programmers' on this list must have seen the
light...Hallelujah!


> -----Original Message-----
> From: wbchmura@Ensign-BickfordInd.com
> [mailto:wbchmura@Ensign-BickfordInd.com]
>
> 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:Jerry.Jalenak@LABONE.com]
>
> As an 'old mainframe programmer' I resent this.....  (:-)
>
> -----Original Message-----
> From: wbchmura@Ensign-BickfordInd.com
> [mailto:wbchmura@Ensign-BickfordInd.com]
>
> 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:josephb@hereuare.com]
> 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: Jeff_Mychasiw@nlgroup.ca [mailto:Jeff_Mychasiw@nlgroup.ca]
> > Sent: Wednesday, June 12, 2002 4:16 PM
> > To: struts-user@jakarta.apache.org
> > 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:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
>
> 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:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-> unsubscribe@jakarta.apache.org>
> For
> additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
>


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


Mime
View raw message