jump to navigation

Fun with Spring, GWT and Annotations March 4, 2010

Posted by Phill in Frameworks, Spring.
Tags: , , , ,
comments closed

Recently I’ve been porting across some of our monolithic IceFaces application to a more modular GWT application. (There’s nothing wrong with IceFaces as such, but for several reasons I don’t think it’s the right fit for us any more).

It’s been going pretty well so far, although I’ve only been working on it for a few days. I’ve got the GWT-Widget server library up and running as well, which integrates nicely with Spring for RPC. (It basically means you don’t have to define a new servlet in web.xml for each RPC server you want, you can just define them as Spring beans).

However, it does mean that you have to create a mapping for each Spring bean that you want to publish and define it in the application context XML, which isn’t really ideal for modular applications: I’d quite like them to be detected automatically with annotations, that way if you have another module on the classpath it will automatically be picked up.

So, I created another annotation (@RPCService) and annotated my RPC endpoints with it. The annotation, as its value, had the URL of that endpoint (i.e. “/user” for the users RPC service)

Then, my initial thought was to use Spring to scan the classpath and load each one up. I’ll cut a long story short here and say that was all unecessary: if your RPC classes are defined in the application context (via XML or annotations, it doesn’t matter), all you need to do is get an instance of the Application Context and call getBeansWithAnnotation.

This makes things really simple: I have a bean set up which has an initialise method that uses that method to get all classes annotated with my RPCService annotation, finds out their URLs, and then configures the GWTHandler servlet to map those beans.

Dead easy! And very useful to do, if you’re using the GWT-Widgets library.

Edit: After reading the documentation it seems that what I’ve done is essentially re-implement what’s already available in the library. Still, hopefully it will come in useful if you need to do something similar for another usage…


Creating a lazy-loading tree with IceFaces July 7, 2008

Posted by Phill in Frameworks, Presentation Layer.
Tags: ,
comments closed

I tried a number of things to make a lazy-loaded tree in IceFaces, but I couldn’t quite get it to work. There are probably better ways of doing it, but I found something which is pretty easy: when you create your lazy-loaded TreeNodes, for each node which hasn’t had its children loaded yet just create a dummy child. In other words, if you don’t want a node to be lazy-loaded, just add a TreeNode child in which says something like “Loading…”. You will also need to subclass DefaultMutableTreeNode to add in a boolean property – something like childrenLoaded.

Then, in your JSF page, set the tree actionListener property to be “#{beanName.expandListener}” and create the relevant method in your backing bean:

public void expand( ActionEvent e )
        Tree tree = (Tree) e.getSource();

        TreeNode node = tree.getNavigatedNode();
        if ("expand".equals( tree.getNavigationEventType() ))
            _treeModel.loadChildren( node );

… assuming, of course, that your TreeModel has a “loadChildren” method on it. Your mileage may vary. You will, of course, need to check whether the children have already been loaded for that node. But it’s still probably the easiest method that I’ve found so far!

JSF Custom Components with Facelets and IceFaces June 3, 2008

Posted by Phill in General J2EE.
Tags: , , , ,
comments closed

I was having fun earlier trying to get a custom component working. I wanted to create a dynamic menu component, which I didn’t think was easily possible with standard JSF components.

What I wanted rendered was something like this:

<div class="navbar">
    <li class="selected"><a href="#">commandLink</a></li>
    <li><a href="#">commandLink</a></li>

Fairly simple, wouldn’t you think?

Well, actually it’s not that difficult – once you know how!

The problem comes with the way child components are rendered. I was creating a new HtmlCommandLink in my custom component, and then using encodeBegin(context) and encodeEnd(context) to render them.

However, I found that when you clicked on the links, nothing would happen! I looked at the source code, and couldn’t actually see anything wrong. It all looked fine… my only thought was that somehow IceFaces wasn’t picking up the components if I rendered them directly.

