core dumps, anyone? :) > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 13, 2002 10:35 AM > To: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]] > 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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] > > > > 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]] > > > > As an 'old mainframe programmer' I resent this..... (:-) > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] > > > > 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:struts-user-> [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]>
