Raible Designs

[TSSJS] Java Web Frameworks Sweet Spots BOF

I've finished composing my "Java Web Framework Sweet Spots" document and presentation for tonight's BOF at TSSJS. Unfortunately, the BOF is at 6:30 and Crazy Bob's wedding is at 6. So I won't be able to make it to the wedding, but I do hope to have a toast to Bob and his new bride. I have been successful in securing beer for the BOF, so you'd better get their early if you want a free one. Caesar's doesn't have kegs, so it's $6/beer and we've purchased 100 of them for attendees. After that, it turns into a cash bar. Thanks to Virtuas, Codehaus, SourceBeat and yours truly for pitching in for the free booze.

My presentation tonight will be short and sweet. Rather than going through each framework author's responses, I'm just going to highlight their "sweet spot" responses. This allows me to get away with creating a measly 8-page presentation, as well as have a more interactive session. I've taken everyone's responses to the 6 questions I asked, and compiled them in a document. This document is available on the Virtuas site, just click on the link below to download it.

» View Java Web Framework Sweet Spots

Posted in Java at Mar 24 2006, 05:27:24 PM MST 28 Comments

Comments:

Matt, haven't read the document yet, but will, soon, and really look forward to it. Thanks a lot for the initiative! It will help clear the jungle around the frameworks.

Mats

Posted by Mats Henricson on March 25, 2006 at 02:54 AM MST #

I read over it once, nice document. The funniest part is Patrick Lightbody making comments about RIFE in terms of the implementation and coding style, particularly that class member variables in the private API are prefixes with "m". I was scratching my head for a little while to look for the relevance there.

Posted by Geert Bevin on March 25, 2006 at 11:56 AM MST #

Geert, haha, I was waiting for you to read that. Haven't you seen me complain about it in #codehaus? Come on, we've got IDEs now - they like color code things for you now :)

Posted by Patrick Lightbody on March 25, 2006 at 12:52 PM MST #

Patrick's part in general is funny, Geert. Despite his claim, I have never said Spring Web Flow (SWF) supports "any framework".

The facts:

SWF is a self-contained controller engine that *can* run in any environment; it is currently supported in Servlet, Portlet, and JUnit environments.
We currently integrate SWF into Struts, Spring MVC, and JSF where it can fullfill the role of the controller implementation as needed. It adds the most value for orchestrating stateful, controlled navigations that execute business tasks (typically business goals transactional in nature: think applying for a loan, booking a flight, paying your taxes).
A WebWork user has contributed a prototype integration piece between WW and SWF, available in our JIRA system.
We have a few clients using SWF and Tapestry together. </>

SWF is not concerned with response rendering, UI components, or anything like that. Nor does it make assumptions responses are always "whole pages" instead of zone updates via div or tabs. SWF is a dedicated controller engine that returns *logical* response instructions; a task execution engine with a well-defined interface for use. And it is highly object-oriented.

As for Patrick's "nuts" comment about our XML-based flow definition language, well... everyone is entitled to their opinion. Review the SWF 1.0 EA samples and you will find the flow definitions extremely readable; one place to go to manage all controller logic related to a logical user task with a linear progression.

Posted by Keith Donald on March 25, 2006 at 01:31 PM MST #

I wasn't able to attend, what was the audience's general response? :-)

Posted by Jacob on March 25, 2006 at 02:01 PM MST #

Jacob was informative, Patrick was refreshinly honest, Don was quite diplomatic, Spring guys' PR assault was higher than Sears Tower even when asked questions about other frameworks, Tim was rather direct, Eelco tastefully mixed bluntness of Tim and PR approach of Spring guys. Overall, not a bad read.

Posted by Michael Jouravlev on March 25, 2006 at 04:31 PM MST #

