Jacob Hookom's Blog

March 2006 Archives

Facelets Milestone Release

Available Now

After a lot of community testing with the 1.1 releases, we've decided to create a stable, milestone release available here. Facelets already has great documentation and provides unbeatable error handling with debugging features for the JavaServer Faces framework.

True Component Development

Many component frameworks available today still fall within the same development requirements as Model 2 frameworks, such as Struts. You have to create a document that represents your view and produce a secondary action or page object of pure adaptor logic/code. With JavaServer Faces, you just have your single document, and the work required of other component frameworks is done automatically by weaving the view and controller aspects together when needed.

Facelets goes one step further as a view technology as it caters specifically to the mechanics of JavaServer Faces. Starting with the compiler, all content, such as text and non-components, is interwoven in such a way that the expensive character data is shared for all users/threads. This helps to keep the pricey aspects of buffering/appending character data within the view to a minimum while avoiding wasteful evaluation.

This really comes to light when you start to look at what's around the corner for MVC with AJAX and partial processing. Views can be constructed without evaluating unecessary results unless required-- setting the stage for things like avatar. No specialized actions, no breaking up of documents, this is purposeful and practical applications of AJAX without lock-in or commitment in your development strategy. Developers complain enough as is about the complexities of MVC on the web, now they think writing specialized logic for AJAX will make their lives easier? Come on, lets approach this sensibly with component-based frameworks.

Finally, Facelets really pushes convention over configuration in the presentation, removing the need to write adaptor code even within the presentation for UIComponents, Validators, and Converters. Although, custom tag development is a piece of cake.

So What's Different in 1.1?

Adam Winer contributed a weekend to modifying the way that shared content, such as non-components, were handled with Facelets' compiler. Now Facelets works directly with the ResponseWriter to produce all the appropriate events for writing elements, comments, attributes, text, etc. The result of this is two fold: we've now cleared up browser specific issues (eg. <script/> tags) and JSF developers are now able to customize the their ResponseWriter implementation to further enhance the output of the whole view for specific platforms, markups, or client/server communication (such as DOM or Fast Infoset).

Along with other bug fixes, the templating features now have better support for inheritance of views and a <ui:repeat/> component was added for times when you need to iterate over collections of data. This component, in conjunction with Facelets' common aliasing features, allows you to inline the repeating right on your <tr/> or <li/> tags in HTML.

Road Map

As always, open source projects are a work in progress. While much of the core of Facelets has stablized in functionality, I'd like to start vesting time in purposeful component development and web standards with JavaServer Faces. I'm also getting more eager to produce examples of XUL and XAML (windows vista) with JavaServer Faces and Facelets. Lastly, Facelets EL implementation is configurable, so I'd like to see OGNL or JEXL implementation of the the standard EL-API available soon ;-)

The New Servlet for MVC Frameworks

Frameworks of Today

All MVC frameworks basically operate within the same 5 phases:

1. Decode Interpreting state/parameters passed from the client
2. Validate This involves validating the information decoded and possibly authorization/authentication
3. Update Once the submitted information is validated, update the Java model
4. Invoke Some controller behavior is handled here, such as an action once state is applied from the update phase.
5. Encode Rendering the result of the action invocation and model state back to the client

Each of our favorite frameworks are implemented differently, but these phases always exist in some form or as an optional phase. Look at Struts w/ ActionForms and Actions or the hook methods and interceptors within WebWork.

Historically, all of these frameworks start their integration with an HttpServlet or Filter. This is their platform:

public void service(HttpServletRequest req, HttpServletResponse resp)
    throws ServletException, IOException {
    // start here
}

Wow, thanks JEE. You can begin to see why there's so much redundancy or one off approaches to MVC implementations.

A while back, Kito Mann started a WebTier Alignment Group of framework developers. While the group unfortunately never really took off, there were some great discussions and comments. The group did identify that there's common artifacts and points of integration between these frameworks. Maybe a common way of defining validators or converters-- or even a common way of integrating a project's domain model?

