Re: Recommendations for a web application framework?
- From: Chris Smith <cdsmith@xxxxxxx>
- Date: Sat, 8 Jul 2006 10:21:38 -0600
Timo Stamm <timo.stamm@xxxxxxxx> wrote:
In a different form, it's also the Wicket example you posted, which has
two id attributes in the page corresponding to the two components; and
then a Java class representing that page, which again has to match the
id attributes on components on the page. It's a little better than
Struts, to be sure. Yet I still see this duality wherein there's a Java
class representing the form.
Unfortunately, you can not eliminate this duality if you want to use
HTML templates and insert a value into a specific position in the template.
I think it is avoidable, and I think JSF does it.
To be perhaps a little clearer, what JSF does is ensure that the
correspondence between identifiers and names in Java code and HTML
content is one-way. That eliminates the really painful bit, which is to
try and keep stuff in sync. I can actually write a JSF backing bean
that encapsulates what I need to know in order to perform some task...
and I really don't care whether the user interface gathers that
information (a) with one component or another; (b) with a single HTML
page or in a wizard-style interface across several pages; etc. Instead,
I create and publish my interface in the form of a backing bean, and
then the web design can be done along those lines. Those changes to the
user interface part of the application are performed simply by binding
different JSF components to different backing bean properties. The
backing beans only need to be changed if there's a real change, such as
the need to enter additional information that the application doesn't
know how to handle yet.
But with wicket, you could encapsulate the two components for the link
and the output label into one component and you can use language
features like inheritance to remove redundancy (yes, it works with HTML
templates too because a HTML file is always associated with a java class).
It's exactly that -- an HTML file is always associated with a Java class
-- that bothers me. I think that's a serious problem. My Java code
shouldn't care what HTML files exist in the application.
This is a major problem with JSF to me: You have to define a lot of
classes and XML configuration files.
Hmm? In addition to the web application deployment descriptor, you have
to add one XML file. I don't like XML for configuration too awfully
much, but the actual information in that file is quite meaningful. It
consists mainly of the navigation scheme between pages, and the model of
information that is available to the pages. I actually wish these were
in different files, since they express facts that are useful in
different parts of the development process; but I imagine that didn't
happen in order to avoid the issue of too many configuration files. In
any case, you can still do things that way manually.
As for classes, I'm willing to wager that there are fewer classes
involved in a JSF implementation of something that with anything that
requires a Java class dual for each
Are you referring to the need to declare backing beans in
faces-config.xml? That would be the key to avoiding the need for the
class per web page model, in that it allows the view layer to access
whatever data it needs based on declared interfaces; and conversely, the
model layer to look in well-defined places for information regardless of
what HTML page it came from.
The example I gave requires one additional class to represent the
Application and one entry in the deployment descriptor to get it
running. An implementation in JSF would probably require at least twice
as many files.
It would require:
1. WEB-INF/web.xml
2. WEB-INF/faces-config.xml
3. counter.jsp
4. WEB-INF/classes/.../CounterBean.java
Furthermore, none of these are really all that involved. web.xml would
contain a mapping for the faces servlet, and possibly some configuration
if you want to change the defaults. faces-config.xml would contain one
navigation rule and one backing bean declaration for CounterBean. The
counter.jsp file would contain the view code, and would bind the
components to CounterBean via EL expressions. Finally, CounterBean
would contain one method to increment the counter variable, and another
to get the counter variable for display.
(The way I typically write JSF code, there would also be an index.jsp
that just contains a single <jsp:forward> action. That's not necessary,
but if it weren't there, you'd need to modify web.xml to change the
welcome file list so that it loads "counter.jsf" by default.)
Was that before JSF 1.2? As far as I understand, the "Avatar" Extension
should make AJAX (forgive me using the buzzword) easier.
It was prior to JSF 1.2. I haven't looked into JSF 1.2 yet, though it's
on my list of things to do this weekend.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
.
- Follow-Ups:
- Re: Recommendations for a web application framework?
- From: Timo Stamm
- Re: Recommendations for a web application framework?
- References:
- Recommendations for a web application framework?
- From: Alan Meyer
- Re: Recommendations for a web application framework?
- From: David Segall
- Re: Recommendations for a web application framework?
- From: Alan Meyer
- Re: Recommendations for a web application framework?
- From: Chris Smith
- Re: Recommendations for a web application framework?
- From: Timo Stamm
- Re: Recommendations for a web application framework?
- From: Chris Smith
- Re: Recommendations for a web application framework?
- From: Timo Stamm
- Recommendations for a web application framework?
- Prev by Date: Re: How to find the JVM options for the Java
- Next by Date: Maven: Parse error reading POM. Reason: parser must be on START_TAG or TEXT
- Previous by thread: Re: Recommendations for a web application framework?
- Next by thread: Re: Recommendations for a web application framework?
- Index(es):
Relevant Pages
|