Patrick, honestly, I'm a total IDE dude. However, I personally prefer to have clear nomenclature for the naming of variables related to scoping. I found that it makes code a lot easier to read and prevents a lot of potential bugs in case the same name is used within different scopes. That's just me and my preference. Besides, code is not only read in IDEs, I often look over diffs in regular files, read source code parts from Subversion, etc etc. Maybe you don't like the "m" prefix, I can totally understand it, I personally think that prefixing with "this." is totally silly.

Posted by Geert Bevin on March 25, 2006 at 08:41 PM MST #

There's nothing wrong with a little bit of clear member delineation. Plenty of other projects do the same thing. Ie _members or m_members...There certainly is a lot more to compare in our frameworks than syntatical preferences I hope :)

Posted by Jesse Kuhnert on March 26, 2006 at 06:57 AM MST #

Geert,

Heh - I know, I'm just giving you a hard time. We can debate whether braces should be on newlines or not next time we chat :)

Posted by Patrick Lightbody on March 26, 2006 at 09:44 AM MST #

Geert, if you are such a IDE dude, I have to suggest something like this for development. ;-)

If found Eelco's comments to be pretty interesting on JSF-- I can see how JSF could replicate Wicket pretty easily with a custom ViewHandler and Java artifacts to compose pages. With Tapestry, it looks like it is going for a more integrated stack (hivemind IoC vs. Spring), which will both attract users, but push others away.

Overall, it's my hope that in some future spec, we can take hints from the Struts 2.0 work and JSF's event management/lifecycle to produce a composable controller API and a separate component model which the controller agnostically operates on (at least with minimal contracts). Hopefully then, the spec would better accomodate both stateless/action and stateful component interaction together under one standard without requiring the model 2 paradigm and the development overhead involved.

Posted by Jacob on March 26, 2006 at 11:10 AM MST #

Jacob, I said that I was an IDE dude, not a visual drag & drop wysiwyg mumbo-jumbo dude ;-) Btw, even though Creator is impressive for that kind of development, its Netbeans foundation lacks a lot compared to IDEA and X-develop in terms of raw coding support.

Posted by Geert Bevin on March 26, 2006 at 03:33 PM MST #

Har har....But of course, why not copy another framework again? I don't know what you would call it this time though, Wicked? Maybe a big W in a circle would do it. Alright...back to my coding hole.

Posted by Jesse Kuhnert on March 26, 2006 at 06:41 PM MST #

heheh, well, tapestry copied from apple; and as others have pointed out, jsf is structually much different than tapestry and it looks like tapesrty is only moreover pigeon holing itself out of existance as jsf gains in popularity with being able to integrate/replicate features of other frameworks (as the pdf describes from other authors). as for the whole 'jsfc' or 'jwcid' or 'wicket:id', here's my personal take on the matter-- if that's what you were jabbing for.

Posted by Jacob on March 26, 2006 at 07:11 PM MST #

Re: 'I can see how JSF could replicate Wicket pretty easily with a custom ViewHandler and Java artifacts to compose pages.'

I challenged you before on TSS: take a look at our JSF interoperability feature request (filed by yours truly) and give us concrete pointers how we should 'easily' do this. Both Jonathan and I looked at it, and we are pretty much convinced that integrating JSF is not as trivial and non-intrusive as you suggest. JSF exposes a couple of 'life cycle' steps and contexts etc in a such a way that there is no way we can build integration while supporting the kind of encapsulation we want.

I don't want to across arrogant, but anyone making statements like that - or suggest that Wicket is a copy of Tapestry - don't get the point at all what Wicket is about. It's an UNMANAGED framework, meaning that it has an incompatible way of working with most frameworks, including JSF and Tapestry.

Posted by Eelco on March 26, 2006 at 07:38 PM MST #

