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