Flex now is much for web development: we have OOP there, fine web-services integration, code and layout separation and more.
I personally think that the best way of creating web application is designing (or modeling) how it’ll look like for end-user, what and what it going to afford. So, let us think we already have some Flex web-application and going to connect it to some web-server to make it do something meaningful.
We have at least 4 options here, we can use:
- Custom XML-based HTTP service;
- Custom non-XML HTTP service;
- SOAP-based web-service;
- AMF (Adobe proprietary) based service.
1. Custom XML-based HTTP service
Flex will send HTTP request and receive XML answer like following:
<?xml version="1.0" encoding="UTF-8" ?>
<list>
<item product="Computer">
<UID>12321</UID>
<CPU>4Gh</CPU>
<RAM>2Gb</RAM>
<HDD>400Gb</HDD>
</item>
</list>
Pro here is that you can do comparatively small XML here (smaller that SOAP one).
Contra is that you are responsible for constricting XML on the server side and working with it (say, using DOM) on the client side.
It is rather inconvenient to do this additional work dealing with some XML structures, but many systems working just the way I described here.
2. Custom non-XML HTTP service
Similar to previous approach, but here you deal with yourself designed metadata like:
list[
Computer[
UID=12321
CPU=4Gh
RAM=2Gb
HDD=400Gb
]
]
It can be not so verbose as XML, but you now responsible for parsing your custom structures yourself. It has so many troubles that it even does not worth to be considered, unless you write system like AMF yourself.
3. SOAP-based web-service
Absolutely pain-free method, since now nearly all web-application frameworks has transparent built-in methods for SOAP based web-services. So does Flex. Troubles could begin here than you will experience high loads with crowds of users. Constructing and parsing big XMLs will kill your web-servers and channels. SOAP does best with heterogeneous systems integration like those used in b2b, but it is too heavy for ordinary web applications.
4. AMF-based service
Pros here comes form the nature of the protocol. It is fast binary over HTTP. Designed just for Rich Internet Applications. Why not to use proprietary protocol for communication with server if you already chosen proprietary Flex system to be used? The reasons could be: you don’t know how to integrate it in your server and you are afraid of possible troubles by dealing with proprietary technology. Here in this article we will consider both questions.
Let us be more exact. There are 2 versions of the protocol: AMF3 for Flex and AMF0 for Flash. So let us focus on AMF3 only (further in this article I’ll use AMF in meaning AMF3).
There are some frameworks for AMF: Adobe Flex Data Services (
http://www.adobe.com/products/flex/dataservices/), AMFPHP (
http://amfphp.org/), WebORB (
http://www.themidnightcoders.com/weborb/). May be there are some others. Frameworks are available for .NET, Java, PHP and Ruby on Rails. But I’ve found the only one available for Rails. It is WebORB. So further in this article I’ll describe my experience about dealing with WebORB plugin for Rails.
Flex and Rails
Good news is that Flex applications works fine with Rails via WebORB (see
http://www.themidnightcoders.com/weborb/rubyonrails/gettingstarted.htm how to use it). Bad one is that it conflicts with number of other plugins like act_as_attachment (we wrote workarounds by changing the WebORB plugin).
Sessions
Another inconveniency is that WebORB service classes which you write for your web services are plain classes, not inherited anything. So you don’t have those nice features like ones you have for your controllers or SOAP web-services. Therefore, your services are stateless by default, since they do not have access to the session object (HTTP session maintained via cookie). We wrote some utility classes and slightly changed WebORB to add session object. But you can choose to maintain session on the client side by SharedObject Flex class:
http://livedocs.adobe.com/flex/2/langref/flash/net/SharedObject.htmlFile upload
There are no obvious ways to upload file via AMF. The only way to upload by the Flex we’ve found was using FileReferenсe + URLRequest objects. There is some obstacle here. The URLRequest initialize another HTTP Session than AMF one’s. Therefore we can't identify user who make URLRequest on the server side. The workaround for this problem is to send additional information with URLRequest to make possible to identify user. Another inconvenience is that URLRequest can't get more than http status code as result (no messages or values).
Search Engine Optimization and mobile access
Search Engine Optimization (SEO) stays for providing readable HTML data for search engines like google.com, yahoo.com, and others. Usually the main argument against using Flash/Flex is absence of SEO possibility. But there is workaround for this issue. The trick here is that you can create simple xHTML site with all SEO information and then user load such page JavaScript will load your Flex on corresponding page. The big advantage of this approach is that it automatically makes your site available for mobile devices (WAP 2.0) if you use xHTML Mobile Profile DTD.
Types mapping
By tests we've found that it is the next (Flex <-> Ruby):
- int <-> Fixnum
- Numeric <-> Float
- Date <-> Time
- String <-> String
- Boolean <-> Boolean
Be aware, that if you choose ":decimal" type for database column it will not be mapped to convertable Ruby type and therefore not accessible in Flex.
There is interesting site concerning Flex and Ruby questions:
http://flexonrails.net/. I could recommend you to look throw this article:
http://www.flex888.com/2007/09/20/10-flex-and-ruby-on-rails-integration-examples.html and this one
http://webddj.sys-con.com/read/295396.htmGood luck!
