If the forums are any indication, there's quite a bit of interest in the Seam community for adding Flex interfaces to Seam applications. Members of the seam community have stepped forward and put together some interesting examples of Seam and Flex working together, and that's been good enough for our more ambitious users. But now it's time to make that integration a bit more formal. So with that, we've added the first round of Flex support to Seam.
We're starting with a simple solution for Flex remoting to Seam applications using BlazeDS. Getting going with Seam involves adding jboss-seam-flex.jar to your application, along with the BlazeDS libraries. The BlazeDS MessageBroker, which responds to requests from the Flex client, is instantiated and managed my the Seam Flex filter:
<flex:flex-filter url-pattern="/messagebroker/*" />
With that, your Flex application can talk to your Seam application. Obviously it wouldn't be wise to expose all your Seam components for remote access automatically. Individual components can be enabled for Flex remoting with a single annotation:
@Name("org.jboss.seam.example.flex.foo")
@FlexRemote(name="foo")
public class Foo
{
public void ping() {
System.out.println("ping!");
}
}
This annotation causes Seam to add a named remoting destination on the default channel, which can immediately be accessed as a \<mx:RemoteObject> in a Flex application. The minimal mxml on the client side would be:
<mx:RemoteObject id="remoteFoo" destination="foo" />
This declares a remote objection. The destination name should match the destination name on the @FlexRemote annotation.
<mx:Button id="button" label="Click Me!" click="remoteFoo.ping()" />
This creates a button, that when pressed calls the remote method. Dealing with results and errors requires a little more code than this, but it works the same as any other Flex remote object.
One of the nice things about Flex remoting is how simple it is to pass complex data structures around. For example, suppose you are writing a Flex client to work with the hotel data in the Seam booking application. If your Seam components had the following:
public List<Hotel> queryAllHotels() {
return entityManager.createQuery("select h from Hotel h").getResultList();
}
Then the entire data set could be loaded into the table quite easily.
<mx:RemoteObject id="remoteFoo" destination="foo" fault="fault(event)">
<mx:method name="queryHotels"
result="hotelTable.dataProvider=ResultEvent(event).result" />
</mx:RemoteObject>
<mx:DataGrid id="hotelTable" />
<mx:Button label="Query Hotels" click="remoteFoo.queryHotels()" />
Note here that the remoting is smart enough to figure out the column names and values to display based on the Java objects returned, with no extra coding. It may not be production ready, but it makes for a great demo.
So, if you want to use Flex and Seam together, how can you give this a try? The Flex module is under development in the Seam22 branch. At this point we only support the basic remoting shown here and don't support conversation or business process scoped components, since the correct mapping of conversations to a rich client is not entirely obvious. If you can live with that, or if you'd like to help contribute to the future development of the Flex module, please jump in on the forums and provide some feedback.
Please check GraniteDs project
Just out of curiosity does Exadel Flamingo fit anyhow to what you are trying to do?
Please, check also the Flamingo project:
http://www.exadel.com/web/portal/flamingo
Yes, and check out also the Tide Framework in Granite DS (see Tide Framework), which integrates with :
Never used it, but the documentation appears interesting.
Yes, those are interesting projects. I hope that those ideas, if not the code itself, can be brought into Seam. We're at the very beginning stages right now, so there's plenty of time to shape the final product.
I've tried GraniteDS a few times, but usually found it cumbersome and sparsely documented. (This could have changed in the last 4-5 months). My general problem with it was that it seemed to try to do too much.
Flamingo seemed fine, but it really didn't do much more for me than BlazeDS plus a couple of companion classes. The lack of messaging (again, things may have changed) was also troubling.
What appeals to me about the approach outlined is the simplicity and narrow scope. I'd rather see something very simple, using a known third-party component, be slowly expanded, than to see the mainline of Seam try to do too much. After all, if you want to run GraniteDS, this shouldn't interfere.
I am a little worried that Seam is going to duplicate the effort GraniteDS (as it did by creating Seam Web Remoting instead of integrating with DWR).
GraniteDS already has integration with Seam, and support for conversations... why reinvent the wheel?
As Norman writes above, we like the ideas from GraniteDS and will continue working with them to bring the best bits into Seam. However, we do believe it is best to not follow NIH syndrome, hence why we wanted integration that works with BlazeDS.
Just to add to the Flamingo mention. Exadel Flamingo (http://exadel.com/web/portal/flamingo) has been available for a year and a half. It allows easily to integrate Flex (or JavaFX) and Seam or Spring. There is obvious support for calling any Seam component as well as Hibernate validation and conversations. There is virtually no configuration except dropping Flamingo Jar file into the application. We just finished working on server-side push for JavaFX and Seam (Flex coming). We have also introduced client-push or occasionally connected applications.
The Hotel Booking application with Flex UI is available here: http://demo.flamingo.exadel.com/booking/
Hi guys, is the development for this integration of Seam and Flex planned for an initial release anytime soon? Since it's in the 2.2 branch, would it make it into a 2.2 release or a 3.0 release? Or probably too early to say? We're interested in this because we're almost starting to finalise our choice in using GraniteDS and if this goes through quickly, it might make things easier for us.
Hi Norman, I downloaded the 2.2 branch, created the seam jars, migrated my application from 2.0.2 to this one. I also added in my components.xml file this part:
< .... xmlns:flex="http://jboss.com/products/seam/flex" .. http://jboss.com/products/seam/flex http://jboss.com/products/seam/flex-2.2.xsd > ... <flex:flex-filter url-pattern="/messagebroker/*" /> ...Then I created a service as follows:
@Name("seamAboutService") @FlexRemote(name="aboutService") public class AboutService { @Logger protected transient Log log; public String getVersion() { log.info("aboutService Flex was invoked :) :) :) :) :)"); return "My Version"; } }My question is:
Do I need BlazeDS's war deployed in my weblogic? or jars? In case I need jar(s), which one? and for which version?
Look forward to hearing back from you,
Nico
Could someone from Seam answer David's question?
Is this flex integration going to be available in the Seam 3.0 version?
I wouldn't want to migrate my code to use Seam 2.2 branch when in Seam 3.0 something different is being done ...
Regards,
Nico
I second Nico's comment. Getting some sense of direction and availability would be very helpful. Also, as a matter of opinion, Flex adoption within Seam isn't going to get any traction until someone addresses the build / integration process. For the last two days I've simply been trying to integrate the GraniteDS flex-seam-tide example into a Maven2 build without any success. Why Maven over Ant? Because that appears to be the direction of the Seam development team and other groups in general. GraniteDS appears to be really nice, but struggling to get it to work within a production build environment (using Flexmojos) makes it non-viable (at least for me). Consequently, I'm going to fall back and check out the stuff that Norman has put together and see if I have better luck there.