I'm going to go out on a limb and suggest that frameworks instead piggy back on the FacesServlet. I'm not saying that framework developers use JSF as end developers do, but being that it's part of the JEE 5 specification, use the bits and pieces you need. There's so much there that can be provided to frameworks that operate completely different.

Frameworks of Tomorrow

To elaborate on this, I'm going to template out a simple Action framework that sits on top of JSF, but only uses a little bit of the features, not including the overhead of stateful components. Ideally, we want to process URIs like this:

/order.addItem.do?item.id=41667&item.qty=3&item.code=SA

First, based on our familiarity with the HttpServlet, where do we start with our simple solution for JSF? The easiest route is to implement a PhaseListener which intercepts requests and does all the processing itself. Alternately we can look at simply providing a Lifecycle implementation.

Because we want to provide RoR/WebWork-like features, it would be great if we can simply invoke or set properties directly on our domain objects from an IoC container. Well, the Faces API has a scoped IoC container built in and has integration from both Spring and JBoss Seam to name a few. Sounds like we're already ahead of the game for our simple Action framework.

To implement our request processing, we'll break the URI into parts and evaluate them using JSF's built-in EL capabilities. The following is example code for basically implementing the 5 MVC phases with the help of JSF. While there's more to be added, this provides the basics required in pseudo code.

// get our JSF-provided FacesContext
FacesContext faces = FacesContext.getInstance();
Application app = faces.getApplication();

// JSF provides Portlet/Servlet wrapper
ExternalContext ext = faces.getExternalContext();

// EL support from JSF's API
ExpressionFactory elFactory = app.getExpressionFactory();
ELContext el = faces.getELContext(); // local to thread

// to store messages
Map<String, String> msgs = new HashMap<String,String>();
ext.getRequestAttributeMap().put("messages", msgs);

// our view result to forward to when we're done
String result = null;

// 1: decode phase
String action = faces.getViewRoot().getId(); // w/ massaging
Map<String,String> params = ext.getRequestParameterMap();

// 2: validate phase
boolean valid = true;
Map<String,ValueExpression> paramEL = new HashMap();

// enable our ValidateResolver
el.putContext(ValidateResolver.class, Boolean.TRUE);

ValueExpression ve = null;
for (Map.Entry pair : params) {
   try {
     ve = elFact.createValueExpression(el,
                                       "#{"+pair.getKey()+"}",
                                       Object.class);
     paramEL.put(pair.getKey(), ve);

     // ValidateResolver could throw an error here
     ve.setValue(el, pair.getValue());
   } catch (ValidatorException ve) {
     valid = false;
     msgs.put(pair.getKey(), ve.getMessage());
   }
}

// disable our ValidateResolver
el.putContext(ValidateResolver.class, Boolean.FALSE);

// if we validated successfully
if (valid) {

   // 3: update phase
   for (Map.Entry pair : params) {
        ve = paramEL.get(pair.getKey());

        // set it for real
        ve.setValue(el, pair.getValue());
   }

   // 4: invoke phase
   String elAction = "#{"+action+"}";
   MethodExpression me = elFactory.createMethodExpression(el,
                             elAction, Object.class, null);

   Object invResult = me.invoke(el, null);
   result = (invResult != null) ? inResult.toString : null;

   if (result != null) {
      // delegate routing of result
      NavigationHandler nav = app.getNavigationHandler();
      nav.handleNavigation(faces, action, result);
   }
}

// 5: encode
faces.renderResponse();

While the above is only pseudo code, it does show that JSF could be used without needing to use stateful UIComponents with a custom, lightweight MVC framework. Because your framework would have a FacesContext always available, it would be much easier for you to include UIComponents down the road if you so choose.

Conclusion

I guess the point I'm making is that these new frameworks should take advantage of the JSF API, even though you're not using all of it. Facilitating other framework developers with the JSF API is something that should be pursued more vigorously by the JSF EG. With each phase of MVC outlined within JSF and the delegation of concerns around ViewHandlers, NavigationHandlers, ActionListeners, Converters, Validators, etc, the whole stack is very customizable. Ideally, developers could co-habitate MVC solutions on top of the JSF-API such that you can have the best of both worlds with action and component frameworks.

