> On the other hand, one of the stated aims of JSP was to separate
> presentation from content, in order to allow HTML people
> (non-programmers by assumption) to do the presentation while
> the programmers create the content.
hm, did I miss this in the spec???? Maybe I should read it again....
<sly grin>
> we find the content horribly intermingled with the presentation
> again. Two roles have to collaborate to produce this particular
> JSP code - a programmer who can write correct scriptlets, and an
> HTML designer who develops the HTML presentation code. Ugh!!!
Well, no. this _can_ be done by one person - and in my case, it
generally
is, with the input of a graphic designer. If you are doing
web stuff with a programmer who can't write basic HTML, get rid of
him/her,
ditto a HTML person who can't write around scripts.
the method I have found best - admitedly using ASP, but its just
as applicable to JSP - is for the programmer to write the code and a
vanilla version of the HTML - then, when thats mostly done, the designer
takes a bunch of screen shots, and does the GFX in photoshop. This,
however,
REQUIRES an HTML-savvy graphic designer, as well as a developer who
can string together basic HTML, which is, IMO, trivial. Then, the
_programmer_
codes the HTML and integrates it with the scripting, based on pixel
measurements from the photoshop files.
Being the programmer in this case, I've done it on about 4 occasions in
the
last 18 months, and others at the place I worked at did the same also
(www.look.co.nz, www.listener.co.nz, shop.renaissance.co.nz,
www.biolab.co.nz, plus a bunch of internal stuff for banks, liquor
manifacturers, etc)
> This is a major step backwards. Separation of these roles is
> rather crucial if you have a significant size of project or of
> project team. Standard software development management practice
Depends on what you call large. The size of app I deal with usually
takes
4-9 months to develop, and has 20-30 distinct pages. Anything much
bigger
and the business requirement ceases to exist.
> will tell you to reduce these sorts of interactions amongst team
> members where possible rather than mandate them. It also mandates
> that you break the entire development task up into units which can
> be completed by people with differing skill sets and levels. The
> code above does not enable that partition.
... and the standard method of software development doesn't really apply
to
web development, which is, IMO, about 90% of the problem that people
have
dealing with it - its NOT client/server, and its not inherrintly
state-based,
so you have to develop in a totally different way. Its also very visual,
tho with massive limitations (please, someone kill IE and netscape
3.0!!!)_
> Ugh. That again intermingles the roles, and takes away a large chunk
> of the value proposition of JSP, but perhaps not as badly as the
> previous example. Some programmer builds a bean to write HTML output.
> Then you teach your HTML developer to not use the HTML they are already
> familiar with, but to use the pre-programmed functionality in another bean.
> I can't imagine they're going to like that too much, especially when they
> have less control over the bean (and any bugs it has) compared to doing it
> in HTML themselves.
IMO:
1) Beans should NEVER output HTML, unless they are HTML-specific beans,
eg,
ones with static final methods that, say, generate a month and year
drop down, mostly to just save time.
2) The HTML should be written by whoever is writing the page, being they
have
the specific knowledge of the page. If a grafic design person is needed,
bring
them in as a 'consultant', but not to actually write the code.
Just IMO. As I said, I've done a few of these, and it works for _me_.
YMMV.
Nic.
Inprise New Zealand Ltd.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
