Craig McClanahan's Weblog

At RailsConf 2008

I am presenting tomorrow (Friday, May 30) at RailsConf 2008, a session entitled Rails powered by Glassfish and jMaki. Originally, this was intended to be presented by my colleague Arun Gupta, but his wife is due with a child "any day now", and she, for SOME reason, took exception to his being away right at the moment :-).

Best wishes to Arun and family ... you can find the presentation slides here.

May 29 2008, 10:20:26 PM PDT Permalink

jMaki on Rails Example App

My colleague Arun Gupta has posted a blog entry describing how to use jMaki for Rails to pull information from a database and display it using a jMaki widget (in this case a Yahoo Data Table widget). May 17 2007, 03:40:59 PM PDT Permalink

jMaki on Rails

Coming back from being deep into new technologies, Craig describes the integration he has been building between two interesting technologies ... jMaki (wrappers around various third party widget libraries for Ajax and DHTML development) and Ruby On Rails. [Read More] May 07 2007, 05:06:34 PM PDT Permalink

Is Visual Web Pack Based On Shale?

Java Studio Creator and Visual Web Pack support an application framework that is very similar to the View Controller functionality in the Apache Shale project. This entry answers the question of whether Creator/VWP are dependent upon Shale, and how the world got to the way it currently is. [Read More] Dec 07 2006, 10:45:13 AM PST Permalink

Creator 2 Is Out ... And I Get To Have A Life

