Dave wrote:
I decided to try something new and develop the simple and small standalone
Planet Roller UI with JSF and specifically the Apache MyFaces
implementation.
It took the better part of a weekend to work through the learning curve and
I'm happy with the results, but since I did this on my own without
discussion,
let me explain my reasoning and my experience, starting with the first
question
that probably comes to mind.
I hope to convince you to not object to keeping Planet's JSF UI in
place and to consider what comes next for the Roller web UI.
Thanks for sending this out. I had just seen your commit a few minutes
ago and was going to ask about this.
Why not just use Struts 1.x?
I'm tired of Struts and the cumbersome way we use Struts in Roller.
For example, this is what's involved in one form:
- Markup POJOs with XDoclet so we can generate form bean class
- Extend form bean to add extra fields, override copyTo and copyFrom logic
- Create page model object to make data available to JSP page
- Create Tiles configs for new page and action
- Create global forwards for action and pages in XDoclet merge file
- Create Struts dispatch action class to handle GET and POST of form
- Markup Struts action so XDoclet can generate struts-config.xml
The result is too many classes, too much boiler-plate code and too many
moving parts. It's slowing us down. Plus, lots has changed in the world of
Java web development since I started working on Roller in 2001 -- I
wanted to
try learn and try something new.
I'm not sure all of those issues can be blamed on Struts 1.x itself. I
think some of the XDoclet stuff and the way we try and use our own page
model class are Roller specific issues, but I agree with your sentiment.
I have been grumbling about the way Roller uses struts for a long
time, so I have no problem with moving past our current Struts 1.x stuff.
But why try JSF?
I'm not trying JSF because Sun told me too -- in fact, I still haven't
told my
manager which UI tech I'm using in Planet Roller (hi Rama). I like what I
learned about JSF from Geary and Horstmann's book and I like the momentum.
It's the most hyped web framework, as Raible says [1], but that's
actually a
side-effect of a very good thing -- its part of Java EE 5 and all the
major Java
vendors are developing and marketing tools to support it including
JBoss/Red Hat, IBM, Oracle and of course Sun. Plus, we've got MyFaces,
a complete JSF implementation right here at Apache [3].
The fact that JSF is component based is a plus in my mind and I think we're
going to see lots of component development, see for example ADF Faces [2]
(now at Apache), and JMaki [4], which brings AJAX components to the world
of JSF.
Following are some notes about my experiences with JSF in Planet Roller.
What I like about JSF
- Less code! Take a look at the new form classes under the package
org.apache.roller.planet.ui.forms.
- No need for the three form, action and page model classes we normally
create
for a Roller JSP page. Compare the new JSF form classes with the old
Struts
Actions for Planet in org.apache.roller.ui.admin.struts.actions.
- No need for XDoclet form generation. Personally, I'd like to eliminate
XDoclet from Roller -- or at least from the web tier. I think it creates
more problems than it solves. And, no more need for the weird form-bean
based
save() logic on HibernatePersistenceStrategy.
- Validation is simple and very easy to extend. We don't make much use of
Struts validation in Roller, in part because it was too complex for my
taste.
But I found it very easy to add custom validation logic to JSF.
Problems encountered with JSF
- Everything is a POST -- serious RESTafarian buzzkill. I was able to
work around this problem by using a simple little filter for GET requests,
one which loads objects based on request information.
- Bugs, e.g. the pesky commandLink in datatable problem that won't go away.
I've been able to work around this problem with a little JavaScript.
- Problems mixing JSF and JSTL tags. Care is required. I've been able to
use JSTL for simple conditional logic, but not much more.
I don't have any experience with JSF so I couldn't really comment on any
of that, but I'd be surprised if it wasn't at least a little bit of an
improvement over Struts 1.x.
I did look at the new forms stuff as you suggested and the
LoadableFormsFilter definitely looks hacky to me :( I can't say that I
fully understand the problem, but it sounds like you already had to work
around an unfortunate limitation in the JSF architecture.
I'm also not particularly encouraged about having to work around
problems using javascript and having to abandon jstl in favor of a pure
jsf taglibrary, but that's not such a big deal.
But JSF sucks!
There is a pretty strong JSF sucks contingent, at least inside the
blogopshere
echo-chamber in which I live. Let's talk about that. A common criticism
of JSF
is that it's too complex because it is designed to support the needs of
IDEs
and not hand-coders. That was not my experience. I found JSF very simple
and easy to use -- less code and less config than I'm used to.
One of the critics of JSF is our own Matt Raible. Matt is on the JSF expert
group and has experience with what he calls the top five Java web
frameworks.
His pick for the best web framework is WebWork, which is the foundation for
Struts 2 AKA "Struts Action" -- just released this week [5] by the way.
Struts Action is still an action framework, and personally I prefer
components -- and the growing number of JSF components, but because JSF is
compatible with Struts Action, you can mix them both in one application.
This gives you the best of both worlds, as Don says [6]:
"You can use a page with JSF components and have complete access
to the JSF lifecycle. This even supports JSF components that post
back to themselves or add PhaseListeners to provide advanced AJAX
support. No more "everything is a POST", and even faces-config.xml isn't
required since the Action instance is available to the JSF EL bindings."
"The bottom line is Struts Action 2 proves it is possible for the
action-based and component-based frameworks to work together, and
application developers no longer have to choose one or the other
exclusively. They can make the decision on a page-to-page basis
according to its particular requirements. Enough of these
"web framework wars", and let's move on to more interesting problems.
:)"
I especially like the "No more 'everything is a POST'" part.
So, by using JSF we can benefit from component-based framework with strong
momemtum and industry support and, if we need it, we still have the option
of using Struts Action for things not well suited to JSF.
Have I convinced anybody? Does anybody object to keeping JSF and MyFaces
in the
Planet Roller webapp?
If I had to vote I would just be a +0 because I don't have experience
comparing all the various web frameworks and it doesn't really matter
that much to me anyways. It's fine with me if you want to keep it.
I do think it would be good to have more of a discussion about this
though, rather than just assuming that we are now going to migrate
everything to JSF over time. I would definitely like to see more info
around why (and others) think JSF is better than SAF 2 or other options.
-- Allen
- Dave
PS. I added some screenshots of the UI to the proposal page on the wiki:
<http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_Modular_Planet>
References
[1] RE: What Web Application framework should you use?
http://raibledesigns.com/page/rd?entry=re_what_web_application_framework
[2] ADF Faces
http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/index.html
[3] Apache MyFaces JSF implementation
http://myfaces.apache.org/
[4] JMaki AJAX components
http://ajax.dev.java.net/
[5] Struts 2.0.0 Available
http://jroller.com/page/TedHusted?entry=struts_2_0_0_available
[6] Unification: Struts Action and JSF
http://jroller.com/page/mrdon?entry=unification_struts_action_and_jsf
