Which do I use for web design?

[Roedy Green]

JSP is not a template engine.

And JSP is standardized.

It is the official way to translate mangled HTML to Java source
code. . It has the same bailing wire syntax style as all the others.
Why don't you call it a template engine?

 

[Arne Vajhøj]

It is the official way to translate mangled HTML to Java source
code. . It has the same bailing wire syntax style as all the others.
Why don't you call it a template engine?

Because a template is fundamentally build on the concept that you have:
- a template with placeholders
- a list of dynamic replacements
and by replacing the placeholders you get the output.

If you only use <%=xxx%> in JSP then it is a template.

But JSP is more than that. Large <% %> blocks are not
a template. And taglibs are not a template.

It is not completely black and white. Some template engines
has developed features that are very code like as well
(Velocity is pretty advanced).

But they are still fundamentally based on a text replacement
model, where JSP is based on a code generation model.

Arne

 

[Roedy Green]

Because a template is fundamentally build on the concept that you have:
- a template with placeholders
- a list of dynamic replacements
and by replacing the placeholders you get the output.

I see. I have been using the term "template engine" incorrectly. I
used to it mean anything that worked with HTML with embedded commands.

 

[Roedy Green]

Because a template is fundamentally build on the concept that you have:
- a template with placeholders
- a list of dynamic replacements
and by replacing the placeholders you get the output.

what is the difference between a framework and a template engine?

 

[Arne Vajhøj]

I see. I have been using the term "template engine" incorrectly. I
used to it mean anything that worked with HTML with embedded commands.

The line is not razor sharp between them, but in I will still
put JSP, ASP and PHP as not being template engines and
Velocity, Smarty and XSLT as being template engines.

http://en.wikipedia.org/wiki/Template_engine_(web) has
a definition similar:
http://en.wikipedia.org/wiki/Template_engine_(web)#Typical_Features
http://en.wikipedia.org/wiki/Template_engine_(web)#Benefits_of_using_template_engines
but then goes on to call JSP, ASP and PHP for template engines.

Arne

 

[Arne Vajhøj]

what is the difference between a framework and a template engine?

A framework is a reusable bundle of some software and some guidelines on
how to use that software.

A template engine can be a framework if it packaged well to
be reusable.

But you can also have persistence frameworks, test frameworks
etc. that are not in any way related to template engines.

Arne

 

[Mark Space]

what is the difference between a framework and a template engine?

A framework doesn't necessarily have anything to do with templates.
Swing is a framework, imo.

I'd say a template engine is probably a component of a web framework or
even just an web View framework. (View as in MVC.) A template engine by
itself would be a rather skimpy framework.

 

[Arved Sandstrom]

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/>

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

 

[mich]

If you were starting a web project from scratch, which technology
would you use? I have looked at various. I saw "regular" jsp
scriplets, servlets emitting html, JavaBeans, JSTL, EL, JSF, and then
frameworks (or is JSF a framework?)

Outside of using frameworks, what would you use? It is a webpage that
could develop into a homemade CMS. Probably use MySQL to store
account information.

I've been thinking about it and I can't bring myself to use any
embedded code like PHP, Classic ASP or older JSP constructs, or
emitted HTML. So, it appears that I would use JavaBeans, servlets to
talk to those JavaBeans and HTML files that have EL in them.

Is this a "good" way to do things? Or should I try JSF which seems
very popular.

I digress, but the security aspect of it seems like something that is
missing from many of the frameworks I have seen and nothing in JSP
like ASP.NET has, which is why I mention the MySQL above.

Thank you.

The problem with all these frameworks is that the day you need to get out
of a using a framework can be a great big headache ...

 

[jmDesktop]

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 seehttp://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- Hide quoted text -

- Show quoted text -

Thanks. What I have discovered over the past several years is that I
really am not as experienced as I thought and that frameworks and
IDEs, in a way, have made me dumb. In my quest to find the answer to
web programming I found that unless you have a framework, then
regardless of language everything is about the same. Looking back at
all my ASP.NET programming and skipping that it was a framework, I
thought I knew what I was doing. That framework made me productive,
but it made me not really understand also. Visual Studio, a great
tool, also shielded me from much. And, I didn't even know it. I
thought I had arrived from my Classic ASP.

Later on I start discovering other frameworks and using other
languages. What I noticed was that every time I sat down to write a
web app it was always the same. It was just like classic ASP
(vbscript and javascript), C, Perl, and later on Python, Java (JSP, or
servlets.) I had my mix of code and html all right there together,
just as ugly as you can find anywhere. And today, if I started
something, this what I'd have. Code and presentation all mixed
together. Just the other day I thought I'd write a web app in Python
and noticed immediately what is obvious to many people.

