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 19:20:38 GMT
Yeah Excellent, yahhhhhh booo...you suck too.

I still think we don't quite live up to the MG standard though - yoiu let
yourself down on the 'take back', but thanks, hehe ;-)

Niall

> -----Original Message-----
> From: wbchmura@Ensign-BickfordInd.com
> [mailto:wbchmura@Ensign-BickfordInd.com]
> Sent: 13 June 2002 18:35
> To: struts-user@jakarta.apache.org
> Subject: RE: Struts Design/construction process. question
>
>
>
> We may be heading off topic here...  I started out at the tail end of
> that era...  I swore an oath that I would never work on a mainframe and
> managed to avoid COBOL, RPG, JCL, Mainfram Assembler, Fortran except in
> school...
>
> Now back our regularly scheduled topics....
>
> MAINFRAMES SUCK! (Happy Niall?)
> (incidentally the above was in jest - I hear you can run Linux on them
> now...)
>
>
>
> -----Original Message-----
> From: Jerry.Jalenak [mailto:Jerry.Jalenak@LABONE.com]
> Sent: Thursday, June 13, 2002 1:00 PM
> To: struts-user
> Subject: RE: Struts Design/construction process. question
>
>
> Hard to believe there was a time when Cobol ruled the universe and
> programs
> were designed in a 'top-down' fashion isn't it?  And as an old (actually
> 40+) mainframe programmer who is trying to make the transition from the
> non-object world of Cobol and (gasp here) assembler to the
> object-oriented
> world of Java (and JSP and struts and XML and and and), there are times
> when
> I really miss those 'good old days'.  But then I think, nah, just post a
> question on the mailing list and get the 'right' answer from all of you
> guys!
>
> Jerry
>
> -----Original Message-----
> From: Niall Pemberton [mailto:niall.pemberton@btinternet.com]
> Sent: Thursday, June 13, 2002 11:51 AM
> To: Struts Users Mailing List
> Subject: RE: Struts Design/construction process. question
>
>
> 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>
>
>
> 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