Well, it's finally out. The final release of Sun Java Studio Creator 2 has hit the web site, and it's free (just sign up for the Sun Developer Network, which is also free, and you'll be able to download a copy). Thare are lots of cool features that you can read about at the site, and in other blogs about Creator today. I'd like to spend a couple of minutes talking a bit about what it is like to be the architect for a product like this.

As you might now already, Creator is based on the NetBeans Platform. In the particular case of Creator 2, we're based on NetBeans version 4.1. But ... that's not quite completely true. Creator development started, a couple of years ago, as a skunkworks project to build a tool focused on visual development of web applications. My colleague Bob Brewin, who was architect at the time (he's now architect for all of Sun's tools) describes some of the vision at the time, and the background of the original code name ("Project Rave") that we used.

What Bob doesn't tell you, though, is what we had to do to get there :-). For expediency we started from the NetBeans code at the time (version 3.6) but hacked many modules of it fairly radically. That is not a sustainable engineering practice over the long term, so we've spent the time ever since coming closer and closer to binary compatibility with the NetBeans platform. In the Creator 2 release, we've made substantial progress towards closing the gap. This, of course, requires interesting "negotations" with the NetBeans platform team -- all going on while NetBeans has their own product delivery schedules, and associated requirements, which don't always line up.

One thing I will say for the NetBeans folks, though ... they know how to build a great platform. And they've been really great to work with, throughout the process. Indeed, you'll see the results of us working together even more in the future. I got to visit the Prague office (where most of the NetBeans developers live and work) last fall -- along with some other travels that leads to my "get a life" comment in the title of this entry. Prague is an incredibly beautiful city, and the team is well organized and passionate about what they do.

Part of what an architect does at Sun is to go out and talk to lots of people, both showing off what we already have but also listening for feedback on where we should go in the future. For me, this kind of thing is often centered around speaking at developer events -- coupled with customer visits and press briefings scattered around as well. This last fall, though, I crammed more travel into less time than I ever thought was possible. Over the course of ten weeks, I went to conferences in Tokyo, Buenos Aires, and Beijing ... followed immediately by the trip to Prague. (Hint -- if you ride a crowded subway in Prague, be SURE to hold tightly to your wallet). And, just for good measure, I travelled down to the Bay Area for a couple of quick trips as well (I normally telecommute from my home in Portland). Sheesh ... I've got enough miles stocked up I'll probably never buy an airline ticket again. But, to my wife's chagrin, I am not all that enthusiastic about flying anywhere fun with them :-).

We had released two Early Access versions of Creator 2 over the last six months, and the amount of feedback we received was both enormous and very useful in improving the quality and performance of the tool. I'd like to extend my personal thanks to everyone who downloaded and try out Creator 2 EA, and especially those who took the time to give us input. As well, thanks to everyone who listened to me present about Creator, or my open source passion of the moment (Shale).

I'd also like to thank the entire team at Sun that brought Creator to life. That's not just the developers. It's the QE folks that made sure we were meeting the quality criteria, the technical writers that produce the wonderful tutorials and articles, the release engineering and website teams that actually produce the bits that were shipped. The list goes on.

In the mean time, I'm going to take a deep breath, and look for someplace we can drive to for vacation this year :-). But, of course, my travel calendar for this year is starting to fill up already (February in Korea, March in Las Vegas, May in San Francisco, and who knows how many additional things that will get added). Isn't being an architect fun?

Jan 25 2006, 04:28:59 PM PST Permalink

Web App Framework Innovation Continues -- News At 11

As many of you might recall if you've heard me speak about web application frameworks, the fact that (in the early 2000s) there were so many available choices. At one time, during the development of the JavaServer Faces 1.0 spec, I was tracking close to 50 choices in the Java web tier space. While the wide range of choice was very gratifying, it was also very confusing to developers and architects tryng to decide what to use. It was also not optimal for creation of components that could be transferred from one vendor's technology to another.

Among the promises of a standard API for building web tier user interface components was the idea that a common base API would encourage the creation of component libraries that could be used across different vendor implementations of JSF, across multiple application servers, and across mutiple tools. It is pretty clear that, over the almost 18 months since 1.0 went fnal, that we (as an industry) are well on the way towards seeing this vision turn into reality. There is widespread innovation all over the JSF landscape -- not just in components, but also in non-HTML renderkits, non-JSP view technologies, and customizations to the basic JSF front controller framework. The latter (of course :-) has been of particular interest to me; more about that below.

So, did the emergence of a standard API stifle innovation in this field (a potential downside that detractors of standards efforts sometimes pose)? Not hardly. It's definitely true that the number of frameworks you hear a lot about is smaller now, but the pace of innovation (as well as applying "lessons learned" from the successes, and failures, of older frameworks continues apace. Today, then, we're still in a world where a development team has a variety of technical choices to base their architectures on. How do you choose?

For one portion of the population as a whole, this decision will (at least in part) be based on how well a potential framework plays with the standard API (JSF). People concerned about this will recognize that JSF 1.2 is now a required part of the Java EE platform (as of verson 5.0), and might be concerned about staying in reasonable alignment with the mainstream standards. If this is you, then you will likely find yourself categorizing various frameworks on their degree of closeness with JSF. The following dimensions will serve as a useful starting point:

• Frameworks that can use JSF components as an alternative view representation. This will be the broadest category, because basically all the interesting frameworks can use the RequestDispatcher.forward() mechanism provided by the Servlet API to forward to either a JSP page, or some alternate JSF view handler supported technology, to render the actual view. In such an environment, you typically do not see other features of JSF (conversion, validation, navigation, managed beans) being used -- instead, the native capabilities of the framework, which are also used when JSF is not present, are utilized. Instead, the output features of the components are the primary value received by using JSF.
• Frameworks that utilize more of the input processing capabilities of JSF. In addition to using JSF as an output technology (as described in the previous category), various frameworks can use portions of the input processing capabilities as well. Just as one example, if you use Struts with the Struts-JSF integration library, you can use the automatic type conversion feature of JSF input components to make your form bean properties typesafe, and therefore not have to do tedious conversions in your action methods.
• Frameworks that use JSF as a foundation, adding value via the extension points in the APIs. Such a framework will leverage the fact that JSF itself provides a standard MVC-based front controller architecture (with a well defined request processing lifecycle), plus other application oriented features (such as managed beans and navigation management), in addition to its component API architecture. Such a framework can therefore be simpler to build and maintain, by avoiding the redundant implementation of features already provided by JSF, and focus on adding value (additional features, improved ease of use) around the edges.

  Shale is the only framework I am aware of that currently fits into this category -- if you know of others, please comment on this blog entry with pointers.

For people where alignment with JSF is less important, or not at all important, it is still somewhat difficult to compare the various approaches, because they appear (on the surface) to be so different from each other. To assist with this sort of a comparison, I presented a session at the recent O'Reilly Open Source Convention (thankfully, in my home town of Portland so I didn't have to travel for once) laying out a basis for comparing web application frameworks focused on how they address the following major architectural decisions:

