I'd like to second much of what Ted said. I've just completed my first
project using struts - I was building and learning at the same time.
I had a series of about 10 screens, with some reasonably complicated
jumping backwards and forwards between screens.
This is how I ended up doing things:
1. Did a basic specification myself - it was to be a re-implementation
of a current system so I had some idea of overall functionality. I had a fair
idea of what was needed on each screen from the old system
so this took the place of the storyboard. Part of this specification was
the database design.
2. Developed the overall skeleton of page control and data entry, in
combination with some simple JSPs ie no flashy graphics, fancy
tables, etc just the fields and buttons I needed and some simple
descriptive text.
Then it got messy - we had the usual "scope change" and suddenly
I had one of our designers writing a detailed specification (including defining
what went on each screen and the validation), taking into account
a raft of new functionality, while I got on with fleshing out the
skeleton already constructed (as the deadline was tight and we couldn't wait).
This is where you work really closely together - I was showing her my screens
and the flow as I was going and we were discussing how we could "best" way
implement the new functionality. The good side of this was that
I could give her feedback on what would be easy to implement
and what would be harder, so she wrote the specification to suit
what would be easier (when possible).
I "finished" the bulk of the processing (excluding certain back end pieces
and particular chunks of functionality) to the point where our
html expert could work on the jsp files. There were hooks in
place for particular processing components I hadn't completed and
the values on the screens were returning 0 or other dummy values.
Funnily enough, this was about a week after the spec was finished <grin>.
3. Our html person took over making the pages look the way the
designers wanted - with the ads and the fancy layout and fonts, etc. The
stuff that would drive me crazy.
After that it was co-development - I was plugging in back end functionality
as it was completed and writing new bits and pieces in the webforms
to make life easier for our html person. As you build the jsps and show
them to people, you start finding out all the little requirements/difference
in concept that you have between people. So I was making bug fixes,
adding new tags, changing validation, and working on back end tasks
like data conversion from old systems, operational instructions, etc.
What would I do differently from what I did?
>4. As Will says, identify, build, and test any reusable objects first,
>say for CRUD operations. Also try to layer your code so things like SQL
>commands and statements can be used and tested seperately.
This is important - its not in my list above as I wasn't really doing it. Some
larger bits of the overall system had been identified as "shared/reusable"
components up front (like some of our database access code) and
other people in the team were working on them. So I was just writing
the hooks ready for the parts to be done, then plugging them
in when they became available.
I would have done more taglibs earlier - to make life easier for the html
person. He inherited too many bits of Java in the JSP pages or I had
to redo pages that were basically huge chunks of Java
before passing this on to him - this due to my shortage
of experience with JSP tags and taglibs when I started.
Locking down the overall functionality before I started coding would
have been nice, but then again so would a million dollars. Scope change
is just life in the computer industry.
While doing some of the back end work last meant that you had people
looking at a "functioning" system earlier and able to spot misunderstandings
in functionality. The downside is that you are trying to do front end
bug fixes while implementing other functionality, and time can tend
to get very tight fitting it all in. You need to have management who
really does believe you when you say "no its not finished as the following
parts of the backend aren't finished/tested".
To summarise I guess I'd say neither JSP nor Java comes first. Planning does.
Work out your overall flow and functionality first, be it html
screens or on paper, get a detailed specification written asap, and
be prepared for lots and lots of iterations between the Java code
and the JSP pages.
And if the deadline is tight and you aren't a one man team, get ready
for lots of talking to your fellow team members - even down to
"I'm going to be making the following changes to blah.jsp this morning
while I implement blah. Is that okay or do you need the file to work
on?"
Fiona