The Unified EL from the Trenches

It's always been my plan to write about the new EL-API, but based on some recent blogs and questions online, I thought I'd finally post something.

How does the javax.servlet.jsp.el Relate?

Lets approach this by example with what you know in JSP. With JSP you had:

FunctionMapper fnMapper = ...
VariableResolver varResolver = new VariableResolverImpl(pageContext);
Expression expr = ExpressionEvaluator.parseExpression("${foo.bar}",String.class,fnMapper);
String value = (String) expr.evaluate(varResolver);

With the Unified EL-API, you have:

ELContext ctx = new ELContextImpl(pageContext);
ValueExpression expr = ExpressionFactory.createValueExpression(ctx, "${foo.bar}",String.class);
String value = (String) expr.getValue(ctx);

So what's the difference? Is it just syntactic modifications? A resounding, "No." With the new EL-API, it's all about context!

Problem Areas with Old EL

In hopes of proving some worth, I will take you through an example with c:forEach. In this example our goal is to create a collection of references (Expressions) for evaluation later, like on a succeeding request to the server. We want to display and update some reference from the UI using EL.

<c:forEach items="${bean.list}" var="foo">
    <my:input value="${foo.bar}"/>
</c:forEach>

Here we've created our own pseudo-Struts form tag called 'my:input' that retains reference to '${foo.bar}'. The user posts back to the server and you go evaluate '${foo.bar}'-- but foo is now null? Wait, in the example Java code above, I had EL create me an Expression, why is foo null? Shouldn't it point to the Nth item in the list? It makes sense that I should be able to evaluate these expressions later to have the same meaning as they did in my web page.

To fix this the Unified EL supports what's called, "deferred" expression evaluation. This means that when child expressions, like '${foo.bar}' are created by the new ExpressionFactory, it will check to see if you've already bound reference to 'foo'. Well, we did, we said foo is an item from '${bean.list}'. Here's how we keep those references in the Unified EL.

ExpressionFactory fact = new ExpressionFactory();
ELContext ctx = new ELContextImpl();

ValueExpression items = fact.createValueExpression(ctx, "${bean.list}",..);
ValueExpression var = null;
ValueExpression[] values = new ValueExpression[10];
for (int i = 0; i < 10; i++) { // whatever number of items

    // we want to just have reference to the i'th item
    var = new IndexedValueExpression(items, i);

    // assign the i'th reference to our VariableMapper
    ctx.getVariableMapper().setVariable("foo",var);

    // create an Expression that stores foo = i'th reference
    values[i] = fact.createValueExpression(ctx, "${foo.bar}",...);

    // de-reference the i'th item
    ctx.getVariableMapper().setVariable("foo",null);
}

// grab some coffee and come back later
// basically deferring evaluation

for (int i = 0; i < 10; i++) {
    // each expression is basically the same as ${((bean.list)[i]).bar}
    System.out.println(values[i].getValue(ctx)); // works!
}

With this example, you see that we create expressions that have reference to other expressions. This is so any related expression can be evaluated later, in a composite fashion. It's as magical as Disney.

Flexible Resolution

Probably the coolest thing in the new EL-API is the idea of ELResolvers. For those familiar with JSF, it's a combination of VariableResolvers and PropertyResolvers into one supporting method. This allows implementations and frameworks to take a user's expression like ${user.roles['admin']} and translate that any way they want at runtime by providing custom ELResolvers. Here's the sequence of calls to an ELResolver:

ELResolver resolver = elContext.getELResolver();

// Example: ${user.roles['admin']}

// first need to resolve user-- what is it?
Object user = resolver.getValue(elContext, null, "user");

// user is a security Principal, interesting..
Object roles = resolver.getValue(elContext, user, "roles");

// roles is a special RolesDefinition object...
Object admin = resolver.getValue(elContext, roles, "admin");

// oh, admin is a Role object!
System.out.println(admin);

