robjsoftware.info

A blog about software – researching it, developing it, and contemplating its future.

Archive for the ‘JSF’ Category

GWTJSF broken with Seam 2, sorry folks!

leave a comment »

So I’ve gotten past a number of the issues I blogged about previously, and I now have a Tomcat-only no-EJB3 version of the Seam blogging example. I’ve tried rolling the GWTJSF code from my original example back into it, and it looks like Seam 2 has thrown another wrench in the works.

As Chris Alfonso at JBoss warned me, Seam 2 installs the SeamPhaseListener by default. The Seam/GWTJSF integration as it previously existed needed its own phase listener, as explained in my article on the topic. This delegating-PhaseListener technique seems to be impossible in Seam 2. (Unless I’m missing something.)

With the GWT conference breathing down my neck, I may need to sideline this for a while until I get a fallback presentation together — I was hoping to be able to demo GWT 1.5 (if it gets done in time!) with JSF 1.2 and Seam 2, but I can’t count on that at this point, there are only four weeks to go and I don’t have the hacking time I’d need. So it’s Plan B time. I’ll take a week or so and get the presentation together with the previous version of the code, and then I can pound on Seam 2 some more.

Also, it looks like the GWTJSF code has officially been left behind in the Ajax4JSF 1.1.1 code tree, which has been rolled into the RichFaces project — except for GWTJSF, which is nowhere to be found in the RichFaces code tree. GWT can definitely be considered a competitor to RichFaces, so I guess I see why JBoss isn’t supporting GWTJSF, but still it’s a shame. It’d be great to see some more synergy there, but I’m not sure how to bring it about. (other than blog about it and rock the boat a little 😉

Anyway, sorry to those who’ve been wanting to use GWTJSF with Seam 2 — it’s going to be a longish road. All help very much appreciated if anyone else has cycles to hack on this with me!!!

Advertisements

Written by robjellinghaus

2007/11/08 at 06:08

Posted in GWT, Java, JSF, Seam

GWT, JSF, declarative markup, and lunch with Gavin

leave a comment »

Just had an interesting lunch with Gavin King (original author of Hibernate and Seam), and came up with a somewhat crazy idea that needs more eyeballs on it.

EXECUTIVE SUMMARY

The GWT toolset lacks a way to do declarative markup. The only way to compose GWT components is through Java code. Joel Webber of the GWT team said at Google Developer Day 2007 that one of his personal ambitions for GWT is to build a declarative markup system.

The Seam toolchain lacks a way to build custom JSF widgets easily. Building a custom JSF widget with plain Javascript is extremely painful. The GWTJSF integration library goes partway towards addressing this, but doesn’t currently support building composable trees of GWT-based widgets.

What if we brought the two together? What if we could create a JSF-based and Facelets-based markup system that enabled composability of independently developed JSF widgets implemented in GWT? This could both leverage an existing declarative markup system (Facelets) for GWT’s purposes, and deliver a much better toolset for creating Seam applications with richer UI functionality.

That’s the basic idea. If you Get It, then please skip to the DETAILS section. Otherwise, read on.

BACKGROUND

The first chunk of lunch was walking through my Seam/GWT example, clarifying what it does and how it does it. Basically, as the page explains, it takes GWT modules and encapsulates them in JSF components. This allows GWT modules to exist within the context of a larger JSF / Seam application, leveraging other JSF page components and directly communicating with Seam components through GWT RPC.

The main use for this, it seemed to us, is taking existing GWT modules and wrapping them as JSF components, to enable their use in a larger JSF application. This was one of the original use cases that motivated the Exadel guys (Sergey Smirnov and Alex Smirnov) to create their GWTJSF integration library.

Where do we take it from here, though? Originally it seemed to us that if all you need is GWT, then this JSF integration isn’t of much use to you. Michael Neale has already landed — in the Seam 2.0 beta — a GWT integration that doesn’t require JSF at all, but just lets your GWT app communicate with Seam components. (He hasn’t, evidently, integrated my RPC refactoring in GWT 1.4, so it doesn’t yet support native GWT-style RPC, but that’ll be easy to do now that GWT 1.4rc1 is out.)

So, is the only use case for GWTJSF really for people who want to take existing GWT components and build them into JSF apps? Well, Gavin saw the code for the GWT module in my demo, and his feeling was, wow, this is a much better programming model than writing custom JSF components in Javascript. So what would it take to make GWTJSF better at creating reusable JSF components?

There are two main things that the current GWTJSF library lacks. One of them is support for Seam conversation propagation. This is important if you want to have GWT components that can participate in a Seam web application which uses both GWT-based AND non-GWT-based components. You want the GWT components to be able to carry the conversation state in RPCs, so they can participate in the Seam server-side conversation state management. (Yes, I know it is totally against the GWT religion to even mention the words “server-side session state.” This isn’t the main point, so don’t get hung up on that.)

But that’s actually not the most interesting possible extension.

THE DETAILS

The current Seam blogging example is basically a tree view of blog posts. Each tree node can be expanded to show the full text of a blog post, with an inline edit button that lets you edit the post’s text right there in the tree.

Here’s the GWT/JSF markup for instantiating this tree-view-blog-editing component:

<!– This is a JSF component encapsulating a GWT module. –>
<bloglist:component id=”main2″>
  <!– This widget routes GWT RPC requests to the Seam component named “gwtBlog”. –>
  <gwt:gwtListener serviceBean=”#{gwtBlog}”/>
</bloglist:component>

This creates a JSF component wrapping a GWT module. The GWT module exposes an interface which is implemented by the server-side Seam component named “gwtBlog”. So the GWT module uses a single interface to communicate with the server.

The GWT service interface is this:

public interface BlogService extends RemoteService {
  public Blog getDtoBlog ();
  public List getDtoBlogEntryList ();
  public String getFormattedHTML (String wikiText);
  public void updateBody (String id, String newBody);
}

This interface conflates operations on the whole list of posts (getDtoBlogEntryList) with operations on individual posts (getFormattedHTML, updateBody).

Overall, this widget is great and all, but it really consists of two orthogonal pieces: a tree view component, and an individual-post-editing component. They’re bound together in the current GWT code. This widget is monolithic; all it does is make a tree of blog posts. It can’t be repurposed by tweaking the JSF page.

When showing this to Gavin, his feeling was that it was not nearly generic enough. The typical Seam way of doing this would be something like (edited for brevity):

<!– Generic tree view, using a post-edit widget for each node. –>
<ice:tree id=”tree” value=”#{tree.model}” var=”item”>
  <ice:treenode>
    <ice:panelgroup style=”display: inline;”>
      <ice:commandlink value=”#{ item.userObject.text}”>
      </ice:commandlink>
    </ice:panelgroup>
  </ice:treenode>
</ice:tree>

This builds a JSF component tree that declaratively nests multiple widgets, using Seam expression language ( e.g. “#{tree.model}”, “#{item}”) to specify where the components get their data.

Now, here’s the rub. What if you could write JSF / Facelets markup that instantiated a tree of GWT widgets this way?

Something like this:

<gwt:tree id=”tree” value=”#{blogEntries}” var=”item”>
  <gwt:blogpostedit value=”#{item.blogPost}”>
</gwt:blogpostedit>

What you’d be doing here is writing a JSF page that creates a component tree that is purely instantiated on the client. The only rendering would happen on the client via GWT. The GWT components would (WAVING HANDS MADLY) have some protocol for nesting themselves, and would have some data-binding style coupling to the server components from which they pull data. The RPC could be GWT-style RPC via service interfaces generic to each specific component.

This would essentially turn the JSF UI component tree into a structure that can be either rendered purely on the server (original-style JSF controls), or rendered partially on the server and refreshed using AJAX (the Ajax4JSF / RichFaces style of user interface), OR rendered entirely on the client (GWT-style widgets). This would also enable declarative construction of GWT-based interfaces, using the exact same syntax and UI component tree as used for other JSF interfaces.

This is good for Seam, because it enables a graceful path towards Seam-based JSF apps with lots of custom UI code, without losing the compositional good qualities of Facelets. And it’s good for GWT, because it gives a declarative framework for building GWT applications, with a great story for coupling to server-side business logic.

ARE YOU CRAZY?

This is not quite a half-baked idea yet. In fact I’d say it’s about 10% baked. But it’s definitely interesting, and it definitely bears more thinking about.

There are many issues with it, just a few of which are:

  • This doesn’t really let you mix arbitrary non-GWT and GWT JSF widgets; the only allowable children of GWT JSF widgets would be other GWT JSF widgets. (Unless you get really sneaky with partial rendering invoked FROM GWT, which probably isn’t worth it….)
  • I have no idea at all what Joel Webber (of GWT fame) has in mind for declarative markup, so this concept may be totally wrong for his use cases.
  • On the face of it this idea seems to imply some kind of EL (expression language) parser implemented in GWT, which is no small chunk of work.
  • Who exactly implements this is a totally open question; I still want to get back to the offline Blogger client done with GWT/Gears, which has basically nothing to do with this 😉

I don’t claim to have answers to these; this post is just a starting point.

I’m going to post in the GWT developers forum, in the Seam users forum, and in the Ajax4JSF developers forum to see what kind of reactions this idea provokes.

Discuss!

Written by robjellinghaus

2007/07/01 at 04:49

Posted in GWT, JSF, Seam

Landed!

leave a comment »

My first official self-commit to an open source project.

I’ve just checked in my GWTJSF patches to the Ajax4JSF trunk. You can now get the GWT 1.4-compliant GWTJSF project by following these directions.

No word yet from the Exadel guys; I’m 99% sure I didn’t break anything but they’ll tell me if I did, they’re not shy 🙂 I do hope they will update their labs.jboss.org documentation to mention this project again, now that it actually builds in their tree. We’ll see.

I included a reference to the googlecode repository in the gwtjsf pom.xml, so it should have no problems pulling GWT 1.4.10 (which it needs).

The old GWTJSF examples (which are not on labs.jboss.org anyway yet) no longer work, mainly because the Maven build (as my last post discussed) splits the sources into a separate jar, so the old build files break. I’ll likely land at least one of my modified samples in the Ajax4JSF tree in the next couple of days, so people will have a reference point.

After that I’ll get back to finalizing my Seam/GWT example and submitting that to the Seam project. Hopefully in another week, or two at the most, I’ll have this whole thing wrapped up and then I can get back to the Gears/GWT offline Blogger editor project!

Onwards!

Written by robjellinghaus

2007/06/22 at 07:58

Posted in GWT, JSF

Mavenizing GWT-JSF

leave a comment »

As aforementioned here, I’ve spent a good chunk of this year integrating GWT, JSF, and Seam. The current fruits of that labor are here.

The original GWT-JSF integration was done by the Ajax4JSF guys. The code is hosted in the JBoss Ajax4JSF Subversion repository. The main problem is that they’ve converted the entire repository to use Maven, except for the GWT-JSF code.

So I’m fixing that. This post documents how. I’m going to try your patience by giving the blow-by-blow in real-time as I work on this. Consider this an object lesson in how to bang your head against a brick wall with MAVEN spray-painted on it.

First, get the Ajax4JSF code building with Maven, by following these directions from the Ajax4JSF guys.

Second, integrate a pointer to the GWT-Maven repository, along the lines of these instructions from the GWT-Maven team. Specifically:

– Add the gwt-maven repository to conf/settings.xml:

<!-- add gwt-maven repository -->
<repositories>
<repository>
<id>gwt-maven</id>
<url>http://gwt-maven.googlecode.com/svn/trunk/mavenrepo/</url>
</repository>
</repositories>

– Update the GWT dependencies in the main project POM to 1.4.10.

– Add

<scope>provided</scope>

to the gwt-user dependency, to keep it out of the WAR file. (gwt-user.jar is only for compile time; gwt-servlet.jar is all you need in your deployed GWT webapp.)

Why can’t the gwt-maven repository live just inside the GWT-JSF POM? In fact, why don’t ALL the necessary repository definitions just live inside the top-level trunk POM for Ajax4JSF?

Third, run “mvn install” in the ajax4jsf/trunk/gwtjsf directory. See it blow up because it can’t find the 2.0 version of jsp-api.jar.

Wonder why this is, since the top-level trunk build has no problem finding it. Flail around adding a <profile> to the POM and watch it die in all kinds of other interesting ways. Back that change out again. Realize that you really have no idea how Maven works. Look at the base dependencies again…

… Turns out to be because the gwtjsf POM has the wrong groupId for jsp-api — it should be javax.servlet.jsp but it was just javax.servlet.

And with that, the frickin’ thing compiles! That’s progress 😀

What’s more, it’s almost 1 AM and my baby daughter wakes up at 6:30 AM. (Get used to me saying that.) But hey, something works now that didn’t work when I sat down here tonight. That’s what hacking is all about: getting something new working. Get enough new things working, and anything’s possible.

Time to commit all this to Perforce (see my next post) and then off to bed. Next hack night probably on Saturday, or if not, next Monday. Hopefully I’ll be able to land this sucker, and then maybe even land my actual changes to the project! What a concept!

Written by robjellinghaus

2007/06/15 at 06:38

Posted in GWT, JSF, Maven