One idea was to actually add the commandLinks to the list of children, i.e. getChildren().add(commandLink). However, this doesn’t render components in the way that you want – i.e., I wanted all of the links surrounded by <li> and </li>!

In the end, what I did was create another custom component (ListElementComponent), and have it render an “<li>” and “</li>” in the encodeBegin(…) and encodeEnd(…) methods respectively. Then, I added the commandLink as a child of the ListElementComponent, and added the ListElementComponent as a child of my custom component.

Clear? Probably not!

Basically, the logic was as following:

for (each menu item) {
link = createCommandLink();
listElement = new ListElementComponent();

This seemed to force JSF / IceFaces to render the HTML as I wanted it.

I don’t know if there was an easier way of doing it, but unfortunately the documentation on custom components in JSF isn’t exactly brilliant!

JSF Issues May 14, 2008

Posted by Phill in Frameworks.
Tags: , ,
comments closed

The project I’m currently working on is using JSF and IceFaces. It’s been a while since I used JSF, and I’d forgotten just how annoying it can be at times. The problem is always using frameworks that write the HTML for you: if you don’t have so much control over what is actually output to the browser, if you have a problem (which you inevitably will) fixing it will not be a simple matter.

Take today, for example. I wanted to include a custom JavaScript on an IceFaces page. Simple enough, you would think. Unfortunately, I had a problem where it would only work once you’d refreshed the page! Bizarrely, Firebug showed the JavaScript as existing in the JavaScript body – but it didn’t seem to actually be loaded by the browser.

I think this might be a problem with the way IceFaces loads things up using AJAX, but either way i’m none too impressed. The solution for the time being is to actually use a <redirect/> tag in my faces-config.xml (as suggested on this thread), this isn’t an ideal solution but it seems to work for the moment.

Although JSF does make some development quicker, the amount of time you lose to stupid problems like this probably negates any gains you made originally.

For the next web based project I do, I think I will try something like Spring WebFlow or Wicket, which both look like very interesting frameworks and don’t suffer from the same issues as JSF (although undoubtedly they have their own issues!)

JSF and IceFaces April 4, 2008

Posted by Phill in Frameworks.
Tags: , ,
comments closed

I mentioned a couple of posts ago that I was trying out Google Web Toolkit. Well, I’ve come to the conclusion that Google Web Toolkit is not the right solution for this particular project.

The problem was mainly one of scope: I think GWT, due to the way it’s designed, is more for small-to-medium size projects at the moment. The project which I am currently working on is small at the moment, but we will need to integrate various other things with it in the future and it will grow.

I did look at Echo2 as well (thanks to Dalibor for pointing it out to me), and that does look good – more like it would be able to handle larger applications, due to the way the page is loaded – but I don’t think it’s exactly what we need at the moment either.

What we have done is use JSF with IceFaces. IceFaces is a “Web 2.0” framework for JSF, i.e. it provides a set of JSF components which are AJAX-enabled. It was a bit of a struggle to get working with Tomcat 6.0, but I got there in the end!

Anyway, I’ve been using it for a couple of days now and I really like it. The AJAX is handled completely transparently to you – you just design your JSF application as you would do normally, and IceFaces will handle the AJAX. As an example, it’s really this simple to add an AJAX based table to your JSF page:

1. Use an IceFaces “dataTable” component
2. Have an IceFaces commandButton call the backing bean to populate the table with data (for example, search results)
3. The data table is updated automatically without needing a page refresh
4. …

    Ok, I admit it, items 4 and 5 are not part of it. But still, I think it’s pretty good going.

    There is a bit of configuration to do before you start, but then that’s the same with pretty much any framework I know!

    What I’m trying to do at the moment is set up a “Loading” message, i.e. when you click on a button which will execute a long operation (for example, doing a text comparison on a lot of database fields) a loading message will be shown. By default no message is shown, and I can’t find a way of automatically displaying one for every call (ala DWR).