Well the example shows how the Unified EL can process almost any object graph you want without requiring the EL implementation to know anything about your objects or where the variables come from-- btw, where did 'user' come from?

In implementation, the ELResolver is actually a composite (there we go again on composites). So you could have had a chain of default ELResolvers for Maps, Lists, Array, and Beans-- while also injecting your own ELResolvers for security which specifically handle objects like a 'Principal' or 'RolesDefinition'.

I hope you realize how expressive this can get! I realize this is a really scary thought, but you could use Seam ELResolvers in the same composite as Spring ELResolvers...

Conclusion

While the JEE spec is putting the Unified EL to excellent use with JSF 1.2 and JSP 2.1, you can use the new EL API with your own framework too-- such as using annotations that have EL expression as their values for IoC containers that can (EL)Resolve themselves!

Extending the Web with JSF

Background

In a previous blog, "New Feature for JSF 1.2", I concluded with a few sentences on breaking through traditional MVC with JSF:

At the 30,000 foot view, here we've broken through the traditional URI/resource in request/action based frameworks such as RoR, where each thing you want to partially handle has to be separated out and coordinated as a specialized endpoint. Not so with JSF since we've extended the concept of a URI into the page itself, allowing you to uniquely operate on resources embedded into the page. The best part is that your components don't need to know that they are processed as part of a whole or part. In truth, the same applies to your domain model-- refresh that list of employees or modify just one employee without needing to coordinate actions or special cases.

Let me elaborate on this a bit in relation to where I see JSF progressing through JSF 1.2 and future specifications. Keep in mind, I'm only one EG member with my own views. First, it'd probably help to explain the what's different about JSF in relation to other, common MVC implementations available.

Traditional Action Frameworks

Requires each request to be coordinated and written as a special case to maintain state. The Java code in the Action serves to deal directly with the HTTP protocol in whatever facade. Java code in the Action pushes possible content to a separate view. Actions must manually handle protocol state transfer to the business model Requires a view to be written for each case to supplement what's coordinated in the actions. Usually in a 1:1 or 1:many relationship for actions to views. Low levels of reuse in both the Java code in the Actions and View Minimal network/server overhead since developers are required to code/optimize each possible request/response condition. Examples such as basic Struts, straight Servlet/JSP, many many others.

Hybrid Component/Action Frameworks

Still requires each request to be coordinated and written as a special case to maintain state. Introduction of component-like concepts eases supplementing the view. Usually have a single event system (request) Components help promote re-use, but there's still a 1:1 or 1:many relationship between actions (or pages) and views. Components/Actions/Pages often require explicit reference to model artifacts, degrading runtime agility during development. Additional network overhead since often times these frameworks make some accommodation for stateful components. A lot of the newer frameworks fall into this category.

Component Frameworks

Framework controller interacts directly with component artifacts. Components act more like a compositional Action or Page from hybrid/traditional MVC. Components and their structure become stateful, adding more network overhead over hybrid solutions. Multiple events are coordinated over component trees. Removing the 1:1 or 1:many association between actions and views, now it becomes many:1, flipping roles. Components are self sustaining, which can be evaluated by themselves or part of a larger view. Since components are stateful, model is usually dynamically referenced, allowing it to change or modified independent of the view at runtime or in development. An example is something similar to JSF

So What?

I thought you'd say that! I believe a deficiency in many MVC solutions is that at some point, you are required to supplement the framework with action or page artifacts in order to coordinate request processing. With Component Frameworks, the view becomes self sustaining for request processing via declaration. With this, we've flipped the traditional 1:many role of actions to views in development and we now have a many:1 relationship. This seems to be more natural to developers for handling event systems instead of coding handlers (actions) for each possible event in the application.

To circle back on my original point of this blog, because components are self-sustaining within the framework, this provides the aforementioned benefit of flipping action and view relationships and allowing your documents and views to be processed as a whole or as partial fragments. Traditionally, since MVC events are mapped via URI as a special case-- that's one channel of communication. With component frameworks, a single URI can be processed/handled in multiple ways in part or in whole, which leads the way to richer forms of communication on the web while easing development.