• Overall application architecture
• Representation of static and dynamic markup
• View tier component model (or not)
• Mapping requests to business logic
• Model tier resource access
• Page navigation

In the slides, I compared the following frameworks on these decision dimensions:

• Struts
• WebWork
• Spring MVC
• Tapestry
• JavaServer Faces

No, this does not cover the entire gamut of interesting frameworks -- but I only had a 45 minute slot, and we still had to race through the slides very quickly to get through in only three minutes over my alotted time. But the interesting thing was to see where the different frameworks approached the same problem area in a similar manner, versus where they took divergent approaches. Seeing how the covered frameworks compared on these categories should make it easy for you to do a similar analysis of other frameworks, if that is your desire.

Interestingly, the standardization of JavaServer Faces did not kill innovation around other frameworks (or even stop people from trying to create and introduce new ones). Indeed, one could argue that the finalization of the standard API was a catalyst that triggered a renewed burst of activity on the part of many framework developers, knowing that all of the frameworks would now be compared to "the standard" approach.

It is also pretty clear that JavaServer Faces has hit a sweet spot where innovation around the standard itself can also grow rapidly. You can see in the comparisons that the expert group which created the 1.0 version of the spec did indeed harvest many lessons from the other frameworks that existed at the time, as well as recognizing that we had to provide robust extension points to allow innovation to occur on top of this standard. And it has been. And it is continuing.

There were those who thought that the Java web tier was going to become a boring place as more and more technologies got standardized. I don't think we have to worry about that for a while yet.

Aug 19 2005, 10:00:00 PM PDT Permalink

Data Provider APIs -- A hidden gem in Creator 2 EA

As many of you know, Sun recently released Sun Java Studio Creator 2 EA, a product for which I am the Architect. By the way, yes that really is a shark -- Creator releases are code-named after various breeds of sharks, and this release is called "Thresher Shark". Anyone remember the code name for the previous release?

It's been quite pleasing to see all the positive response from users and the press (including the one my colleague Tor pointed out). Everybody comments on the nice new components, the refined look and feel, and all the new editing features (which we inherited by upgrading our base platform to NetBeans 4.1. But I haven't seen as much attention to one feature we added -- a new binding API for connecting components with back end data providers of various sorts. As we talk more about what these APIs do, a quick sidetrack into how we got here might also be of interest.

Even back to its origins as a skunkworks effort called "Project Rave", Creator has been focused on empowering an audience (corporate developers) that has, in many respects, found the Java platform difficult to deal with. Besides liking to use component oriented development, and drag-n-drop tools, one of the application styles that corporate developers tend to spend a lot of their time working on is retrieving data from databases, and displaying it in tabular reports. "OK", we said, "let's make this really easy -- just drag a database table from the Server Navigator, drop it on the Table component, and the component should automatically adapt to the columns that are available in the query."

We accomplished that initial goal, and this feature quickly became one of the most popular capabilities in the original release. But we quickly started hearing customer feedback that there's more ways to access data than just JDBC based rowsets. And, anyone who used the visual binding capabilities for rowsets would quickly ask for the same thing when they want to bind to the return value from a web service (or EJB) method call, or have a data abstraction layer that presents the persistent data as a set of JavaBeans (for example, if you're using Hibernate underneath). Could we, pretty please, hook up the same sort of drag-n-drop binding, and customization of the resulting table structure, for these data sources as well?

So, we did. I got the chance to demo this in public for the first time during our JavaOne session, "What's New With Sun Java Studio Creator" (TS-6911). When I got to the part about data providers, I did the following demo:

• Dragged a Table component onto the design surface.
• On the Server Navigator, I expanded the node for my demo database, and dragged a database table onto the page, dropping it on the table component.
• The design time API for the Table component took over, and created a CachedRowSet instance to interact with the database, plus a CachedRowSetTableDataProvider to interact with it abstractly.
• In addition, the Table Component dynamically recreated its columns, matching the columns returned by an SQL SELECT statement. Because Creator asks the components to render themselves, even at design time, you immediately see how this is going to look.
• This much we could do before. But the next step was new -- I expanded a node representing a particular Session EJB that was installed on my server, and dragged the getCustomers() method (one of the public methods provided by this particular EJB) onto the Table component.
• This time, the design time code synthesized and compiled a custom TableDataProvider for that particular EJB method, and wired it up to the columns of the table, which now matched the bean properties of the Customer beans returned by the method.
• Changing my mind again, I did the same thing, but this time with the results returned by a web service call.
• And again, a custom TableDataProvider was constructed for me, the columns were changed to match the new result type, and again we see the result immediately.
• For my last trick, I used one of the concrete DataProvider implementations we ship with Creator (ObjectArrayDataProvider), dropping it on the design surface and using the property sheet to connect it to an array of JavaBeans that my application provided. Then, I used the Table Layout customizer to bind the Table component to this data provider, instead of any of the others (you can certainly have more than one data provider in use on the same page, if you need to). Again, the Table component adapted itself, this time to the bean properties of my existing bean class.
• In none of the cases above did I even have to write any Java code to actually retrieve the data. The data provider implementations take care of that for you, the first time the component asks for some data. It just works.

I've been speaking at conferences and in front of customers and user groups for over six years, but what happened next is unique in my experience -- I was interrupted by applause for a technical feature of a product that I had had a hand in designing and building. Way cool. But what's even cooler is that the developers in the audience recognized how powerful this abstraction is, and how easy it can be to build applications accessing any source of data.

So, when you grab a copy of the Creator 2 EA release (you can get it for free, just follow the download link), I would encourage you to not just stop at the comprehensive palette of JavaServer Faces components. Open up the "Data Providers" and "Advanced Data Providers" categories, and drag a few onto the design surface. See how you can use the same visual editing experience to compose applications from non-visual components as you do with visual components. Open up the JavaDocs ("Data Provider Reference" in the dynamic help window") and explore how you can leverage these APIs in your application code, as well as the use Creator puts them to for binding. Give us some feedback on to make this aspect of Creator, along with everything else, even better in the final release.

And, the next time you read a review of Creator 2 EA, look for some comments about data providers :-).

Aug 12 2005, 04:14:02 PM PDT Permalink

Back from behind the firewall

Hey ... remember me? The guy who promised to start blogging, did a couple of times, and then disappeared last fall? I'm ... um ... back :-)

Although I've had the opportunity to speak at more than a few conferences in the last ten months, I've been spending most of my time on two primary activities:

• My day job -- architect for Sun Java Studio Creator, where we recently introducted Creator 2 Early Access. There is lots of interesting stuff going on here, but I couldn't talk about it until we went public.
• My open source efforts -- where the beginnings of a new web application framework called Shale are starting to take shape. Shale is innovative in the web framework space because it presumes the existence of JavaServer Faces, and adds capability on top instead of redundantly implementing the same features.

Now that life is (relative to my normal madhouse) at point that isn't quite so frantic, it's time to get back into the blogging habit, and talk about these topics, plus other interesting things going on in the world of Java, and especially in the web tier. Things might get a little interesting in September, when I'm slated to go to both China and Argentina; but both of those occasions will have me talking with developers. That's always a useful endeavor.

To start things off, I'll shortly post a blog on a hidden gem in the Creator 2 EA release that hasn't gotten as much attention as some of the other features.

Craig

Aug 12 2005, 03:47:09 PM PDT Permalink

Wherefore Art Thou, Oh Components

In a TheServerSide thread responding to the fact that I've started blogging, an interesting question came up from a reader with the alias NullPtr:

I am speaking about building a custom JSF component. A custom JSF component can comprise (sic) of several sub-components arranged in a specific layout, there could be JavaScript associated with these components. Who writes this component, the Java developer or the web designer, and how?

While the first part of this statement can lead to its own set of interesting design discussions (on "one big component" versus "assemble complex things out of simple things"), let's focus here on the second part. I believe that, in the case of JSF components, there will be more than one answer to this question over time. Let's look at some of the possibilities, using the term widget as a generic reference to some sort of reusable user interface component that is written against some sort of API supporting component development.

• First, consider a complicated widget from your favorite UI technology (say, Struts Layout; Tapestry's contrib:Table, Echo's Table, or whatever). Did a page author create the implementation of these widgets? Probably not; it was likely a Java developer either working on the framework itself, or intimately familiar with the APIs of that framework, who created something reusable. The Java developer undoubtedly used their own favorite editor or IDE (insert gratuitous "Emacs rules, Vi drools" discussion here :-).
• A second traditional source of widgets has been the providers of IDE tools themselves. In order to enhance the design time experience of the page author, the tool will often provide prebuilt widgets with extra design time support (for example, GUI dialogs to configure the columns in a table, or data binding dialogs to attach to model tier business objects). Traditionally, the components provided by a tool would typically conform only to the component API supported by that tool. One of the ways that JSF encourages more components is making it possible for these same components to be used in other tools as well. See, for example, what Oracle is doing to migrate their traditional (Oracle proprietary) components to JSF with ADF Faces.
• Naturally, the open source community has been a historical source of widget libraries for various component APIs. Previously, such libraries have tended to be closely associated with the underlying component API project (or its development community); the advent of a standard component API makes it much more reasonable to build such libraries that plug in to multiple frameworks or tools.
• Within large corporations, it is common to see the Marketing Department (for external facing applications) and/or the IT department (for internal apps) mandating that all applications conform to a common set of look and feel standards. For example, I was visiting a customer recently that had a prebuilt set of JavaScript code to create menus with a common look and feel across all of the pages. Currently, that means each page author starts with a cut-n-paste of template code in order to create every new page. A great strategy would be for the IT department to package up that JavaScript code into a widget (this is very easy to do with JSF components) so that the page author can leverage the drag and drop capabilities of development tools to add the code block to their page, and (perhaps more importantly) customize its behavior using property sheets, just like you can customize the characteristics of an Input Text component.
• Page authors, in my experience, are generally less concerned about creating "fine grained" reusable chunks of markup (although they do like the idea of being able to reuse such chunks created by others). JSP, for example, has evolved ways to reuse fragments (such as static and dynamic includes in JSP 1.0, or tag files in JSP 2.0). My belief is that these technologies will continue to be leveraged for larger chunks of stuff (such as a banner that is common across multiple pages), rather than on individual widgets, and we'll see tools focus on supporting this sort of use case (for example, see Page Fragments in Sun Java Studio Creator). On the other hand, it's certainly feasible to contemplate a specialized tool for building JSF components that starts with a chunk of markup, and creates the component classes for you -- it's just fairly straightforward Java code, after all.
• Finally, there are generally "standard" components provided by whatever component API you are using. In the case of JSF, this is the set of simple HTML components that are provided out of the box, so you can at least become familiar with the technology quickly. This is where commonly required concepts show up to be standardized (analogous to the way that JSTL standardized tags like <c:if> that every tag library needed, but everyone was doing differently). This is not where you are going to see high speed innovation in fancy new widgets. And that is a Good Thing (tm). The focus is, and continues to be, on a high quality API underlying the components that are, and are becoming, available from the sources listed above.

So, where do reusable components come from? The same places that they always have. The extras that JSF provides (a common basic API for building such widgets, useful infrastructure like managed beans and value bindings, and an architecture designed to be easy to support in tools) encourages the development of component libraries that are not aligned with only one technology or tool -- the focus is as much on reusable as it is on components.

Oct 02 2004, 11:07:10 AM PDT Permalink

Struts Or JSF? Struts And JSF?

Introduction

