Re: Which do I use for web design?
- From: "Arved Sandstrom" <asandstrom@xxxxxxxxxxxxx>
- Date: Sat, 07 Jun 2008 14:02:11 GMT
"Lew" <conrad@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A92dneCoV5QU8drVnZ2dnUVZ_sKdnZ2d@xxxxxxxxxxxxxx
Arne Vajhøj wrote:
It is significant easier to write JSP pages than servlets.
JSPs are approximately as hard to write as HTML.
JSF is slightly harder, mitigated by the presence of decent visual tools.
Even with a text editor JSF isn't overly hard for what it offers, though I
admit getting into the mindset of it took me a while. FWIW, the key was a
now-lost link that advised to think of JSF as similar to Swing.
JSP and JSF make a nice staged learning ramp. Get comfy with JSP first.
Normal form widgets like <input type="text".../> are just fine for a broad
category of web apps. Then take your time to assimilate JSF, starting
with the easiest stuff first. Then dive into richer frameworks built atop
JSF, like Tomahawk and Tobago.
Luckily for us these technologies dovetail well that way.
<http://myfaces.apache.org/tomahawk/index.html>
<http://myfaces.apache.org/tobago/index.html>
<http://myfaces.apache.org/>
--
Lew
Good post (not to mention some of your others, plus Arne's). To someone who
is a bit overwhelmed by everything out there (like the OP, and like I have
been myself from time to time), I usually suggest taking the time (and it
really doesn't take that long) to design and code a best practices MVC
servlet/JSP/beans web app: servlet as controller, JSPs as view, and beans
for the model. Pretty much bare metal, and it provides the grounding for
understanding what frameworks will do for you. Let's call this Stage A.
The next stages that you mention are also ones that I would agree with.
Although any of a number of different frameworks could also be championed.
The key is to keep in touch with what the framework is doing for you that
originally you did in Stage A.
As you point out, there's typically Stage B, which is the initial framework
that replaces Stage A (you coding everything). And then there's Stage C,
which typically involves enriching the UI somehow - maybe better widgets,
maybe AJAX, maybe both.
These are all front end elaborations, really. Getting fancier with the
backend (the model), with ORMs and/or EJBs etc, is another matter. Similar
process, though. For a simple app you can get away with well-designed but
essentially hand-coded DB access...later on you'll also see that having
something else take care of that for you is nice.
Main thing though, it is very easy to lose sight of exactly what it is these
things do for you. I sympathize with the OP.
I was sort of lucky in this regard (your perspective may differ). I may date
myself, but I was already well into a second decade of programming before
HTML and Mosaic and Lynx ever showed up. CGI shortly followed. There were
obviously best practices back then, but often loosely observed. My first
exposure to J2EE was precisely of the kind I describe as Stage A - the main
reason being, it was J2EE 1.2 back on 1999-2000, and we had no choice. We
had EJB 1.1 session beans and BMP entity beans, Servlet 2.2, JSP 1.1...the
app had to deliver WML/HDML content to cellphones and HTML to browsers, so
we also used XML/XSLT, and ended up coding our own custom JSP tags for the
latter. By some incredible stroke of good luck our smallish developer team
(about half a dozen at the start in '99) was just overloaded with guys that
had reams of industry experience (*), and although MVC was new to us, it
just seemed "right". Actually, in 1999 almost everything I describe, Java
included, was more or less "new".
God knows the J2EE app servers were...we spent about three months with
Netscape trying to debug a fundamental bug that they had in iPlanet related
to primary key classes. What saved our bacon on this front was that we
discovered Evermind's Orion J2EE server (for a 2000 blurb see
http://www.serverwatch.com/sreviews/article.php/1376021), which was then
(and for a long time afterwards) a developer's first choice for J2EE. IMHO.
I would never again want to do that much work for what these days would be
classified as a small/medium enterprise application. But I never regret
having had to do it. Because now I know what all these frameworks and IDEs
are doing to save my time.
AHS
.
- Follow-Ups:
- Re: Which do I use for web design?
- From: jmDesktop
- Re: Which do I use for web design?
- References:
- Which do I use for web design?
- From: jmDesktop
- Re: Which do I use for web design?
- From: Roedy Green
- Re: Which do I use for web design?
- From: Arne Vajhøj
- Re: Which do I use for web design?
- From: Roedy Green
- Re: Which do I use for web design?
- From: Arne Vajhøj
- Re: Which do I use for web design?
- From: Lew
- Which do I use for web design?
- Prev by Date: Re: Natural logarithm method not recognised
- Next by Date: Re: Creating a shape from a set of points
- Previous by thread: Re: Which do I use for web design?
- Next by thread: Re: Which do I use for web design?
- Index(es):
Relevant Pages
|
|