Take a look at what would be required for development, keep in mind, what is categorized as an 'action' is java code that only exists to coordinate event or request processing of state.

Traditional MVC	Component MVC

For traditional MVC each possible event from the view, you've been required to develop and maintain an endpoint that often includes one more artifact that supports rendering (a view). On top of that, the coordination between client and server is only supplemented by convention and is not automatic. With component frameworks, your development time is spent producing a single artifact that describes the view, composed of pre-fabricated and reusable components that automatically coordinate client and server communication.

As we push forward into richer client interactivity, AJAX for one, what expectations are going to be put back on the developer for not only coordinating, but maintaining these specialized solutions? By the nature of component MVC, each component handles it's own state coordination as supported by the overall framework. This means that components can encapsulate handling AJAX or other rich-content delivery without concerning the application developer or other components included in parallel-- 'they just work'.

How Practical Is This?

It depends on what kind of scalability you are looking for. It's like the old project management grid, the division of: time, money, and quality. You can't have everything-- yet. What I'm talking about is scalability of requirements vs. hardware/bandwidth. I jokingly remember when Struts first came out and people asked about the additional overhead on hardware, Craig replied something along the lines of, "Hardware's cheap, you can always add more, programmers and application maintenance is what's expensive." While this is true, everyone knows there can be restrictions.

Traditional MVC	Component MVC

The above graphs only serve to highlight differences between the two routes of development.

Vertical Development

One may retort, "Why do you think component frameworks are much better at scaling complexity?" To avoid sounding like a broken record, let me ask why everyone uses Spring. Spring provides a series of pre-packaged, pluggable artifacts that support development on the JEE stack. Components work the same way. I could, for example, provide a component that generates an editable table, backed by EJB 3. Similar to portlets, a developer can drop components into their application and use in parallel with others. It's a vertical solution such that it doesn't require much, if at all for additional development.

Pre-packaged solutions aside, since component artifacts are self sustaining, so are developer-created supplements that increase maintainability and re-use. The solutions are vertical.

With traditional MVC, you end up with a series of horizontal solutions that must be maintained and coordinated across multiple layers. The EJB-backed table example would probably require: directly interacting with a PersistenceContext, generating actions for each event type, manually coordinating state transfer between the client and the server, and creating a view to handle passing the appropriate state to the correct actions. On top of that, could you ever use all of those artifacts along side other widgets in a larger view? You can quickly realize the exponential growth in complexity for development with traditional MVC.

Gravity Kills

So you've warmed up to the idea of component solutions for MVC, but the stateful overhead gives you chills. Well, to do component solutions correctly, you are going to have some additional overhead. Really, are you supporting a few hundred users or tens of thousands? If it's the latter, I have an answer for that (surprise). Just like with ORM solutions for persistence, there's cases where you need to optimize. Nothing would stop you from dipping into SQL queries or direct JDBC use. Well, with component frameworks, there's nothing stopping you from either marking components transient or basically limiting their use. For those 'dump content to screen' use cases, you may not need any components at all-- thusly a lack of overhead where the calls could be stateless. But for those cases where things start to get complex, go ahead and utilize components to support development.

Basically, it's a major misconception that because you use components, everything must be coordinated via components. As mentioned in previous blogs, you can produce/render URLs that simply pass identifiers without requiring component state to be maintained across requests.

Why Choose JSF?

First, it's a standard. While some may simply ignore this fact, it's already blossomed a large market of solutions/services. This is Web 2.0. You have multiple vendors, shops, and open source projects that can be literally dropped into and utilized with your applications. While other frameworks do support component development, no where else are you seeing this kind of support from the community at large.

Look at JSF's track record. JSF is built more like a platform, allowing extreme amounts of customization. Since it's initial spec, we've seen many alternatives pop up for describing views, managing application state, and tying in existing popular frameworks. I could start a list, but again, no other framework on the market has been as actively customized or added to-- including Struts.

Finally, look at the way you develop applications. It's the interface/UI that sells your product or more commonly sells your capabilities as an application developer. Going the route of components, knowing you can more easily scale UI complexities-- you're not going to be selling yourself short.