Eelco, you can approach this two ways: from Wicket to JSF or JSF to Wicket. My comments around replicating some of the java-centric approaches within the JSF platform would involve the latter. For integrating JSF into other frameworks-- throw out the FacesServlet for one-- not needed, purely adaptor logic. So start at the FactoryFinder-- and find an instance of the FacesContextFactory and pass in your servlet/portlet artifacts to auto-magically get your JSF context for use with UIComponents. Of course, this isn't all-- the Lifecycle in JSF that you are referring to is purely spec, the signature on Lifecycle is: void execute(FacesContext) -- whatever you do in that invocation is up to you. As for the other Application composites around ViewHandlers/StateManagers/etc, you can override those too if you wanted. But in relation to the JSF lifecycle, once you have that FacesContext, you can have a JSF instance and simply invoke the processXXXX methods whenever it's ideal for your code or matches up with your custom lifecycle. Don't get me wrong, going from Wicket to JSF wouldn't be terribly easy, but hardly impossible.

Posted by Jacob on March 26, 2006 at 07:52 PM MST #

small correction, But in relation to the JSF lifecycle, once you have that FacesContext, you can have a UIComponent instance and simply invoke the processXXXX methods whenever it's ideal for your code or matches up with your custom lifecycle.

Posted by Jacob on March 26, 2006 at 07:59 PM MST #

Re: wicket:id. The difference with jwcid or whatever is that it is namespaced. Just as special tags like <wicket:panel> etc. There is no difference with a tag like <h:inputText> for that matter.

Furthermore, from your blog: just use the literal tags themselves, <h:inputText/> for example which literally represents what you are attempting to do within the context of the document.

What do you mean, 'literally represents what you are attempting to do?' Sending back a <input type="text"> tag to the client would be my attempt. As it happens, I would want to let that tag be dynamically modified so that it cooperates with my server side component tree. So I attach it to that tree by adding a wicket:id attribute wich corresponds to that tree. I like that conceptually better than having special tags that expand into something else at runtime.

And then there is this thing of previewability.

Let me point out that if you are creative, you can go a long way. Like this guy did (and which we integrated in our framework too). With that we are able to have previewability of templated pages and components without extra tooling support. And we're just starting on that.
The fact that you don't like/ can't work with Dreamweaver and comparable tools doesn't mean the rest of the world can't. I know quite a few people who are incredibly productive with it, and while the HTML it spits out is not always super, they can actually do a lot to keep it reasonable. Furthermore, as you and some others here really seem to think having seperate teams of programmers and designers are a fantasy, here is an interesting mail from one of Wicket's users.. And on top of that I can confirm that I worked with seperate designers (who used Dreamweaver, yes), and that it was pretty damn productive and enjoyable.
Having clean templates is not only about being able to use Dreamweaver and friends. For my own development, I couldn't care less about that. But I do like to keep those concerns seperated, and my HTML easily readable. I think it is very comparable with why it is better to seperate your style from the rest of your markup; just as I don't want to polute my markup structure with style elements, I don't want to polute my markup with any logic.

Posted by Eelco on March 26, 2006 at 08:18 PM MST #

Jacob,

I think it's funny that the momentum behind jsf keeps being touted as the primary reason why the framework is good, instead of an actual technical reason why the framework is good :) Maybe the giant turd that was ejb 1/2 gained a lot of momentum as well. Nonetheless both of them were exploded from my bowels with the same force that a healthy cup of coffee/sanity can bring.

Posted by Jesse Kuhnert on March 26, 2006 at 08:37 PM MST #

I agree with Jesse. Also, I think it is a misconception that the critique on JSF has anything to do with missing features.

Posted by Eelco on March 26, 2006 at 08:44 PM MST #

So I attach it to that tree by adding a wicket:id attribute wich corresponds to that tree. I like that conceptually better than having special tags that expand into something else at runtime.

But isn't that the point of what our component frameworks offer, in addition to templating/externalizing other logic such that you simplify the problem space with a clearly identifiable marker/symbol of something more complex and managed elsewhere? ... something unknown to Dreamweaver or HTML or the designer?

I do agree that designers can use dreamweaver/whatever to work with programmer's pages, but lets get with the times and use CSS, on one project of mine, one guy started using the displayTag for his stuff, and I ended up creating a macro that was backed by HB's criteria-- both produced the same structual markup, and the designer just told us to use the same CSS 'classes' on both we're done-- JS was also decoracted by class too.