It should come as no surprise that the most frequent questions I get asked center around the issue of which of these two web tier technologies an organization or individual developer should consider using. It makes sense to ask me, because I was the original creator of the Struts Framework, and was the co-specification lead for JavaServer Faces 1.0 (JSF).

Usually, the question is framed as an or issue, based on an understanding that the two technologies are mutually exclusive. That turns out not to be the case, but it can still be difficult to determine what to do. This blog entry provides my current advice on the subject -- but, to understand it better, it's worth briefly reviewing the development and focus of the two technologies.

The story is a little long compared to typical blog entries; if you want to cut to the chase and see my advice, scroll down to the section entitled The Bottom Line, below.

Struts

Struts grew out of a personal need (open source developers often call this scratching your own itch) to support the development of an application that I was responsible for, prior to joining Sun in 2000. My task was to take a US-centric application to Europe, initially in four languages, and make it available (among other delivery channels) on the web. At the time, there was lots of discussion about appropriate architectures for on the JSP-INTEREST mailing list at java.sun.com, but there were few available implementations. Therefore, I set out to create an application framework for my own use, particularly focused on some key functional areas:

• An architecture based on the Model-View-Controller design patterns commonly seen in rich client applications, focusing on separation of concerns between presentation logic and business logic.
• A request processing lifecycle that is applied to all incomding HTTP requests, allowing the centralized management of common functionality like input form validation, and invoking business logic via a logical alias, rather than embedding knowledge of the business tier into a view tier component.
• Robust support for localizing the user interface of a web application.
• Since I was planning to use JSP for the view tier, a set of JSP custom tags that simplified the creation of user interfaces based on HTML forms.

The resulting framework served my needs quite well. As it became obvious that my needs were not unique, I began the process of open sourcing this idea of a web application framework at the Apache Software Foundation. What happened next was nothing short of extraordinary -- Struts quickly became the de facto standard web application architecture in the J2EE space (the number of significant Internet applications built with it is substantial, but is dwarfed by the number of intranet applications that use it), integrated into nearly all the major app servers and tools, supported by a rich ecosystem of knowledgeable proffesionals and skilled developers, backed by significant documentation in the form of books and articles, and the basis for a large user community centered around the Struts User mailing list (to subscribe, send an empty message to user-subscribe@struts.apache.org).

As Struts became a common starting point for developers new to the Java platform, an interesting phenomenom was occurring -- for many developers, the key perceived value of using Struts was assumed to be the JSP custom tags for HTML forms. While these tags are quite useful, they do not constitute a robust user interface component model, which has led to the need to create or integrate of third party tag libraries for more complex presentation requirements. To me, the core value has always been in the controller tier (the request processing lifecycle, and the features which this lifecycle has enabled, such as the additions of the Tiles framework for reusable look and feel, and the Validator Framework for client side and server side enforcement of form validation business rules). This perception, then, has led to some of the current confusion.

JavaServer Faces

After Struts was released, and was beginning to demonstrate its popularity, an increasing number of other frameworks and component implementations were becoming available. Indeed, at one point during the development of JSF, I had pointers to over 50 such technologies on a spreasheet being used to survey the market. While a large amount of innovation occurred, it was difficult to forsee the development of a common standard API for user interface components -- one that would enable the creation of a component marketplace where tools vendors could support one component API instead of 50, and where component developers could count on interoperation with many tools instead of one or two.

JSR-127 was introduced with the goal of solving this problem -- providing a common base level API for building user interface components for web applications, with the specific goals of being both accessible to developers writing applications by hand, but also easy to integrate into tools. In order to complete this JSR in any reasonable amount of time (and, if you wish to argue that we didn't achieve this goal, I won't disagree :-), we stayed strictly focused on the view tier. Controller tier functionality was considered out of scope, although to be of any practical use we had to provide hooks for basic things like instantiating objects on demand, as well as support for page navigation.

The focus on the view tier was clear from the feature list for JSF 1.0:

• Standard component API for user interface components, ranging from simple input fields to more complex tree controls and menus, to sophisticated scrollable tables which allowed both input and output. Components also support standard JavaBeans style events and event listeners.
• Decoupled rendering model, so that the same component could be rendered in different ways (for example, a command component used to submit a form might be rendered as either a button or a hyperlink).
• Request processing lifecycle focused on the handling of user interface events (such as the node of a tree control being expanded or contracted), coupled with support for data type conversions and component level validation rules.
• Utility technologies supporting the component APIs, including value binding and method binding expressions, managed beans (create on demand), and page navigation support.

JSF 1.0 was released in March 2004, followed by a maintenance release (1.1) in May, and is being rapidly adopted by tools vendors, component writers, and application developers alike. The beginnings of widespread adoption are clearly occurring, and any application which you are about to start should certainly evaluate JSF to see if it meets your needs. Besides the functional APIs described above, you will enjoy the availability of robust tools support from many vendors (shamless plug -- including the product I am currently an architect for, Sun Java Studio Creator).

The Bottom Line

But what about all those existing Struts applications? Are they going to get left out in the cold, or the developers forced to abandon their existing code and rewrite it? Nothing could be further from the truth.

The ideal scenario for existing Struts applications would be that we should be able to migrate, one page at a time (nobody has time to replace their entire UI in one fell swoop) to using JSF component tags -- either the standard ones shipped with JSF, or from any available third party component library -- to improve the richness of the user interface. And, because of the original MVC-based promise of separation of concerns, this migration should require little or no change in the back end functionality of the application (for Struts, that primarily means Action and ActionForm classes). Also, the migration should not eliminate the ability to use key Struts features like Tiles and the Validator Framework.

This scenario is, in fact, achieveable. In the Struts source repository is the Struts-Faces Integration Library, that achieves exactly this goal. It is currently available in nightly builds, but will shortly be released as a stand-alone add on library for Struts 1.1 or 1.2 based environments. The nightly builds include two versions of the canonical Struts example application, one using Tiles and one not, both using the Validator Framework.

If you have an existing Struts based application, then, I encourage you to evaluate a migration towards using JSF components instead of the original Struts HTML tags. Not only are the original tags effectively superceded by JSF, they are also not undergoing active development at the moment. You will find effectively equivalent functionality in JSF components already available, and much more sophisticated user interface components under development by many providers, for use in the future.

For new development, here's the best strategy for determining what to do:

• Evaluate the two technologies individually, to see if they satisfy your requirements.
• If one or the other technology is sufficient, go ahead and use it (it's easier to learn and use one technology rather than two where possible); keeping in mind, however, the caveats about Struts HTML tags mentioned above.
• If your requirements include unique features supported only by Struts (such as Tiles or client side validation support), feel free to use the two frameworks together.

The Future

It should be clear by now that there is overlap between Struts and JSF, particularly in the view tier. Over time, JSF will continue to evolve in the view tier area, and I'm going to be encouraging the Struts community to focus on value adds in the controller and model tiers. Thus, it will become more and more clear that there is room in many web application architectures for two frameworks, each focused on their own tiers, cooperating to meet overall architectural requirements. The details of this, however, will be the subject of further discussions on the Struts developer mailing list, and (undoubtedly) future blog entries.

Sep 27 2004, 03:23:01 PM PDT Permalink

All Right Already

OK, it's time. They asked. They cajolled. They wheedled. They said "you really need to be blogging." :-)

Who's they? Oh, just folks like Alexis and Tor who have been blogging for a while, and are tired of listening to me speak my answers to all sorts of questions when I could be blogging them.

They are right of course. So, here I am -- at the moment still recovering from jet lag after a two week trip visiting Sao Paulo, Brazil (speaking at BrasilOne) and visiting customers in Toulouse and Paris in France. But rest assured, I will soon be joining the ranks of other observers of the way the world works, and will be offering comments on Java technologies (especially in the web tier) and perhaps a few other items of interest. But, for the moment, sleep comes first.

Sep 26 2004, 09:24:53 PM PDT Permalink

« May 2008
Sun	Mon	Tue	Wed	Thu	Fri	Sat
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31
Today