If I did this type coding long enough, you'd think I'd change, but I
didn't until ASP.NET when I was actually exposed to some separation of
layers. Without the tools, however, I was back to the old. My point
is that what I now know is I either pick a framework, write my own
framework, or I am stuck with the mixture of layers.

I also understand why the frameworks were created and I admire the
folks from all the languages that wrote them. They are the ones that
really understand what's going on. I think I do too now, but am
woefully inept to even begin to create an MVC framework.

 

[Arved Sandstrom]

jmDesktop wrote:

[ SNIP my own, and some of poster's ]

If I did this type coding long enough, you'd think I'd change, but I
didn't until ASP.NET when I was actually exposed to some separation of
layers. Without the tools, however, I was back to the old. My point
is that what I now know is I either pick a framework, write my own
framework, or I am stuck with the mixture of layers.

Let's say that all you need to write are small and relatively simple web
apps. For Java, your own "framework" may simply be a re-useable controller
servlet, an event handler base class, some of the core event handlers, and
some of the core JSPs. You could also regard the JSTL as part of your
framework. If your simple web apps access databases, part of _your_
framework (in the Model part) would also be a skeleton data access object
(DAO) system (see
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html) -
this could be quite simple, potentially to the point of targeting a single
RDBMS.

IMO it's a good exercise to create a skeleton framework like this. Number
one, you can actually develop with it. Number two, it exposes you to the
concepts at the lowest level. Number three, when you start using other
frameworks, you'll know that fundamentally that that bit is replacing your
Views, that other bit is replacing your Controller, and that other stuff is
doing what your Model does.

It also doesn't hurt to tackle each new framework at a very simple level.
Choose one of the basic tutorials, and dissect it. Identify the Model, View
and Controller. Next, implement one of your own simpler applications.

You can absolutely get overwhelmed by using a high-powered IDE that has
support for various technologies. Dive into a J2EE app using Netbeans, and
in an hour or so you can have a working app that set up entity classes
mapped to a DB, it created a session facade bean for you, it created all
the stuff for a few JSF web pages, and at the end of that you're not
necessarily much the wiser about anything that's going on. IOW, and again
this is just my opinion, I wouldn't recommend starting this way.

I also understand why the frameworks were created and I admire the
folks from all the languages that wrote them. They are the ones that
really understand what's going on. I think I do too now, but am
woefully inept to even begin to create an MVC framework.

With regards to the latter, still a good article is
http://www.stardeveloper.com/articles/display.html?article=2001060501&page=1

This is an MVC2 example. Page 6 will mention the limitations of this
example: no support for forms handling or internationalization, not a
particularly complex user interface (one event, one handler), and some
scriptlet code still in JSP. Also, the state components of the model are
very simple. Because the limitations _are_ mentioned in the article you're
not left in the dark about actual real-life improvements that would be made
(that is, what frameworks will do).

Also, if you haven't already done so, read (at a minimum)
http://java.sun.com/blueprints/guid...rprise_applications_2e/web-tier/web-tier.html
from "Designing Enterprise Applications with J2EE". That link points to a
discussion of the web tier.

Note that with enough care you can make this work with any language. For
example, see http://www.tonymarston.net/php-mysql/infrastructure.html#mvc
It's not a bad idea to read up on MVC done in other environments - it
highlights the principles.

This should get you started.

AHS

 

[Neil Coffey]

Try not to become dogmatic. Emitting HTML from servlets is not a bad
thing, in fact all frameworks use servlets to emit HTML. Writing
application level code that use print-like commands to generate HTML,
however, is bad and you should stay away from that.

Thank goodness! I was beginning to think I was alone in this universe
of "if it doesn't use 10 black boxes with spurious initials it's not
a real application".

As Silvio says, you really *can* just write a plain boring old servlet
that reads in the parameters from the request and spits out some HTML.
If you need to persist some data to the database, you really can just
use a plain boring old JDBC connection. If you need to pool your
connections, you really can just write some code to do that in exactly
the way you want. If you need to cache data from the database, you
really can just write some code to cache in the way that you want (yes,
even just 'bang it in a hash map' if that serves your purpose...).
If you need to separate out the static and dynamic content of your
page, you really can just write a bit of code to read in a text file,
run a regular expression over it and replace bits accordingly. None of
these things were ever such difficult problems in most cases, but
for each of them you'll find a plethora of "frameworks" to do them
in profoundly convoluted and inflexible ways (though possibly with
various extra features you never even dreamt of needing).

For each "framework" that I consider using, I always ask myself
things such as:

- how difficult is the "problem" that framework solves?
- do I need to solve that problem?
- is it easier and quicker for me to write my own code to solve
the problem than to understand and implement the framework?
- if it's sloewr for me to write my own code, is that ofset by
the extra flexibility I'll get if I write my own? (It may take
me an extra 5 hours, but with the framework, I may waste more hours
later trying to find out things like 'how to turn on the XXX logging'
rather than just adding a single line to my own code.)
- how much of a "black box" is the framework? (Depending on your
situation, tens of thousands of lines of somebody else's C++ code,
open source or otherwise, may be a black box.)

