This post summarizes a complaint about JSF that I hear from time to time:
... traditional page design workflow isn't as straight-forward with JSF. With action-based web frameworks, it was rather easy for a HTML designer with some technical acumen to directly edit JSPs to implement a look and feel. Not so with JSF -- you're farther away from the final HTML. Its the components you include on the page that generate DIV tags and so forth. Having accrued 10+ years experience working with HTML, I find this the most frustrating aspect of JSF. We've been given a series of HTML Mockups from a design firm, and integrating has proved to be very challenging. I wonder if JSF merely shifts work efforts from HTML editing to Component customization.
Well, it may be frustrating at first, but on balance I would argue that it is a /good thing/ that your web designer is not editing HTML directly.
The reason is that you should not be implementing look and feel by directly editing HTML. If you're doing that, then you're working around the whole architecture of HTML. What you should be doing instead is adding CSS selectors to your semantic HTML content, and applying your layout, look and feel using CSS. The architecturally correct separation of responsibilities is:
- Developers produce /semantic content/
- Designers produce /stylesheets/
Now, most JSF component libraries (and most Ajax libraries in general) kinda
muddy the water here by providing widgets that look pretty out of the box, and
can be skinned according to some built-in theme
facility. Well, this is an
important marketing feature for something like RichFaces - users have an
expectation that widgets will look pretty without customization - but for
serious development I think it tends to lead people down the wrong path. That's
why one of my first feature requests for RichFaces was a plain
theme that
looks /intentionally/ ugly, and is easy to style using CSS.
In my opinion, there is third, under-appreciated, attribute of the HTML architecture:
- Both content and style are expressed /declaratively/
And, in my view, this is essential for understandability of the code.
Let's consider good 'ol <h:dataTable>:
<h:dataTable value="#{products}" var="prod">
<h:column>
<f:facet name="header">SKU</f:facet>
#{prod.sku}
</h:column>
...
</h:dataTable>
This code fits the semantic content
description perfectly. It's a highly
declarative specification that:
- there is a table, where each row is a product
- with a column that has a header and some content in each cell
I can't really imagine a nicer way to express this. Consider the traditional JSP/JSTL type approach:
<table>
<tr>
<th>SKU</th>
...
</tr>
<c:forEach items="${products}" var="prod">
<tr>
<td>
<c:out value="${prod.sku}"/>
</td>
...
</tr>
</c:forEach>
</table>
This is a significantly more complex implementation:
- there are 5 levels of nesting, compared to 3
- it's difficult to correlate the column header name with the content, except by counting <th>s and <td>s
Even worse, it features an /iterator/, thus mixing two completely different language paradigms (declarative vs. procedural) in a totally unsatisfying way.
On the other hand, it doesn't hide the bare HTML tags from us. If we wanted to edit the JSP template to add presentational concerns, it's easy enough. Unfortunately, once we start adding presentation concerns to our HTML, the HTML code becomes /much/ less reusable. What we should be doing instead is adding CSS selectors.
And, of course, all well-written JSF components make this super-easy:
<h:dataTable value="#{products}"
var="prod"
rowClasses="oddrow,evenrow"
headerClass="header"
syleClass="table products">
<h:column>
<f:facet name="header">SKU</f:facet>
#{prod.sku}
</h:column>
...
</h:dataTable>
Now our designer can concentrate upon developing declarative CSS stylesheets to target the selectors we have provided, and we will be free to make all kinds of changes to the semantic HTML without affecting the design (for example, we could use some fancy table control such as <rich:table> that provides lazy fetching of data from the server when the scrollbar is dragged, along with sortable, resizable columns and row selection. All without a line of JavaScript.
The declarative, semantic style of user interface development really starts to show its potential when we consider databinding. In a traditional UI library, tree views are a pain. We need to write messy Java code to adapt our application's model to something that the tree widget can comprehend. In RichFaces, we simply declare how the tree structure maps to the /structure/ of our object model. No Java code required:
<rich:tree>
<rich:recursiveTreeNodesAdaptor roots="#{root}"
nodes="#{dir.children}"
var="dir">
<rich:treeNode>#{dir.name}/</rich:treeNode>
<rich:treeNodesAdaptor nodes="#{dir.files}"
var="file">
<rich:treeNode>#{file.name}</rich:treeNode>
</rich:treeNodesAdaptor>
</rich:recursiveTreeNodesAdaptor>
</rich:tree>
Now just try to do that in some other Web framework! :-)
Probably, you can now guess why I'm going against the grain by sticking up for JSF when some folks are jumping on bandwagons like GWT or Wicket. These technologies attempt to specify a naturally hierarchical artefact using sequential code. Personally, I just don't get that. I'm deeply interested in technologies like Hibernate, JPA, Seam, Web Beans, EJB3, jBPM which reformulate what used to be programmatic concerns in a declarative mode. That there should be a movement /away/ from declarative programming in the one field where it is /most/ natural (user interface) is counter-intuitive to me.
Actually, the pure-declarative nature of JSF templates is a pretty unique feature of JSF. Facelets is the first templating language I've ever seen that doesn't need iterators and conditionals. JSP, Velocity, FreeMarker, RHTML, etc, all encourage the mixing of logic and content. Facelets/JSF let you express dynamic content every bit as declaratively as HTML or DocBook express static content. (Jacob Hookom is one of the smartest guys in Java, in case you missed it.)
Your blog doesn't seem to support trackback? I have written an entry inspired by this one. Thanks.
Trackback is mostly a spam tool. The idea just doesn't work.
>> declarative programming in the one field where
>> it is most natural (user interface) is
>> counter-intuitive to me.
I'm not completely convinced, I feel that especially when it comes to complex user interfaces, you need all the power and expressiveness of a programming language like Java rather than doing things declaratively in XML.
While I completely agree that CSS is the way to go to manage styling, I think you give HTML too much credit. In a time where people are incereasingly being enticed by RIA technologies, there is often the need especially when JS / AJAX is involved - to push the limits of what HTML can normally do.
Peter, if you are going to pull the RIA card, then lets draw some conceptual comparisons to something like Flex. Almost all component frameworks provide two levels of development. The first level covers 95% of development which is just pure composition and encapsulation. Flex does this with its custom component development and this same strategy is the essence of Facelets. The second level is the 'native' route whereby you have to use a secondary, more primitive technology to create a component. In the case of Flex, you're looking at ActionScript UIObject implementation and rendering based on artifacts from Flash for the most part. In JSF, you are looking at HTML and JavaScript, probably outputted by Java code.
For JSF 2.0, we've already started laying out the foundation for doing a better job of covering the primary case for custom component development. This includes conventional practices in pure composition of markup and other components (something like Facelets) and a secondary piece which is for static asset delivery (images, css, javascript). The end result is doing a better job of taking HTML, JavaScript widgets, CSS, etc and packaging them as a manageable component without needing to dive into the 'native' Java-based development of JSF components.
There's other reasons for going declarative with the UI. You said you need the power and expressiveness of a programming language like Java, and I can't agree with you more. As to why people insist of dumbing down their use of Java only to (duplicate) things through a series of imperative statements in the UI is beyond me. JSF's use of bindings and EL does put the power back in Java (actually requiring it in many cases)-- the problem is that developers have become so dependent on spaghetti logic in their markup that they think they need it to do the job. Even when I'm using Freemarker or Velocity, I find that I'm putting more and more into backing bean logic specific to supporting the view case because it promotes re-usability, type-safety and readability. It simplifies and cleans up the UI substantially-- JSF components and their EL-binding mechanisms accomplish the same thing.
And that is exactly the point of JSF. HTML alone is clearly insufficient for expressing (by which I think you really mean /dynamic/) user interfaces.
But fortunately XHTML was designed for extension, and JSF takes advantage of this built-in extensibility by providing a framework for adding new tags to the language. Some of these new tags add dynamicity.
I'm yet to see any useful feature of an Ajax library like scriptaculous or Ext JS which could not be more efficiently and clearly expressed using a declarative tag.
Now, /today/, the pure-JavaScript libraries are more complete than the JSF libraries in terms of the total set of functionality they offer. But JSF is gradually catching up in this area. What JSF does a /whole lot/ better is:
The great bugbear of JSF today is that creation of new JSF components is difficult, unless you are prepared to ditch JSP support entirely and target Facelets exclusively. But the JSF 2.0 group is addressing this problem right now, by introducing a /much/ simpler methodology for creating new components, based substantially on the Facelets approach. (JSF2 will also stop targeting JSP, thankfully.)
JSF (together with Seam, in the facelets way) is indeed quite promising, I recently spent some time testing these. However, the designer-coder problem was one of the critical point. I agree that a designer can read JSF. However he cannot see it (nor the coder). Now I use a hundred years old home-grown templating library, I guess it is similar to Tapestry. It gives a html - in the sense that you can open the original template in a browser, and it is 95% as if it were live, including example data. I wasn't able to reproduce this with facelets. I have to run the pages on a test server even for myself. I am not sure if there is a tool for this, I haven't found one in a short time. Until the designer cannot test the jsf page he is editing in a browser (or in a 95% browser compatible tool) I cannot imagine how designers, coders and JSF can work together.
If JSF is all that perfect, why is there an issue in the Seam JIRA to decouple the Framework from JSF?
And a very applied example question. If creating custom components is all that easy with Facelets, why is the fancy textarea that I am typing into right now powered by Seam Remoting? And what makes you choose the jQuery Progressbar plugin over a JSF component library Progressbar on this site (at least the script file is imported..) ?
Dont get me wrong, I have been a fan of Seam for a long time (I even possess Michael Yuan's well written book). But stating that JSF IS the answer to everything is just not right, in my opinion.
I don't think anyone said JSF is the end all solution. In my experience, it's not unusual to have JSF and some other framework being used by the same company depending on the needs for the UI.
The whole debate around making things better for designers is pretty bullsh*t.
Starting clean, yes, some middle ground works, but as soon as you bring a dynamic, more maintainable element to your UI development-- then screw the designer. Every site I've worked on, I keep a scratch space of sample layouts and simply plug in ideas, separate from any dynamic coding, then pull those bits into component-like solutions and templating where maintainability is hugely important. Of course, I only have to maintain one CSS doc between my scratch space and the production within JSF or any other web framework.
Ahem, I'm not quite sure who the question is directed at. If directed at me, I'm interested to know exactly where, in the thousands of words I've written on the topic of JSF, I ever described it as ?
JSF, like any technology, has its share strengths and weaknesses. We're working very hard in the JSF 2.0 EG to remedy the weaknesses. You'll find a list of some of things that bug me on this very website.
As for Seam2 being decoupled from JSF, surely this is a good thing? Surely it's reasonable to recognize that JSF is not the only cool web framework out there, and that some people might want to use something else?
Nice try. Actually it's powered by RichFaces.
RichFaces does not yet have a progressbar component. It's currently slated for the 3.2 release.
P.S. We're practical people here, we use what we need to use to get the job done.
Again, where did I (or anyone) state this?
You mean XHTML is great just because you can add arbitrary tags? As already pointed out this leads to the designer vs coder problem. Maybe there isn't yet a framework that can solve this problem perfectly - but some come close. I can't say I really agree with Jacob Hookum's sentiment of :)
Yes, it may be true that you can take a JS widget and wrap it in a tag that generates all the necessary HTML at runtime, hooks into server side event handlers, etc. I'm still not convinced whether all that effort to 'componentize' is worth it.
We all agree that we are concerned about highly dynamic behavior, say involving Ajax calls and partial refreshes on the client. To me, a tag introduces an additional layer of indirection which causes more harm than good:
It's good to hear about all the effort going into improving things with JSF 2.0, but will change happen fast enough?
But the whole point of this post is that it doesn't. Designers create CSS, not (X)HTML. That's the architecture of HTML. Your HTML should not have any in it. Sure, you can create HTML with embedded , but that just shows that you don't really understand how modern HTML is meant to be used.
It is an indirection that gives you ease of use, and maintains the language paradigm of HTML (declarative).
I'm afraid this doesn't follow logically. Why should a tag be more BDUF than any other reusable component in a JavaScript library? Why is RichFaces more BDUF than Ext JS? (It is not, IMO.)
Why is this more true of a JSF component library than it is of Ext JS? (It is not, IMO.)
In Facelets (or in JSF2), creating new tags is /very/ easy, by the way. assuming that you are comfortable coding and testing your own crossbrowser JavaScript (which most developers are not).
Is a Java IDE an additional layer of abstraction over Java? (I don't think so.) If it is, why is that a Bad Thing?
Sure, this is a lot of work, but we're now getting /very/ close with JBoss Tools and RichFaces, and you won't believe how productive this environment is until you've tried it. It beats the pants off the guys with JavaScript libraries for productivity.
Fast enough for what, precisely?
I don't understand why Swing is not evolving to adopt a declarative nature with XML templates and EL bindings. The GWT Incubator Project has an issue to support XML templates in a future release (I hope GWT 1.5). Templates will be parsed at compile time to generate java code to build the widget tree.
(sorry Gavin, how I can post links in my comments?)
That's an incomplete view of web markup, sorry. Precious little web design work happens without manipulation of XHTML structure.
Sure, and not just CSS. The best expressions of this idea are microformats, which didn't find a need to invent a new markup to do so. I did quick search through your weblog and found no mention of them.
Even when you have 'semantically' expressed the domain in markup, you'll still need to coherently present that information for a reader. In other words, look closer. You'll find at least two kinds of XHTML - one for layout and one for content. Your argument and the examples you give only cater for the latter. What you really want is a way to separate the overall layout(s) from structured content. That means cohesion - declaring the site layout in one place and the presentation of domain content in another. Afaict Sitemesh is still the best tool in Java-land for doing this. So good intentions aside, it's not clear to me that JSF doesn't get in the way of both designers and developers; perhaps you could show a fuller example instead of isolated fragments.
One part of the designer vs coder problem which someone already brought up in the comments: for e.g. <h:form>, <h:commandLink>, <h:commandButton> compared to <form>, <a>, <input type="submit"> - the JSF tags are not previewable in a browser.
For custom dynamic behavior, a tag has to be wired up to server side custom code or ajax event handlers etc. Sure you can achieve all this in JSF, but IMHO the declarative approach and the limitations of JSF EL get in the way.
Well, for one - towards the end of your blog post you mention the Wicket and GWT 'bandwagons'.
I agree, there are two kinds of XHTML-- and anyone who's used Facelets sees that it can be freely mixed XHTML without issue. The Hotel Booking demo for JBoss Seam uses XHTML-based templates with JSF components.
The main point is that it should be okay to turn over the reigns of XHTML production to a component given proper hooks for CSS use. JSF 1.x wasn't very good at generating CSS-available XHTML code, but many of the Apache/3rd party components are much better at accomodating 'standards' in markup generation.
This is a problem which is /very/ solvable with tooling. You really should check out the upcoming release of JBoss Tools.
Or, simply render the page and run the generated HTML through a pretty printer. Please don't try to tell me this is hard.
Correct, any dynamic behavior that depends upon server-side logic is going to require a running server if you want to test it.
Personally, I've never seen ayone try to test and develop an Ajax application without the server running. Kinda self-defeating, wouldn't you think?
Could I test dynamic behavior in Wicket applications without a server? What about GWT or Tapestry?
Both of which have a fraction of the penetration of JSF.
Oh please, are perhaps the most disgusting, ad hoc, awful hack I have ever seen.
And I don't see how they are relevant to this discussion.
Now your turn to look closer. The /layout/ is inherently static and declarative, and is not expressed using JSF tags.
FYI, Facelets provides a wonderful templating mechanism to separate layout from content, and reuse the layout. (Something like Stuts Tiles, if you need a reference point.)
These layout templates are separate files that don't usually need to involve any JSF tags, other than <ui:insert/> and <ui:include/>.
This stuff is demonstrated in the Seam examples, and in the started project that is automatically generated by seam-gen or JBoss Tools.
Actually this is a very well-known feature of Facelets, it did not really occur to me that I needed to reiterate it in this post.
Seriously, you really should take the time to learn actually Facelets and JSF, instead of assuming that there are problems that were solved years ago.
Well I never said anything about a , I was just pointing out IMO the 'impedance mismatch' of a declarative tag based approach because you always need to break out of the confines of markup and EL into java code for dynamic behavior.
For very complex dynamic behavior, this is of course true. But there's all kinds of somewhat things that can be specified declaratively with tags, for example:
etc.
For example:
<div id="thediv"> <input type="button" value="open"> <rich:toolTip>Open a dialog box</rich:toolTip> <rich:modalPanel event="onclick"> <input type="button" value="puff"> <rich:toolTip>Puff it all away!</rich:toolTip> <rich:effect event="onclick" type="Puff" targetId="thediv"/> </input> </rich:modalPanel> </input> </div>All declarative, and quite dynamic.
And I would posit that these are overwhelmingly the most common cases of dynamic processing that is suited to the client side. When you need to do something /truly/ complex, go to the server, that's a much better environment to do it in. After all, that's the whole point of Ajax: it makes server visits .
It was a general question, it was not intended to be directed at anyone personally. Should my words have offended you, I am sorry about that. I wrote that sentence to reference your statement about...
I think that is an unfair thing to say, since both these technologies have their place. That is why I pointed out "If JSF is always a better choice then why did you not choose it to do XY...".
I have read some of your statements and I especially agree on the aspect of the JSF lifecycle implementing a "chain of responsibility" pattern to allow a maximum of extensibility.
Of course! Maybe they are jumping on the GWT / Wicket bandwagon right now ;)
Damn. I should get my facts straight next time. Sorry about jumping conclusions here.
Good work on this textbox though. Maybe improve it with adding a few icons to add a quote,list,etc. Or now that I think about it, maybe ignore that feature request. That would look too much like phpBB.
Then why didnt you borrow the one from Icefaces? That would definetly prove the power of the JSF ecosystem, being capable of swapping in new components from the JSF library market (Some decision helping here) ;)
I see where you are coming from - the 'getting things done' area. How would you feel, if somebody now wrote about how wrong jumping on the jQuery bandwagon is? Your jQuery Progressbar is somebody else's GWT or Wicket application. If a technology solves the requirements in the right amount of time/money and quality/maintainability, then it is not about right or wrong, it is about getting the job done.
But who am I telling that? You gave us Hibernate, my rants about getting the job done wont be news to you.
No one actually did this, but that statement was some kind of the message that I read in between the lines of this blog entry.
By the way, thanks for the member search area of this website. Finally a practical example that made me understand the "workspace management" part about Seam (the one last part that I didnt really get ;) ).
As I told in my previous comment, GWT will support a Declarative UI
It is just a simple statement, expressing an opinion, nothing more.
So why wouldn't it be fair? It wasn't said that these technologies are of no-value. Even if the author thinks this way, he is in his rights.
Right, there is a big gulf in meaning between and .
To clarify, I certainly don't believe that GWT or Wicket has . My goal is that Seam will support /both/ of them.
Alright, mea culpa.
Your point about designers need to work only with CSS is very questionable at the current state of browser support for CSS (IE6 still has a majority of users). One must be a pretty skillful designer (really hard to find such people) to express all presentation details only through CSS. So it makes a life much easier if you can control HTML output.
And about : Well, tapestry 5 uses this approach in Grid component (but you can override HTML output there!). Tapestry 4 too, though it's a bit more complicated there.
You mentioned semantic HTML content. They are as close to semantic (X)HTML markup as is available. That you can describe them as while claiming knowledge of is curious.
That doesn't make sense. Of course there's design structure and layout in HTML, HTML is a presentation format. And that's not a problem, it's architectural to the format - truly. Think of applying CSS as a loose coupling, like annotating code. Unless your focus is entirely on server side toolchains - marshalling relational data to HTML - to use HTML according to your precepts you will wind up with micro content formats. Any toolchain that tries to do an end run around this will make the work more difficult than it needs to be as it fights what HTML is for.
Short version: you are never, ever going to redesign a site without changing the (X)HTML, so your best bet is to target parts of content that might remain stable and split those from layout.
Right. And yes, you did need to say that, otherwise the no design in HTML line sounds naive.
Let's be clear on terms here. By , I assume you are talking about this kind of thing, example taken from wikipedia:
I'm sorry, but how could the use of CSS classes (!) to define the semantics of data in an XML document ever be architecturally correct? What a perversion of the very nature of XML! What do we have an markup language for, if we are going to work around its extensibility by defining extensions in a totally ad hoc way using CSS classes?
Well, please tell me, how can I create a schema to describe the structure expected of these ? How can I decide whether this document is a microformat? How can I go about specifying new microformats?
Now, perhaps there would be some way to the concept of a microformat by doing something like:
<div> <v:vcard> <div><v:fn>Joe Doe</v:fn></div> <div><v:org>The Example Company</v:org></div> <div><v:tel>604-555-1234</v:tel></div> <a href="http://example.com/"><v:url>http://example.com/</v:url></a> </v:vcard> </div>But then it wouldn't really be a microformat anymore, would it? It would just be ... XHTML.
Um, you seem to be missing the point of the discussion. We are discussing the separation of roles between web designers and web developers. Yes, there is some level of in any HTML. But you don't need a person with knowledge of graphic design to manage this stuff. (As in most discussions, context is everything: we are discussing separation of roles here.)
As an analogy, a docbook document certainly incorporates and . And it is also a . But you don't need a typesetter to create a docbook document. It is pure semantic content.
The best HTML looks like a more freeform version of docbook.
I have no idea what you are trying to say here. Yes, my focus is very much upon server side toolchains, and yes, I'm very interested in marshalling relational data to HTML. But no, I would /never/ use a microformat to do this.
Wow, a couple of minutes googling , and I discover there's absolutely nothing new in what I just said. I really didn't need to bother. Elliotte Rusty Harold said it for me. And said it far better than I ever could. Tee hee, I think he actually calls micorfomats snake oil, in a very elegant way :-)
I have work with JSF, and yes, it is nice to get RIA implemented, só de designer just make the page , but the rendering of JSF and the reachfaces controls are not even close to easy manipulation of the html/css code, and the skins that they implementen are the worse thing i have ever come across.
Click HELP for text formatting instructions. Then edit this text and check the preview.