Reflecting on MVC

I've probably written a half a dozen solutions to MVC. All of them a discarded in a folder on my G: drive, never touched again. Every once and a while, after sitting with a notebook, I'll add another one to the G: drive. Maybe the 'G' stands for graveyard.

The other night, I watched a DVD documentary on the band, Keane. It rambles on to a comment from Tim Rice-Oxley about writing songs; how before they had a hit, he could sit down and just let the ideas flow-- how now there's an expecation that everything he writes has to be a hit. It's just not the same anymore.

In some foreign form, I think we can feel the same way. We work so hard to have that one hit, to create that solution that everyone loves.

I know that I will forever adding more ideas to my G: drive. It's not that the solutions are bad, just that the bar has been set. Everything evolves into some form of what's in place with JSF. Of course, each person has their own ideas as to what the perfect solution is, but JSF is my benchmark right now.

All the solutions start out with the idea of having a tree of components that operate on the model. Simple enough. My definition of a component is something that can be evaluated as part of a greater whole or separately. They also participate in all parts of MVC-- rendering, validation, updating, decoding, etc. The important thing is that they can be evaluated independently, and JSF already captures this with it's naked approach to exposing the whole component tree to the developer.

At this point, things get rough. Having the component tree managed like that has to be pricey-- we are talking about MVC on the web. What if the component tree was stateless? That might work, but then I would end up back at square one with requiring components each figure out how to render hidden state and coordinate change with other components. I've been using an Action/Request framework on a project right now and battling with hidden fields, iterative form controls with multiple updates, and JavaScript up the wahzoo.... well it's increasingly difficult. It's not that it can't be done, but I just can't see this being a good solution to require of developers. It's kind of like throwing them into a pit, and if you can crawl out, we'll give you a cookie. It seems that it would be a lot simpler to just have the framework guarantee state transfer for me. Now I'm back in the same boat as JSF again.

This is usually where I get frustrated and stop.

Everyone's so concerned about overhead of JSF and component solutions. Again, every ounce of data I've seen showed that JSF performed closely with solutions like Struts. At JavaOne, in the 'MVC Bottlenecks' BOF, early releases of MyFaces 1.0 were only had 6% less throughput and results like this make me scratch my head-- most graphs show only a few millisecond difference. I know some had mentioned scalability issues, but what was the real issue?

What about the comments that there's no front-controller, like Struts, for JSF with GET requests. Again, I reflect on how I've found myself using Action frameworks. I guess having that front-controller helps if I need to deliver an alternate view. Truthfully, I find that I really only have one view I ever associate to GET requests. All other conditions are considered errors or my single view displays the appropriate message. Authentication/Security is usually handled on a global level... so I've basically lost my need for a front-controller for GET requests. Yes, I do run into cases where I need to deliver alternate pages, but their all part of some transaction via POSTs and JSF has that covered.

Let's keep that ball rolling. Lets say you want to go from a GET request to another GET request with JSF? No one says you can't simply render an HTML anchor tag with a 'hand' generated URI. It's the same thing you would do with Action frameworks.

Despite all of this, I don't expect everyone to use JSF. Most people question the scalability of JSF, but again, I haven't seen actual benchmarks that proves it was an unsolvable issue either within the guts of a particular JSF implementation or within the hardware running the application. Is it even an issue when there's only a 4-6% difference? I guess to me, it's not a question of how easy a framework can scale on the hardware, but how easy it can scale use case requirements. Why do you choose full-ORM solutions over straight JDBC? I guess one could reach a point, just like with ORM, where performance starts to degrade. Is it the ORM's fault or is it because the ORM allowed you to easily do overly complicated things? Could the same be applied to component frameworks for all they provide to you?

JSF will always be a work in progress, just like every other framework out there. Even today, I got excited about JBoss's Serialization announcement since it could allow for an improved, plugable StateManager. So many times this evolution of enhancement has already occured in different ways with JSF-- but the tune is still the same.

This work is licensed under a Creative Commons License.