Re: Struts Design/construction process. question
You might take a look at the Artimus example application. http://husted.com/struts/resources/artimus.zip This doesn't use custom Actions classes for most operations, and the ones I did use were mostly for show. There's a single framework Action that calls a business operation, the same way the Struts ActionServlet calls an Action. The difference is the business operation is not tied to Struts or HTTP, and can be unit tested using conventional tools. These business beans could be the disconnected components your project manager wants people to pump out. Someone would then connect the dots in the Struts config by associating URIs with the business operations. I'd also recommend using a single coarse-grained ActionForm for all your pages. Then subclass that for specific validations if needed. In a 1.0 team setting, this ActionForm can be maintained like the deployment descriptor or struts-config (usually by a designated guru). In 1.1, there can be a coarse-grained bean for each module, or you can switch over to a Map-based ActionForm or a DynaBean. The classes and architecture in Artimus is based on code developed for the Adalon tool, which Synthis kindly donated back to the ASF. http://synthis.com/ -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services [EMAIL PROTECTED] wrote: 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]
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]
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
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
RE: Struts Design/construction process. question
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
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
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
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
RE: Struts Design/construction process. question
Yeah, you can. That's why their called 'Enterprise Servers' now-a-days. (:-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 13, 2002 12:35 PM 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
RE: Struts Design/construction process. question
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
RE: Struts Design/construction process. question
Yeah Excellent, yahh 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 13 June 2002 18:35 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
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]
