Raible Designs

JSF 1.0 - Proposed Final Draft Spec and Beta Reference Implementation

From Craig McClanahan on the struts-dev mailing list:

I'm pleased to announce that the Proposed Final Draft version of the JavaServer Faces 1.0 Specification, and a corresponding Beta release of the Reference Implementation, is now available at:

http://java.sun.com/j2ee/javaserverfaces/download.html

Please send any feedback and comments strictly about JavaServer Faces to [email protected].

I'm also finishing up an update to the Struts-Faces Integration Library, and will be making it available (via nightly builds) very soon. Feel free to ask any questions about how to use Struts and JavaServer Faces here on the STRUTS-USER list.

Sweet! It's almost time to try JSF in a webapp. I'd love to offer a web layer for AppFuse in JSF. But then again, I'd like to offer WW2 and Tapestry options too. I just need to figure out how to give the developer that option when building. The main problem is it'd probably be a pain in the ass to maintain all 4 implementations. But then again, that's what unit tests are for!

In other news, a nice patch has been proposed for the DisplayTag that would give it JSTL's EL support.

Struts 2.0

There's a flurry of e-mails about Struts 2.0 dancing around on the Struts Developers Mailing List. Looking at the Overview or the ReadMe, you can see that there's some major (revolutionary) changes being discussed. The Struts Bandwagon is alive and well. The proposal is called Jericho (since it tries to tear-down the walls within the Struts architecture) and proposes to open-up Struts by:

• Declaring interfaces for all core components.
• Providing working base implementations for all core components.
• Encapsulating alll path references within "Location" objects (fka ActionForwards) and referring only to Locations from all other objects.
• Providing additional extension points from core components so that the "Inversion of Control" pattern is fully realized. (e.g., a populate method for the FormHandler.)
• Providing "POJO" signatures that encapsulate servlet/portlet behavior so that applications can be freed of servlet/portlet semantics, if so desired. This strategy would also be applied to optional packages like Validator and Tiles.
• Retain optional access to servlet/portlet objects so that applications can be free to do whatever they need to do.

Also under consideration - adding Struts Menu to the core. Good stuff my friends, good stuff.

Also noticed on the mailing list - Tomcat is not the Servlet/JSP reference implementation (news to me):

There is a (mis)conception, for example, that Tomcat is the RI for the servlet and JSP APIs. That is not the case -- the official RI is the "J2EE SDK" available at http://java.sun.com/j2ee/1.4/download-dr.html. It happens to *include* code from Tomcat, but this is the real RI.

Yet Another Web Application Framework: Shocks

From watching the struts-dev mailing list, I discovered a new Servlet Framework called Shocks. The thing that interests me about this framework is that the author looked extensively at Struts and WebWork both before creating it. It's feature-set sounds nice too:

It has an aspect-oriented workflow engine that can add crosscutting
system logic (like form processing, L10N, security, logging, etc) dynamically at
runtime (without having to mess around with the bytecode).  It can trade actions
across classloader boundaries, enabling web applications to span across multiple
.WAR files.  This allows users to drop in a new .WAR with new metadata and new
actions, which updates the application workflow at runtime across all modules in
the application namespace.  It handles workflow versioning and version rollback
(in case you make changes you come to regret).  It does instance pooling of all
components and sequences.  Every aspect of the system can be managed with JMX at
runtime.

Sounds like Spring, eh? Yes, says the author.

