Subject: Re: Process in a struts project From: Vic Cekvenich <[EMAIL PROTECTED]> === Great.
A quick and dirty approach: 1. Have a prototype in HTML. Do all possible output/reports. 2. Look at the HTML and design your SQL data model relationships and attribute it. 3. Rename *.HTML *.JSP 4. Create Java Beans based on Forms/and the data model. 5. Based on .JSP and JavaBeans, create struts.xml action mapping. 6. Create an action class. Copy X # of times for each page 7. Create a helper DAO class for beans DAO persistance to DB. 8. Clean up JSPs 9. Customize each action. 10. Add validation 11. Add tiles 12. Add menu You should also do CSS in JSP (if not XSL) I would have one role for Model/beans/SQL, one role for Controler/Application, one role for View/Presentation. Vic Jason B Menard wrote: > We have a different methodology that seems to work pretty well for us. Our > process is almost reverse of yours, since we stress the software engineering > and coding side of things and then worry about look-and-feel. > > Part of our engineering phase is to determine what our screens are, what a > user is able to view, what actions a user may take on each screen, as well > as any view logic. By the time we get to this point though we have already > done coneptual and object models so we can be quite specific. Once we have > this drawn up we have enough info to pass off to our web designers so that > they can mock-up static screens for a customer design review. > > Once engineering is finished and we get into coding, we generally have some > people doing the java classes that make up the backbone of the application, > while others do the view logic and struts classes. Unit testing happens at > each stage. All classes are thoroughly tested before being made available > to the struts programmer, who must work with the view programmer to ensure > that proper application flow is maintained as well as that their appropriate > units work correctly. The jsps being generated by the individuals working > on the views are not what the customer will finally see however, they > contain the functionality, but not the look-and-feel. > > Once we have tested to ensure the application works, only then do we hand it > off to the web programmer/designer. He will then take the jsps and modify > them to implement the look-and-feel, but making sure to retain all > view-logic. We are lucky in our case that our web guys do know custom tags > and java in general, so there is no disconnect here. Once look-and-feel is > integrated, we undergo our final round of testing before handing the project > off for customer acceptance. > > Naturally there is some communication involved during integration testing > between the software engineers and the web programmer/designer, but it hsa > always worked well for us. This methodology gives the web designer > ownership of the pages. Once the project leaves development and is put into > production, it is the responsibility of our software maintenance team (who > have there own programmers and web people) to maintain that version of it > over the remainder of its lifecycle (although naturally future revs go back > to the engineers). > > (1) Doing things this way, our equivalent of your back-end engineers need to > know nothing about html unless they are responsible for implementing the > views. > > (2) Our equivalent of your front-end engineers end up with the pages after > the "back-end engineers", so they have ownership of the pages. > > (3) We have solved your problem of java code in the jsps through engineering > and teaming. Since we have already determined the view logic ahead of time, > it is usually clear in advance where we may need to roll our own custom > tags, or use somebody else's. We generally have at least one person on the > team specifically responsible for custom tags, usually the person(s) > implementing the jsps. > > I think overall the key to solving your problems is shifting your emphasis > towards the back-end and away from the front-end. The back-end is the meat > of the application anyway, with the front-end pretty much being just window > dressing. > > Jason > > > ----- Original Message ----- > From: "Couball, James" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, January 29, 2002 2:22 PM > Subject: Process in a struts project > > > >>Hello, >> >>Please excuse this slightly off topic message, but I felt that this >>discussion could be valuable to the group. Please ignore if you find it >> > too > >>OT. I don't mind suggestions for other forums for this question. >> >>My questions are listed at the end of this email, the rest is background. >> >>We utilize struts on a number of projects. As a user of struts, I am >> > trying > >>to come up with a good process for developing web apps that helps us >> > manage > >>the hand-offs between: >>(1) Graphic designers (responsible for branding, look and feel, color >>schemes, etc.), >>(2) Front-end engineers (responsible for realizing the UI using the >> > graphic > >>designers' guidelines), >>(3) Back-end engineers (know struts, java, J2EE, etc.) >> >>In our current process, the graphics designers design the branding, look >> > and > >>feel, and other graphic elements that make up the user interface. From >> > this > >>HTML templates are created for the different types of pages in our site. >>The front-end engineers then take the page templates and the site map and >>create the pages for the entire site. At this point, we have static HTML >>pages with hard coded 'place holder' values. >> >>The 'static site' is then passed on to the back-end engineers. They fill >> > in > >>the dynamic portion of the pages: populating data and other content. >> >>I have a couple of problems with this: >>(1) The back-end engineers have to know a lot about HTML. Often they have >>to make minor tweeks in the HTML that breaks the page for one browser or >>another. I don't think they should have to know all this. >>(2) Once the front-end engineers hand off the pages, they consider >>themselves done and out of the loop. Global look and feel changes become >>very hard to do because the front-end engineers no longer recognize the >>pages. >>(3) No matter how hard I try, system engineers _still_ put in java code in >>the JSP pages. >> >>**** >>I would like to come up with a solution where: >>(1) The front-end engineers to deliver pages that have been unit tested >> > with > >>test data (not hard coded HTML). >>(2) The front-end engineers own or are responsible for the pages through >> > the > >>lifetime of the system. >>**** >> >>Ok, the first step is to train our front-end engineers to use JSP and our >>custom tags (struts and otherwise). >> >>The second step is to enable the front-end engineers to be able to unit >> > test > >>each page under a variety of different data inputs. That would require a >>number of things: >>(1) First, the data the page makes use of needs to be well defined. This >>would make the job of interfacing between the front-end engineers and the >>back-end engineers easier. However, I don't think there is any standard >> > way > >>of doing this and no way at all of doing this within the JSP page. >>(2) The front-end engineer needs to know how to create the holders for the >>data to be rendered within the page. Using struts, this would involve >>writing java beans or ActionForm beans. (How are these beans >> > configuration > >>managed along with the JSP they apply to?) >>(3) The front-end engineer needs to compile and deploy the JSP. >>(4) The front-end engineer needs a test harness that helps/supports >> > building > >>data objects, storing them in the appropriate scope (page, request, >> > session, > >>...), and then forwarding to the page to be tested. >> >>Using XML/XSLT makes some of these steps easier because there is a well >>defined way to define the model, the front-end engineer does not need to >>create java beans, and the test harness is easier to setup because there >> > are > >>no data beans to populate. >> >>My questions are: >>(1) Does it sound reasonable for front-end engineers to know how to do? >>(2) Are there tools that support this activity? >>(3) Could a servlet (or some other test harness) be written to help the >>front-end engineer unit test their pages? >>(4) Is unit testing page rendering something that is automated or >>eye-balled? >> >>Any comments will be appreciated. >> >>Sincerely, >>James Couball >> >> > > > -- > 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]>
