Re: Kick start to Struts

[Ted Husted <hu...@apache.org>]

As Will says, there's more than one approach, but here's what works for
me:

1. Write a specification, even if it's for yourself and just a paragraph
long. I started a sample outline for one th example at <
http://husted.com/about/struts/example-spec.html >, but never finished
it. 

2. Storyboard the application workflow. Here I just whip up some HTML
screens with a visual editor like Dreamweaver or Frontpage. For testing
forms, you can put another storyboard page in as the action target, and
sample results on the other side. 

3. Now that I know what I'm writing ;-), I design the model (database
tables and queries). 

This is generally the first third of a project. 

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.

5. Plan a path through your storyboard, and start building the JSP pages
and the support code to hook them up to the objects and the model. Look
for the simplest, useful workflow, and implement that first.

This is generally the second third of a project. The last third is
testing the application and making changes, including bug fixes. 

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/


William Jaynes wrote:
> 
> Don't be too hard on yourself. I'm not sure how much of programming has ever
> become second nature to me. No matter how experienced one gets, there's always
> too much new stuff to learn.
> 
> There is no right answer. You have to work out what is best for yourself. Some
> advocate an approach that starts with the html, kind of a story boarding
> approach. (see Ted's http://husted.com/about/struts/strutByStrut.htm) Other's
> would say get the model right first, develop those objects, test them outside
> any specific application (perhaps using JUnit). Of course, the usual method is
> somewhere in between. (mmm... I guess this isn't much help.)
> 
> Will
> 
> ----- Original Message -----
> From: "Rodney Smith" <ro...@gmx.net>
> To: <st...@jakarta.apache.org>
> Sent: Thursday, August 09, 2001 3:54 AM
> Subject: Kick start to Struts
> 
> Hi all,
> 
> Which comes first the chicken or the egg?
> I need to know when creating a struts web application which comes first,
> creating the java component first, then build the html and convert to jsp?
> that is the question I need to get started into my own web application
> through struts. I would really like as much feed back as possible in the best
> professional approach to this. As I have so much enthusiasm, but not enough
> knowledge in this area.
> This sort of information that I request is second nature to web designs and
> programmers I gather, but I am new to the game.
> 
> Thanks to all those listeners and most importantly thanks to the perfect
> responses from Ted and Craig.
> 
> Kind Regards
> Rodney Smith
> 
> --
> Sent through GMX FreeMail - http://www.gmx.net

Re: Kick start to Struts

[Ted Husted <hu...@apache.org>]

Ted Husted wrote:
> [Upfront planning] is generally the first third of a project.

At least if you're smart ;-), otherwise you end up doing the planning
during the construction phase, which leads to a lot of reconstruction
(built the wrong thing, so now we need to build it again), and the
infamous "fourth third" most projects need before they can ship ;-(

-Ted.

Re: Kick start to Struts

[Keith Bacon <ke...@yahoo.com>]

Thanks for your experience Fiona, sounds like you had a good project
& team there. (This from a kiwi too!).

Lets have more like that every-one.

Notes On Layering Making System Testable & Adaptable
====================================================
In a small scale environment we used to develop business classes
(model components) & write a Swing GUI to test them. The laters here
were 
- business logic (MVC model)
- Swing GUI (JPanels usable in Applications or Applet - MVC view &
controller).
- Menu system with containers to display the GUI in.

Also we wrote 'batch' test classes where possible.

When nearly completed we'd hook up to the JSP front end.
We guessed that testing & debugging via the browser was at least 3
times slower than via a Swing GUI (& also much more frustrating). 

This reduced the number of skilled server side developers required. 

Also reduced the number of changes that involved both JSP & server
side code.

Office staff preferred to use an App than to type data into HTML
forms so having both types of interface was valuable. 
The Swing GUI's were designed to plug into applets in the hope they'd
be resurrected.

I'd do it like this again for any development where there is
significant complexity in the business logic. It's probably overkill
if you are just putting data from forms onto a database.

Does any-one know how long HTML forms will be used for?. Will Applets
or JNLP (Java Network Load Program) allow us to replace them with
Swing? If HTML forms life is limited it becomes very important to
layer your design to isolate the dependance on them.

Good layered design (called 'weak class coupling') makes a system
faster & easier to test, it then gets tested better. Subsequent
enhancements are easier & better quality.

We were writing code to last for 3 years or more, shame we went bust
instead!

Keith.


--- Ted Husted <hu...@apache.org> wrote:
> Fiona Thorne wrote:
> > 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".
> 
> I think the day I became a true believer in layered applications
> was
> when I realized that it's much simplier to test components when
> they are
> not wired directly to HTTP. If I have an object that just takes
> plain
> parameters, it's easy to write unit tests for that. If it takes a
> request or another complex structure, and parses that itself, then
> testing it is much harder. This sometimes means you have two
> objects
> where one ~could~ have worked as well, but with layers you can test
> and
> troubleshoot each part seperately. 
> 
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/about/struts/


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: Kick start to Struts

[Ted Husted <hu...@apache.org>]

Fiona Thorne wrote:
> 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".

I think the day I became a true believer in layered applications was
when I realized that it's much simplier to test components when they are
not wired directly to HTTP. If I have an object that just takes plain
parameters, it's easy to write unit tests for that. If it takes a
request or another complex structure, and parses that itself, then
testing it is much harder. This sometimes means you have two objects
where one ~could~ have worked as well, but with layers you can test and
troubleshoot each part seperately. 

-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/about/struts/

Re: Kick start to Struts

[Fiona Thorne <ft...@comdyn.com.au>]

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