I think there are appreciable differences that have yet to be realized between 
the two (I haven't read their code at all), but definitely a lot of conceptual 
crossover.

I would think that introducing a new framework into the mix (and convincing folks to use it) must be pretty tough at this point, unless you create an IDE to go with it or introduce it in a book. BTW, did you know you can use Tiles with Spring.

The good ol' Struts vs. WebWork Debate

Jason Carreira has been nice enough to post a technical comparison of Struts vs. WebWork. Don Brown (creator of many Struts add-on packages) and Jason have been going at it ever since. It's funny, there's a small part of me that doesn't believe there's a future for Struts (because of JSF). I believe that JSF and WebWork are quite similar, and if I'm going to take the time to learn a new framework, I should learn JSF. Why? Because, I'm willing to bet the literature for Struts -> JSF is out there, and there's probably no literature for Struts -> WebWork. Also, I believe there will be JSF jobs in the near future, but not many opportunities for WebWork. In a perfect world, I'd do something like Kris is doing and learn them all - extend AppFuse to support my favorite framework (if I find one better than Struts) after the learning process, and use that for new projects.

Where does Kris find the time to learn all these frameworks? I barely have enough time to workout and complete my 8-hours-per-day of productivity-for-pay. Then again, I've been getting up around 7:30-8:00 a lot lately vs. the usual 4 a.m.

In my current gig, I'm teaching a fellow programmer how to write webapps in Java. He's never written Java, HTML, CSS or JavaScript. He wants a tool to do it all - so he can drag-n-drop, point-n-click and voila - he's created a webapp. This is a fundamental problem with J2EE - it's not possible? Or maybe it's the beauty - you have to get down and dirty with the code to create a webapp. Another issue is that we're using Struts Resume as our baseline and architecture - and there's really nothing in this app that's drag-n-drop or tools-friendly. Everything is Ant, JUnit, Struts and Hibernate. You have to be somewhat familiar with all of these to build/deploy this app. Personally, I like getting down-n-dirty with the code, but that's because I'm familiar with it and have been working with it for years. Teaching someone else how to get down-n-dirty (and to like it) is proving to be a whole other battle.

Web Frameworks - which one should I learn?

I've seen a lot of talk about Web Frameworks these last couple of weeks - particularly JavaServer Faces, WebWork and Spring. There's also been great articles posted comparing Spring and WebWork as well as an Introduction to Spring from TSS. Spring, WebWork and JSF all look like excellent frameworks to me, but I also continue to believe that Struts is a great framework. And I would go so far as to say that it's the best web application framework. Yep, I said it - Struts is the best web application framework to learn if you are a web developer wondering what to learn. Why? Because it will get you a job.

I've continued to receive a fair amount of calls and e-mails over the last couple of weeks - and they're all calling because of my Struts experience. Good luck in finding a company that wants you to build their web application using WebWork or Spring. Maybe someday I'll be lucky enough to hire employees for Raible Designs and build web applications in my own office with my own employees. Then we'll get to choose whatever technology we want to build customers' apps. Until then, I'll stick with Struts and continue to be an employed developer.

I strongly believe the best way to learn anything is to get paid to do it. I've learned Struts over the past couple of years, not because I wanted to, but because someone else wanted me to - and they paid me to do it. Of course, there are some companies that will probably pay you to learn WebWork or Spring, but most would rather not.

Another thing to consider is that WW and Spring will probably someday develop "migrating from Struts" documentation. Sounds like a good idea to me - until then, and until someone pays me to learn the others, Struts is #1 for me.

Now it's your turn to tell me why my logic is flawed... if you can. ;-)

JSF Presention and sample code

David Geary's Presentation and sample code from last week's DJUG Meeting can now be found online. From Tom McQueeney, DJUG's new president (congrats Tom!):

For those that missed last week's meeting, David introduced us to the new JavaServer Faces specification, now in its 4th "early access" release on the Sun web site. David considers JSF to be a "Struts killer" once the standard takes hold within the development community and tool vendors. The JSF 1.0 final spec is expected to be released early next year.

Early next year == March from what I've heard...

Skinning your applications and Apache+Tomcat on RH9

Here are a couple of links I found on mailing lists that might be of use:

• Xkins: Xkins framework uses Velocity to process snippets of HTML, but you can use any other template processor (Xkins comes with it's own default processor). Xkins also comes with Forms Tag Libs, that allows you to create forms using Xkins and comes with four Skins. Xkins Forms integrates with Struts framework. Xkins also fits perfect in JSF world, playing a role as a RenderKit, and can work with other presentation frameworks, (i.e. struts-layout).I'll stick with simple XHTML and CSS. If I need different layouts (HTML), I'll use a different base tile.
• John Turner has published a Tomcat 4.1.27 + Apache 2.0.47 HowTo. This is similar to mine, but looks much cleaner and to the point.

Later: I discovered the beauty of John's HowTo this evening. It allows you to specify one measly line in Apache's httpd.conf file and only a few lines in Tomcat's server.xml file and viola Tomcat configures itself! It sets up aliases and such for each webapp that you have deployed. As an example, here's dynamically created section for AppFuse:

#################### localhost:/appfuse ####################                                       
                                                                                                       
# Static files                                                                                     
Alias /appfuse "/opt/dev/tools/jakarta-tomcat-4.1.27/webapps/appfuse"                              
                                                                                                       
<Directory "/opt/dev/tools/jakarta-tomcat-4.1.27/webapps/appfuse">                         
    Options Indexes FollowSymLinks                                                                 
    DirectoryIndex index.jsp                                                                       
</Directory>                                                                                  

# Deny direct access to WEB-INF and META-INF                                                       
#                                                                                                  
<Location "/appfuse/WEB-INF/*">                                                                 
    AllowOverride None                                                                             
    deny from all                                                                                  
</Location>                                                                                 
                                                                                                       
<Location "/appfuse/META-INF/*">                                                              
    AllowOverride None                                                                             
    deny from all                                                                                  
</Location>                                                                                   
                                                                                                       
JkMount /appfuse/j_security_check  ajp13                                                           
JkMount /appfuse/auth/*  ajp13                                                                     
JkMount /appfuse/register/*  ajp13                                                                 
JkMount /appfuse/passwordHint/*  ajp13                                                             
JkMount /appfuse/*.do  ajp13                                                                       
JkMount /appfuse/*.jsp  ajp13                                  

I had all of this working great - I even had Apache upgraded to 2.0.47 on OS X (serving localhost/~user files and everything)! And then I rebooted... Now in catalina.out, I'm getting the following - ugh...

BAD packet 256                                                                                      
In: : [B@c283b5 4/843                                                                               
01 00 03 47 00 00 00 00 00 00 00 00 00 00 00 00  | ...G............                                 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | ................ 

WTF?!

Solved: I got this solved fairly easily. I had modified /usr/sbin/apachectl so that the HTTPD variable pointed to /usr/local/apache2/bin/httpd rather than /usr/sbin/httpd. I fixed it by removing /usr/bin/apachectl and executing "ln -s /usr/local/apache2/bin/apachectl /usr/sbin/apachectl". Now if I could only get the Rendezvous mod working on 2.0.x.

JSF and Apache Axis at DJUG

I attended tonight's DJUG Meeting. The meeting was informative and well attended, but it was way too long. I just got home and it's a bit after 11:00. To put it in perspective, I arrived at 6:00. That's 4 1/2 hours of Java love. Elections contributed to the delay, as well as David Geary's 2 1/2 hour JSF presentation.

The basic concepts meeting covered Apache Axis, presented by Scott Davis. He showed us how easy it was to use Axis to create a web service and how to call it from the command line. The biggest highlight of his presentation (for me) was Keynote - his presentation software. It had wicked transitions and the slides looked awesome (good purchase Scott). Other cool software noted during Scott's preso was CodeTek's Virtual Desktop.

Next up was David Geary for a presentation on JSF. This guy has quite a resume: worked for Sun from 1994-97, member of the JSF and JSTL Expert Groups, author of 6 books, designed and implemented the Struts Template library (2nd committer to Struts after Craig). Books coming soon from David: Core JavaServer Faces, Core Rave, and Extreme Struts. Extreme Struts sounds very much like the Struts chapter I wrote for Pro JSP - XDoclet, StrutsTestCase, JUnit, Tiles and Validator. If you're looking for documentation on AppFuse or Struts-Resume, you'll find it in this book. If you don't remember, I wrote these apps for my chapters.

Most folks reading this blog probably know what JSF is. If you don't, it's a Java-based framework for building web applications. It is designed to replace Struts, but that probably won't happen until well after it's 1.0 release (March, Beta in December). JSF was also written to compete with .NET's WebForms, kinda like how JSP was developed to compete with ASP.

Sun's Project Rave is what supposedly will make JSF easy. Can Rave really be that much better than Eclipse or IDEA? Good luck Sun, those are two killer IDEs that are going to be very difficult to beat. And besides, has Sun ever produced any good applications? iPlanet sucks, so does Forte - comparing both to the other options out there.

I could go on and on about what I learned at this presentation, so let me just give you a brief synopsis. JSF generates JavaScript for you for event handling. The JSP tags are long and ugly, but they're named this way (i.e. <h:selectone_menu>) to distinguish a component (selectone) from a renderer (menu). David said he complained about this immensely when he joined the Expert Group, but now sees the point. No XML attributes are used in faces-config.xml - it's all entities. Reminds me of web.xml, lots of typing for not much information (what a pain - today's tool suck at deployment descriptors). JSF has no client-side validation - looks like Commons Validator will be around for quite some time. Especially since JSF requires you to specify your validation after each component in the JSP (vs. declaratively using the Validator). JSF EA4 does not work with Tiles - they're working vigorously to fix this. You can specify your navigation-rules separate from you actions in faces-config.xml (very cool feature).

If you know JSPs and Servlets, it's much easier to learn Struts (and presumably other webapp frameworks). If you know Swing, it'll be much easier to learn JSF. To me, this seems wrong. Some of the examples given tonight had HTML in .java files (for custom renderers). Are we reverting back to Servlets? Is Sun making a mistake with JSF? How is it better than WebWork or Struts? It seems to me to be an over-designed product developed by a bunch of Swing addicts.

My first impression of JSF is that it's going to be harder to teach to newbies (vs. Struts). Everyone says it's a standard so the tools vendors will come through and make it easy. The tools vendors haven't done shit for JSP and JSTL IMO, so how is JSF different? It's a good idea, it just needs to be simplified - a lot. KISS.

JSF: Allows WebWork style Actions

Am I working too late or does JSF allow a WebWork style Action? According to this post, you can have your properties and your logic in the same class (like WebWork). Also, no more worrying about BeanUtils.copyProperties()?

Struts encourages you to use Strings for field values that might need conversion, in order to redisplay correctly in case of conversion errors. You don't need to worry about that with JavaServer Faces, because the redisplay is handled by the components themselves. You will generally use the native data types for your field properties.

Regardless of what the WW Developers say, I think I'm gonna dig Java Server Faces.

PHP vs. Java - which is better?

I have a former client that has a customer. This customer asked them - "so when are you migrating from Java to PHP?" So evidently this person has the impression that the next wave of web applications will be written in PHP. My former client has asked me to provide an answer for their customer. If I translate it, I think they mean to ask "what is different between Java and PHP and why should we use Java over PHP." Here are my opinions - please add yours as you see fit. I must admit I don't know a whole lot about PHP, except that it's widely popular among the Linux/Apache/MySQL crowd and that it's similar to ASP in it's lack of a MVC architecture (yes, I know about the PHP MVC project).

• I think Java is more of an industry standard, whereas PHP seems to be popular among hackers and hobbyists.
• Java provides better separation of layers - key for testability. PHP has all the code embedded in the page, so you have to run it through a browser to test if database connections work (for instance).
• Java is more scalable.
• More folks know Java and it's easier to qualify someone's Java skills. How do you test someone knows PHP? Is there a certification?
• More for-profit organizations use it.

If you're a Java or a PHP-lover, I'd love to hear your opionions (facts are always better). I'm going to point my client to this post, so keep it clean.