At the heart of this conversation, I guess this is where I would draw the line between component frameworks and hybrid frameworks. You are still enforcing a view with a supplemental artifact that defines your logic as with Model 2. As in the original article I wrote, neither is better, just that's where the line is drawn in my opinion that somewhat distinguishes JSF from the others.

Posted by Jacob on March 26, 2006 at 08:54 PM MST #

Not necesarily. This is Wicket's goal/ mission statement: 'Wicket is a framework for enabling component-oriented, programmatic manipulation of markup'.

Posted by Eelco on March 26, 2006 at 09:08 PM MST #

Jesse/Eelco, i would have to take a fairly pragmatic approach with JSF, which is why Matt possibly asked for my comments on the framework. It's fair to say that it is the EJB 1/2 out there now-- in implementation and there's a lot of things I would like to change and have changed. Other people have added/modified the parts that they saw lacking in the framework. If anything the API did get quite a few things right to encourage the level of adoption we're seeing. Like I said before, I do hope the next spec can separate itself a bit more to better supplement the needs of other framework developers, something that even Matt posed at J1 last year to the WebTier group which didn't imply that JSF was going to fill that gap, just that it's obvious that something should fill that role. Surprisingly, JSF has 'evolved' into that role a little and it could be done better in future specs, JSF's EJB 3. So for a lot of framework developers, there's a decision to either innovate outside of the 'spec' or innovate within it; approach that however you want.

Posted by Jacob on March 26, 2006 at 09:17 PM MST #

That's an interesting perspective. If Wicket was going to work within the JSF spec, it would have to permit Component level integration, not just page granularity integration. I'm more than a little confused about how we can write a Wicket Component that hosts JSF and vice versa. If the JSF team would like to show us how that's done using our public API (particularly the bit about multiple levels of component nesting!), I'm sure we'd be more than happy to add that to the Wicket project. Until this happy day of integration arrives, we have a lot of work we want to get done on making Wicket the best framework it can be on its own because we believe it's a better approach to web development. We've made an unbelievable amount of progress in less than two years and I expect even more by the end of 2006, including generics support, a book and more. Everyone that comes in contact with it seems to be blown away by the quality of our code, speed of development and our back-to-simple-Java emphasis. It's really kindof beyond me how Java web development has drifted so far away from the original focus of Java on simplicity. It's time to tip that balance back the other way. In areas where the carpet doesn't meet the walls, I think innovation in the Java core (vm, language, core packages) is often going to be the right approach. I've never understood from day 1 why Java web development wasn't fundamentally about Java objects. Wicket aims to put us back there at that sweet spot.

Posted by Jonathan Locke on March 26, 2006 at 11:09 PM MST #

Jacob:
> So for a lot of framework developers, there's a decision
> to either innovate outside of the 'spec' or innovate within it

JSP is still supported as a base J2EE presentation technology, is not it? Even if/when JSF gets rid of JSP entirely, JSP will be still supported, at least in its current version. So, one can still innovate within good old JSP spec ;)

Posted by 64.160.69.34 on March 27, 2006 at 10:55 AM MST #

lol, that's why I said, "... approach that however you want."

Posted by Jacob on March 27, 2006 at 10:53 PM MST #

Matt, the document you've compiled here is a very useful insight into the minds of the Java web-space, thanks a lot for your effort!

Posted by Wolfgang Schnerring on April 30, 2006 at 02:18 AM MDT #

Matt, the link for the document is broken. Can you please update it?

Posted by Maninder Batth on March 11, 2010 at 04:40 PM MST #

@Maninder - I updated it to point to the Slideshare Version.

Posted by Matt Raible on March 11, 2010 at 04:48 PM MST #

10+ YEARS

TWITTER

RECENT ENTRIES

Tag Cloud

[TSSJS] Java Web Frameworks Sweet Spots BOF