Tapestry - "we try to make the simplest approach the correct approach." I haven't been blogging much of this session b/c I'm just sitting back and
soaking it up. It's a good session and Howard is a good speaker. I'm learning a lot about Tapestry and it's philosophy about web development.
I especially like the line-precise error reporting - it's something that all frameworks need to do better.
Tapestry looks very cool. You basically
write an abstract Java class that has abstract methods for properties you define in an XML file. Tapestry them implements this class and its abstract
methods. The class that Howard wrote to handle a login form is very simple - it's only about 7 lines long - and 4 of those are abstract methods!
The HTML form is cool too - not much of the HTML
has changed since it was bare-bones HTML. He's merely added some a few "jcwid" and "listener" attributes to some of the elements.
Tapestry is a large system of subsystems, all implemented behind interfaces. It ships with its default behavior (i.e. page/template pooling), but you can
(supposedly) easily change this behavior or implement custom classes. Internationalization is a first-class citizen in Tapestry - no surprise here since it is
in most MVC frameworks. Tapestry 3.1 will embed Hivemind at its core and will provide much easier integration with tools like Hibernate and Spring.
Tapestry's "Validation Subsystem" looks very rich - providing both client side and server side validation. It uses Field decorations to highlight both labels
and fields when validation fails. By default, it promotes using CSS to change colors, backgrounds, etc. There are a couple of Helper Beans for validation:
the Validation Delegate and the Validator. It's pretty neat that you can bind a label to a field in XML. Since HTML already allows binding
<label>'s to form elements - you'd think that Tapestry could harness this by parsing the template. I suppose it's just easier to require the
XML binding - then you don't have to worry about the user writing invalid HTML.
Howard is trying something new in this presentation - real-time coding. I use this in my presentations and it works pretty good. He's having some serious
issues b/c he can't mirror his laptop's monitor with the projector. This obviously makes it difficult to code since the slide show is his monitor. I
try to use pre-canned code (i.e. IDEA Live Templates) so there's less chance of fat fingering things. I also use a Mac - on which mirroring works great.
The "Page" object is pretty cool in that it contains a bunch of lifecyle methods you can override. Most frameworks don't have lifecycle methods. I guess
Spring's SimpleFormController does with onSubmit, onBind. Lifecycle methods are a Good Thing IMO. The formSubmit() method is always called,
regardless of validation errors. Therefore, you have to get the IValidationDelegate and check if it has errors before continuing. I wonder what the logic
behind this is? Most frameworks seem to support automagical validation - with no further work required by the programmer. I guess it's kinda cool b/c you
can continue with validation errors if you want to. Choice is always a good thing.
Howard just showed us a client-side validation example. The wicked cool thing is that the client-side script is configured in a .page file rather than in the
HTML template. Most frameworks I've seen (that support client-side validation) require you put something into your template. This was a good
talk, I'm definitely interested in Tapestry and excited to start learning it in the next couple of months.
David is going to cover some JSF advanced topics: data table, tiles integration, custom components and validators. I was talking
with Rick Hightower last night. He mentioned that he's been doing a fair amount of work with JSF lately and really likes it. He
actually said he thinks he can develop a webapp faster with JSF than he can with Struts. He also said that JSF ships with a lot
of what you need - and a lot of the JSF books seem to cover how to add new stuff (custom components and validators) you don't need. This is to
say that the books tend to cover the features of JSF, rather than how to develop successful projects with JSF. I said I thought
it'd be nice if there were some JSF books by folks who'd used it to deliver applications. More of a "here's what you need to
know" kindof manual. I think that's what JSF needs.
The <h:dataTable> in JSF is pretty much the same as the <c:forEach> tag in JSTL. An interesting note on the JSF
expression language - it starts with a # instead of a $. For example:
<h:dataTable value='#{tableData.names}' var='name'>
...
</h:dataTable>
The major difference between JSF and JSTL's expression language is that JSF EL can access managed beans. The JSP 2.0, JSTL and
JSF expert groups are going to work together to try and synch up their expression languages. Personally, I don't see why the JSF
folks didn't just use JSTL and simply include managed beans in the lookup logic. Here's a wierd one - if you use any "template text",
i.e. in a dataTable - you have to wrap the text with <f:verbatim>text</f:verbatim>. David says this is one of the embarrasing
things about JSF. He hopes it'll be fixed in the next version.
The <h:dataTable> looks very similar to the
DisplayTag. Sweet - that's one less thing I'll have to worry about when creating a JSF app.
I've said it before and I'll say it again - my two favorite tag libraries are the DisplayTag and
Struts Menu. As I'm learning new frameworks, one of my major goals is to reproduce the same functionality I enjoy in my Struts+JSP
apps. It's been pretty simple so far with Spring and WebWork, since both support JSP. However, it might get a bit tricky with Tapestry
and JSF. I'm sure it'll be possible (and hopefully easier) to reproduce this functionality, it's just a big unknown
at this time.
"Form" beans in JSF are not like form beans in Struts. It's really just a class that doesn't extend anything and has action handler methods.
An interesting point - the actionListener's value (which is really a class.methodName) can be any class in any scope OR it can be a
managed bean. How about some code:
public class Form {
public void changeLocale(ActionEvent e) {
FacesContext context = FacesContext.getCurrentInstance();
Map requestParams = context.getExternalContext().
getRequestParameterMap();
String locale = (String) requestParams.get("locale");
if ("english".equals(locale)) {
context.getViewRoot().setLocale(Locale.UK);
} else if ("german".equals(locale)) {
context.getViewRoot().setLocale(Locale.GERMANY);
}
}
}
The major reason behind the FacesContext is to support Portlets. So rather than using a ServletContext or PortletContext, the FacesContext
provides a level of abstraction. The underlying theme of JSF: To be as flexible as possible. This is to say that there are many ways
to do things with JSF. I often think it's better to have less choices when learning a technology, but once you're versed in it - choices
are great. I guess I just wanna know the best way to do things, not all the options. Actions are for business logic, ActionListeners are for UI logic. ActionListeners are always fired before Actions - in the event
that you have an actionListener and an action defined for the same component. Listeners and Actions are really just methods on a class and they
can actually both be in the same class. JSF is starting to appeal to me. This session has been one of the fastest so far - there's only 20
minutes left and it feels like it's flown by.
JSF ships with converters for dates and currencies out-of-the-box - cool! Now David is explaining about a custom
CreditCard converter. This is what Rick was talking about last night. Why do we need to know this stuff? Would a normal talk on another MVC
Framework talk about converters and validation? I bet not. I think it's a good topic - maybe something that other frameworks should cover
more visibly. The Converter interface has two methods: Object getAsObject() and String getAsString(). The Validator interface has one method:
void validate(FacesContext context, UIComponent c). I just asked David about using Commons Validator instead of JSF's core validator. He said, "Yes,
it's possible." Sweet! You can use Commons Validator with Struts, JSF and Spring! Now if we could only get support for it in WebWork
and Tapestry - then I'd eliminate my need to learn another validation engine.
Now David is talking about using Tiles with JSF. It looks as simple as using the <tiles:insert> tag to insert dynamic content into an <f:subview>.
Any time you insert a tiles component, you need to wrap it in an <f:subview> tag. That was short - we're done talking about Tiles. I had some
questions - i.e. can you refer to a definition directly from an action or in the action's navigation definition? Oh well, onto custom components and renderers.
Custom components and renderers seems to me to be something that should be left out of these types of presentations. Sure, it's cool they're possible - but
who's using them? Have you needed them in a real-world JSF application? I only want to know the things I need to know to develop a real-world JSF webapp.
Sorry, I forgot - there aren't any real-world webapps written with JSF. If I'm wrong - send me a link. ;-)
This presentation was good - it inspires me to learn some more about JSF. Maybe there'll be some projects in my next gig that require JSF - that would
be wicked cool. After all, the best way to learn this stuff is to get paid to do it. If nothing else, I'll get to learn it later this year when I write
AppFuse's web layer in JSF.
For the 2nd session of the day, I've decided to attend the session on AOP. My choices were Converting
XML (Ben Galbraith), JSF (David Geary), What's new in EJB 2.1 (Monson-Haefel) and Runtime Code
Generation (Glenn Vanderburg). I asked David about his JSF presentation and he said it was "boring" so
I decided to skip it. This session, in the first 10 minutes, is pretty boring too. I might have to duck
out of this and attend another session - but none of the other sessions really interest me. This
one started this morning, and it seems to be a continuation of this morning session. It's mostly
on AspectJ and he's doing the good ol' logging example. I don't really have an interest in using
AspectJ since Spring's AOP is more than adequate for my needs. Oh well, I guess I'll stick around and
relax.
Ramnivas is using Eclipse to compile his aspects, and shows us how if he uses "javac" to compile everything,
no aspects are added. I'm guessing that there's some sort of plugin for Eclipse that allows for easy
compiling of aspects. A new feature in AspectJ 1.2 is the ability to set an ASPECTPATH and then use "aj"
rather than "java" to run code. This achieves the same effect as compiling the aspects in Eclipse. The "aj"
script appears to just set the system classloader.
Now Ramnivas is showing us how you can use an aspect to define pointcuts on internal appserver classes. His
example involves WebLogic, the J2EE Petstore and logging any EJB method calls. To use this, he has to
start WebLogic with a custom script, that has a custom classloader defined. For some reason, we're now talking
about log.debug() vs. if (log.isDebugEnabled()) { log.debug() }. Ramnivas
thinks that most folks don't wrap their debug statements (the proper way). Who doesn't know about this?! I'd
like to think that most developers are writing the 3-line version vs. the 1-line version.
An interesting quote: "So many things to show you - 3 hours is not enough." Maybe if we didn't have to
wait 2 minutes for WebLogic to start each time, 3 hours would be plenty. ;-) Ramnivas just added
logging to all the classes in the blueprints packages and then reloaded the page. There looks to be several
thousand method calls occurring behind the scenes for a simple page. Of course, there's lots of tag libraries - but
still - PetStore is a ridiculously complex application. Why did some ever impose this crap upon us as "best
practices" for Java. IMO, best practices should be based around simplicity, maintainability, testability and
performance. Does the PetStore even ship with unit tests? I'll bet it doesn't...
Now we're watching a pretty cool demo where Ramnivas is using aspects to enforce coding policies. In this
example, he's using aspects to enforce rules in EJBs (i.e. no static variables, swing or threads). It interesting
in that the aspects actually prevent compilation and display errors defined in the aspect. It's a neat idea, but
I'm suspicious in that a lot of this AspectJ stuff seems to be Eclipse-specific. What I mean by this is that
Eclipse seems to be required for compilation. Is it easy to aspect-enhance your classes using Ant? I would
hope so.
Ramnivas seems to be quite the AspectJ expert. He mentioned that he wrote a book for Manning and has mentioned
a couple of his contributions to AspectJ in this presentation. I admire authors that write and contribute to projects
at the same time. It's often an indicator that the person knows what the hell they're talking about.
This afternoon's first session choices are as follows: JSF Advanced Topics (Geary), Intro to J2EE Web
Services (Monson-Haefel), JSR166 (Glenn Vanderburg), Rhythm (Brian Boelsterli) and GUI Development (Ben
Galbraith). Web Services and Rhythm are 3 hour presentations, so I might stay away from those - that's just
too long for me. Now that I'm sitting in the 2nd half of a 3 hour presentation - it seems that these sessions
are best attended in the first half. It's almost as if the presenter is trying to find things to talk about
in the second half. Or maybe AOP is just a boring-ass topic. ;-)
I'd like to go to Brian's talk on Rhythm, since he's a good friend and mentor of mine. But then again, I
learned Rhythm from him - and use it daily - so I don't know that I'd get anything out of it. Advanced JSF
looks good, maybe I'll go to that one. For the 2nd session this afternoon, I'll probably attend Howard's
Creating Powerful Web Forms with Tapestry. Maybe I should stick with JSF and Tapestry and
make it a web-intensive afternoon. Both presentations are even in the same room!
Groovy makes for easier for loops. As an example,
for (Iterator i = r.iterator(); i.hasNext();) {
System.out.println(i.next());
}
... becomes ...
for (i in r) {
System.out.println(i)
}
With Groovy, you can remove semi-colons and use dynamic typing. This means you can basically remove
any types (i.e. List). The nice thing is that typing is a choice - you can use static typing like
you do in Java write now.
One thing I forgot to mention about this conference. Jay Zimmerman (the organizer) has a pretty good
idea. The full schedule is printed on the back of the conference badges attendees hang around their
necks. This makes it very easy to find and decide what session to attend. I wish more conferences
would do this.
Richard is going through closures, native list looping and how you can remove classes and method
declarations. It seems to me that one of the coolest features of groovy is that all of the
shortcuts are optional. This is huge IMO, because it means the developer has a choice -
which is always nice. Richard says that in his experience, a program written in Groovy is about
1/5 the size of the same thing written in Java (an 80% reduction in code). Someone in the room asked
about performance. I was surprised to hear Richard say that Groovy was a bit slower. After asking
about this, it turns out that Groovy can be executed as a script or as native bytecode (if compiled
first). So when Richard said "it's slower" - he meant the script version is slower - because
it's interpreted - just like any scripting language.
Sweet - I just got a connection on the hotel's wireless network. I was in the midst of
reading some RSS feeds in NetNewsWire and noticed
a JRoller blog with additional coverage of this conference. ... Sorry, I got sidetracked for the last 20 minutes with the Spring developer's mailing list - talking
about simplifying Spring
forms in JSPs.
Back to Groovy. Richard, and several members of the audience, are talking about closures. I still
don't really get what they are and why they're important. I guess I shoulda been paying attention. ;-)
Groovy has regular expressions built-in - based on JDK 1.4 Regex. In Groovy, == is the same as .equals()
in Java. And === is equal to == in Java. Apparently, they did this because folks usually use ==
when they really want to get the functionality of .equals(). I like the idea that == in Groovy means
the same thing as == in JavaScript, but I don't know how I feel about ===. I'm guessing that using
.equals() is still possible.
Richard has a good presentation style. He does a lot of coding during his presentation - writing
scripting, compiling and executing them. Unfortunately, since I got internet access, I haven't been
paying attention as much as I should - but at least 75% of the class seems to be extremely engaged. An
interesting thing about this conference vs. the MySQL Conference in Orlando. At MySQL, almost all the
presenters had PC Laptops. In fact, I was one of the only ones with a PowerBook. At this conference,
Bruce Tate is the first one I've seen that uses a PC. Almost all the presenters are using PowerBooks -
mostly 15".
Groovy can be used for easily writing XML as well as enhancing your Ant build scripts. One thing
I'm hearing at this conference, as well as seeing on blogs recently is that AppFuse's build.xml could
probably use some refactoring. With Ant's new import feature and the ability to write scripts in
build.xml - it's likely it could be greatly simplified. Then again, it ain't broke - so why should
I fix it?
Richard's showing us how easy it is to write XML using Groovy's shell:
import groovy.xml.*;
x = new MarkupBuilder();
a = x.Envelope { Body("Hi")}
If you run this, you'll get:
<Envelope>
<Body>Hi</Body>
</Envelope>
An interesting thing from the above demo. When Richard added "print a" as the last line in the
script, it printed "Envelope" after the XML output. He said this is because the last line in Groovy
is treated as the script output. That's kinda wierd IMO. GroovySQL - pretty cool and simplistic. A
nice feature is that connections are automatically closed (when the script completes). Another thing
Richard mentioned is that Files are also automatically closed - even when used inside an Iterator. It
seems to me that Groovy is trying to stop many newbie Java developer mistakes, as well as do more
automatic resource management (closing files and connection). This is actually similar to Spring in
how its JDBC and ORM support manages closing connections behind the scenes. Good stuff - another tool
to make life easier for Java Developers.
After slipping out of Bruce Tate's Spring talk, I headed into Dave Thomas's Advanced Version Control talk. I was going to blog it in real-time, but his talk was full of tips-n-tricks and there was just too much information. He showed us how its possible to use CVS to "undo" things and how the "magic -j" option allows you to easily merge experimental branches, as well as undo certain time periods of code. It seems that CVS is way more powerful than I ever knew and if you use a lot of tags and branches - it can be a very handy tool. The biggest thing I got out of this talk is that it's possible to do what I want to do at Java.net.
At java.net, they give you a CVS "module" for your project, rather than a CVS "repository" like SourceForge does. A couple of weeks ago, I decided it would be nice to arrange AppFuse's CVS so it would be more similar to a repository. By default, java.net gives you a "www" folder in your project's module - and when I first imported AppFuse, I just included www as a folder in the appfuse (base) module. Since I want to add more modules, I figured it would be easy enough to move all the base appfuse stuff to an "appfuse" folder so I'd end up with:
appfuse (module)
- appfuse
- www
This achieved what I wanted (from a CVS viewpoint), but when I'd check everything out, I'd get "appfuse/appfuse" - which is not what I wanted. You can read more on java.net's forums. Anyway, I ended up backing out the change. After sitting through Dave's talk, I realized that it's easy to achieve what I wanted. I just need to get access to java.net's CVSROOT module and add a line to the "modules" file to say "appfuse appfuse/appfuse". Damn, I wish I would have known that a few weeks back.
After that, dinner was served (catered) by the hotel. After dinner, there was an Expert Panel Discussion - where the experts consisted of: Rick Hightower, Bruce Tate, Dennis Sosnoski, Bruce Snyder, Rod Cope, Dave Thomas and Daniel Steinberg. It was a good discussion, with topics ranging from EJB3 to .NET to dynamic configuration with scripting languages to JSR 175. A most enjoyable event. Following the discussion, a group of us headed over to the hotel bar and grabbed some beers. I got to sit next to Renee Dopplick, Dan Steinberg, Dave Thomas and Mike Clark. It was quite a treat. I didn't get home until midnight.
Today's sessions start in 45 minutes and that's about how long my commute it - I'd better get going!