After running through this kind of analysis and possibly knocking up
a few tests, I've personally ended up ditching all sorts of the
'industry standards with silly initials' because it's quicker and more
flexible for me to just write my own "framework" to solve the problem.
A notable exception is probably going to be GWT, because for me
personally, doing anything even remotely significant in Javascript
is a complete abomination. If for you personally, you simply cannot
figure out how to read in a text file and replace some bits of it
with dynamic content, then JSPs may be the way to go. Similarly,
if whacking some variables from an object into a PreparedStatement and
executing it is a major upheaval for you, then a "persistence framework"
may be appropriate...

Neil

 

[Arne Vajhøj]

The problem with all these frameworks is that the day you need to get out
of a using a framework can be a great big headache ...

That argument can be used against practically everything from
compilers to databases.

If one choose a framework that seems likely to be around
for many years, then the framework will not abandon you - you
may abandon the framework, but that is a choice.

Arne

 

[Arne Vajhøj]

Thank goodness! I was beginning to think I was alone in this universe
of "if it doesn't use 10 black boxes with spurious initials it's not
a real application".

As Silvio says, you really *can* just write a plain boring old servlet
that reads in the parameters from the request and spits out some HTML.
If you need to persist some data to the database, you really can just
use a plain boring old JDBC connection. If you need to pool your
connections, you really can just write some code to do that in exactly
the way you want. If you need to cache data from the database, you
really can just write some code to cache in the way that you want (yes,
even just 'bang it in a hash map' if that serves your purpose...).
If you need to separate out the static and dynamic content of your
page, you really can just write a bit of code to read in a text file,
run a regular expression over it and replace bits accordingly. None of
these things were ever such difficult problems in most cases, but
for each of them you'll find a plethora of "frameworks" to do them
in profoundly convoluted and inflexible ways (though possibly with
various extra features you never even dreamt of needing).

For each "framework" that I consider using, I always ask myself
things such as:

- how difficult is the "problem" that framework solves?
- do I need to solve that problem?
- is it easier and quicker for me to write my own code to solve
the problem than to understand and implement the framework?
- if it's sloewr for me to write my own code, is that ofset by
the extra flexibility I'll get if I write my own? (It may take
me an extra 5 hours, but with the framework, I may waste more hours
later trying to find out things like 'how to turn on the XXX logging'
rather than just adding a single line to my own code.)
- how much of a "black box" is the framework? (Depending on your
situation, tens of thousands of lines of somebody else's C++ code,
open source or otherwise, may be a black box.)

After running through this kind of analysis and possibly knocking up
a few tests, I've personally ended up ditching all sorts of the
'industry standards with silly initials' because it's quicker and more
flexible for me to just write my own "framework" to solve the problem.
A notable exception is probably going to be GWT, because for me
personally, doing anything even remotely significant in Javascript
is a complete abomination. If for you personally, you simply cannot
figure out how to read in a text file and replace some bits of it
with dynamic content, then JSPs may be the way to go. Similarly,
if whacking some variables from an object into a PreparedStatement and
executing it is a major upheaval for you, then a "persistence framework"
may be appropriate...

I think this is very bad advice.

It is usually rather easy to write code that does the needed
functionality of a framework.

But there are some major problems:
- that custom solution will contain bugs that cost money to find and
fix - the first versions of the frameworks also contained lots of
bugs, but they have (hopefully) been found and fixed
- that custom solution will be a nightmare for the maintenance
programmers and cost a fortune over the life of the application - a
custom solution does not come with the same level of documentation as
good framework - and the maintenance programmer may have experience
with a good framework, but not with a custom solution

Writing your own mini frameworks is something that is great for
hobby programming. It does not belong in work programming.

Arne