Easy In Place Editing with Apache Sling and jQuery jEditable

1. Download & reference jquery and jeditable 
2. Create a scriplet to be included

   $(document).ready(function () {
           $("[class^='edit']").each(function () {
                   var param = $(this).attr('class').substring(4).toLowerCase();
                   $(this).editable('<%=currentNode.path%>', {
                           type: 'textarea',
                           name: param,
                           submitdata: {
                                   '_charset_': 'utf-8',
                                   ':redirect': '<%=currentNode.path%>.html'
                           },
                           cancel: 'Cancel',
                           submit: 'OK',
                           event: "dblclick",
                           tooltip: 'Click to edit...'
                   });
           });
   });

3. Use this scriplet in your respective script file, and create an editable textare with a css class named  "editXY" where XY is the name of the property to be edited

       <div class="editProperty">
   
   <%=currentNode.firstname%></div>
   
     

That's it. The redirect doesn't work too well, but hey ... :)

Playing a website with JFugue

Ok, had to do this:



import org.jfugue.*

def munge(s) {
s.findAll { it ==~ /[A-Ga-g]/ }.join(' ')
}

String.metaClass.play = { new Player().play(new Pattern(munge(delegate.toString()))) }

"http://www.google.com".toURL().getText().play()



All credits go to transentia

Sling/Groovy Development with OSGI

After having evaded this whole OSGI/Maven topic, I think it is time that I delve into the whole issue. Lars Trieloff and other helpful people alredy gave me a hint about when to change from webdav/scripting mode to OSGI/Maven bundles.

After several hours and reading several blogs and webpages, I came up with the following pom.xml:



<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>SlingControlmanagement</groupId>
<artifactId>SlingControlmanagement</artifactId>
<version>1.0</version>
<packaging>bundle</packaging>
<build>
<plugins>
<!--
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-scr-plugin</artifactId>
<version>1.0.8</version>
</plugin>
-->
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Export-Package>
test;version=1.0.0
</Export-Package>
<Bundle-SymbolicName>controlmanagement</Bundle-SymbolicName>
<Bundle-Name>controlmanagement</Bundle-Name>
<Import-Package>
org.osgi.framework;version="1.3.0",groovy.lang;version=1.6.0,org.codehaus.groovy.reflection;version=1.6.0,org.codehaus.groovy.runtime;version=1.6.0,org.codehaus.groovy.runtime.callsite;version=1.6.0
</Import-Package>
<Sling-Initial-Content>
SLING-INF/initial-content/libs/myapp;overwrite:=true;path:=/libs/myapp
</Sling-Initial-Content>
</instructions>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.sling</groupId>
<artifactId>maven-sling-plugin</artifactId>
<executions>
<execution>
<id>install-bundle</id>
<goals>
<goal>validate</goal>
<goal>install</goal>
</goals>
<configuration>
<mountByFS>true</mountByFS>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.groovy.maven</groupId>
<artifactId>gmaven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>generateStubs</goal>
<goal>compile</goal>
<goal>generateTestStubs</goal>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
</plugin>

</plugins>
</build>
<repositories>
<repository>
<id>apache.incubating</id>
<name>Apache Incubating Repository</name>
<url>http://people.apache.org/repo/m2-incubating-repository</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>apache.incubating.plugins</id>
<name>Apache Incubating Plugin Repository</name>
<url>http://people.apache.org/repo/m2-incubating-repository</url>
</pluginRepository>
</pluginRepositories>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>1.6.3</version>
</dependency>
</dependencies>
</project>


There are several things to point out:

1. I am by no means a OSGI/Maven expert, so consider this to be a first draft
2. the commented out scr plugin is used for declarative OSGI services, details here.
3. the groovy version used for compilation (1.6.3) and within OSGI (1.6.0) are different. This might lead to problem. Best thing to do would be to reinstall groovy-all.jar into the OSGI environment
4. the "Sling-Inital-Content" tag is a convenience used to supply initial content to sling
5. the <mountByFS>true</mountByFS> tag should theoretically allow to have all changes done within the filesystem be propagated to sling. Doesn't work atm, although, unsure why
   
   

So where in REST is the MVC?

Still trying to get my head around REST. Looking at sling, I do see two different approaches:

• view/model combined: a resource is represented by a markup (html), which contains both view and model information. The controller (browser) is responsible for the correct representation and the hypermedia functionality (hyperlinks, forms), which allows navigation and manipulation of the represented data
  
• model exclusively: the resource is represented by a data structure (json), which is both rendered to the controllers (browser) taste as view

Now, from a design point of view, the second one seems cleaner, and very compatible with the MVC pattern. But the first approach is the one the web is build upon, soooo there has to be something about it ...

The idea spinning around in my head is to implement the first approach with Griffon and Sling: Sling will deliver SwingBuilder fragments which then will be interpreted by Griffon. Stay tuned...

Apache's mime-type list

Just stumbled on this while reading the sling mailing list:

Apache's web server default mime-type list, together with associated extensions: might come handy, includes the relevant RFCs in the comment

This must be the quote of the week

Having read the (german) news post on heise.de
regarding the issue of prodcut piratry one quote struck me:
According to the article (no source is quoted there!), Peer Laslo of SAP is supposed to have made this statement:
" ...
Wir sind nicht betroffen. Unseres Software ist so kompliziert, dass man sie schlecht fälschen kann.
..."

eng:

"...
We are not affected. Our software is that complicated that it hardly can be imitated.
..."

Now, I do not have any context information for this statement. Put like this, it sounds really weird. And wrong too: A software can simply be pirated by copy and paste, or reverse engineering.

So the only thing protecting this particular product is the complexity to enhance/change and lastly to use it. Looks like not only security but whole businesses can be built with obscurity in mind....

Deploying a Groovlet Application to the AppEngine with AntBuilder

Just a quick & dirty info: you can easily use the already defined tasks for Google AppEngine with your Groovlet-based application (as described by Guillaume Laforge on his SpringSource blog)



def ant = new AntBuilder()
def webinf = "war/WEB-INF"
def aesdk = "appengine" //change this to the location of AppEngine SDK

ant."import" (file: "${aesdk}/config/user/ant-macros.xml")
ant.sequential() {
taskdef name: "groovyc", classname: "org.codehaus.groovy.ant.Groovyc"
groovyc srcdir: "src", destdir: "${webinf}/classes", {
classpath {
fileset dir: "${webinf}/lib", {
include name: "*.jar"
}
pathelement path: "${webinf}/classes"
}
javac source: "1.5", target: "1.5", debug: "on"
}
copy toDir: "${webinf}/groovy", {
fileset dir:"groovlets"
}
if(args.find{it.startsWith("-u")}) {
appcfg action:"update", war:"war"
}
}


Please note that appcfg is a task defined in the GAE SDK. By importing the relevant xml file (and having the respective jar files on classpath), this and all other ant tasks become available to groovy scripts.

If you run this script with "groovy build -u" 3 things will happen:

1. all stuff in "src" will get compiled
2. all stuff in "groovlets" will get copied over to the appropriate directory (no need to compile those, if you follow Guillaume's hints regarding web.xml configuration
   
3. all stuff will get pushed to the AppEngine

If you use strictly Groovlets, nothing needs to be compiled and step 1 might become obsolete.

What is your LOCBUT?

How many lines of code do you write before having the urge to test if it is working? Does this count go up or down when you know that there are solid tests backing it?

For me personally, it is about 5, and going down if tests are around.

I have of course no metrics, but I have the feeling that this is not depending on the programming language. Which leads to some interesting conclusions:

• strive for fast round-trip cycles in your development process
  
• prefer expressive languages which allow to more in less LOC

Checking the Radar

Well, about time this blog gets some content added.

Quick check on my radar: what technologies am I watching, where they are heading, what else I would like to have a look at etc.

Tapestry:
Wasn't able to play around with it. Currently V5.0, looks very very good, but I will take it off the radar, since I do not see an opportunity to test it out.

Grails:
About same as Tapestry. I personally would choose one of those two as Web Framework.

Groovy:
This has become my home language. Just makes sense. Just good. Use it. Will be on Main Road by 2011 (and might get boring then :))

Sling (and Jackrabbit):
Still much work going on there. Sling (and Jackrabbit) are not only superb technologies, but more than that, have become inspiration for modeling content and thinking about data and their respective handling.

Griffon:
Everyone and their mum does that AJAX-Flex-JavaFX-RIA-thingie. Everyone? No, there are some stubborn, backward-oriented guys (did not spot any ladies up to now), which, basically, say, screw it: we are doing SWING! Yeah baby. Do it right by using Groovy, be inspired by Grails, and well, use some major brain power. This one is hot, mark my words...

What are possible new candidates for the Radar?
Well, there is Clojure, but I do not yet have any use case for it at the moment. I will first read the book. Suggestions welcome...

Apache Jackrabbit 1.5

Apache Jackrabbit was just released in version 1.5.

It looks that this is the "yes, we heard you" release, and is a huge jump forward for straightforward usage:
1) grab the jar-file
2) java -jar jackrabbit-....jar

And... there is no step 3 :).

I can't stress out enough the importance of such easy usage. While it already has been more or less simple to use Jackrabbit in, say, semi-professional setups, it now has the chance to hit the Main Street. "Want webdav? Well, you'd better use that jackrabbit thingie".

Ok, there may be some steps 3, but I will write about those later

Fun with annotations in Groovy/Griffon

The 1.6 version of Groovy seems to have full-fledged annotation support.

I took the occasion to finally learn to create some annotations on my own, and wrote an annotation which can be used in a Griffon model to give the controller some hints about how to best display its data.

I might have taken this a little bit too far, but it is also possible to declare strings in annotations which can later be evaluated.

Take this annotation as an example:


package annotations

import java.lang.annotation.*

@Retention(RetentionPolicy.RUNTIME)
public @interface TableModelInformation {
boolean displayed() default true
String displayName() default ""
String displayValue() default ""
}


This can be used in the model like this:


...
@TableModelInformation(displayValue='"Total Subprocesses: ${object.subprocesses.size()}"')
List subprocesses = []
...

(Note the weird string syntax: only double quotes (i.e. GString) are rightfully not interpreted as Strings. Furthermore it expects to receive an instance of the object in a variable named (tadaaa) "object".

This can be evaluated later in the controller:

return new GroovyShell(new Binding([object:object])).evaluate(object.class.getDeclaredField(field).getAnnotation(annotations.TableModelInformation).displayValue())

("object" and "field" are available in the context of the controller)

I am not sure how to optimize this code, especially the verbosity of annotation retrieval. It nevertheless is kind of funny to see groovy behavior in an (at least from me) unexpected way...

Using ocmgroovy as Persistance Layer for Griffon

Griffon is a very interessting approach to create an agile and fun framework for building Swing applications. Currently a very shy version numeration is used (0.0.1 is current), but the whole package is built using large know-how.

One thing missing is the persistance layer. It is planned to use GORM, the hibernate-based layer of Grails.

This situation is an opportunity for ocmgroovy, my "framework"(*) for persisting Groovy objects into a JCR. While beeing a little ugly hack atm, the basic things like save() and get() seem to work, at least for my basic test cases.

Using ocmgroovy in grails is one annoying and 2 easy steps

1. download ocmgroovy (either create the project via pom.xml or download all dependencies manually, which basically means to download all jackrabbit dependencies and xstream with its dependencies) and install it into {griffon_project}/lib directory
2. declare the class to be persisted in {griffon_project/lifecycle}/Startup.groovy
3. use it in your Griffon mvc
   

Step 2 looks like this

TransientRepository repository = new TransientRepository()
def session = repository.login(
new SimpleCredentials("threatmanagment", "password".toCharArray()))
JcrPersister strategy = new JcrPersister()
strategy.session = session
strategy.instanceRoot ="threatmanagment"

strategy.instrumentate(ThreatModel, "name")
strategy.instrumentate(Dataflow,"id")

This makes model classes ThreatModel and Dataflow persistable, i.e. currently mostly adds save() and get() methods to instance and class, respectively

And Step 3: about as easy

ThreatModel model = new ThreatModel("name": "TestModel")
model.save()
...
ThreatModel model2 = ThreatModel.get("TestModel")

Please note that this is all very shaky at the moment (and therefore will create a black hole if you try it at home ;)), but might prove usable in the future.

I probably will release a PoC-project in the near future.

===
(*): ocmgroovy is very alpha and only used by myself. Therefore I do not consider this to be a framework

Ditching Flex ... for now

Well, killing another fairie: I am dissing Flex for my pet project. There are several reasons:

1. not too good Flex-Support in IDEA
   
2. roundtrips are slow (create compile load)
   
3. open source built on closed source doesn't work
4. mxml: simply don't like those
5. actionscript will not be the next ecmascript
6. verbosity: too much to write while using MVC frameworks. Convention over Configuration is not there yet (?)
   
7. HTTP support is kind of crippled
   

There are very good reasons to love Flex:

1. the looks: I am no expert, but I got the feeling Flex just looks great out of the box
2. components: component based UIs are great.
   
3. event models
   
4. ubiquity

I am sure that some of the points are due to the fact that I am a novice. I might come back to it, but now it is time to move on...

An "in between" review of Sling

Now that I have been using Apache Sling for a pet project for some weeks now, I thought I could share some insights on it. The spaghetti western way, of course :). And all utterly subjective.

The Good

• java -jar sling.jar -> http://localhost:8080 and dav://localhost:8080. This is fantastic.
• Scripting support
  
• REST: learn it the Sling way
  
• webdav-support
  
• A good community
  
• best-of-breed technologies: OSGI (with Felix), JCR (with Jackrabbit)
• JCR muscle flexing included: query, hierarchies, versioning
• semi-structured data approach
  
• it's fun
  

The Bad

Nothing bad, just great stuff with some edges:

The Ugly

• Docu. Yeah I know. Is getting better, but should be more (please kill those "out of sync" pages)
  
• After a fast start, there still is a learning curve (OSGI, REST, JCR, Maven, ...). Since these are hot topics anyway, this is no big deal, expect when you want something fast and nownownow :)
  
• bootstrapping problem: despite the available help, I still did struggle with the question whether controls (scripts) or data should be created first. But this is just me, I guess :)
  
• JCR Editor support: Days eclipse plugin is great, but unfortunately doesn't work on my Ubuntu-system
• No out-of-the-box solution for rich applications (Except dojo, which is a beast on its own...)
  

All in all, Sling holds its head up high in a tight, competitive market. I am looking forward to do more stuff with it. The rough spots are being addressed, therefore I am positive and quite impressed. Most important thing now would be to flesh out the documentation....

update 13th Sept: The JCR Plugin for eclipse works after a fresh install, using Eclipse Ganymede and JCR Plugin version 3.6.6. Nice thing is, that Eclipse editors seem to work, e.g. when editing a HTML file. Have to check if this works with the groovy editor too ...

Flex/Flash wasn't made for REST

Well, it did take longer than others, but I finally got the message: Flash was not built with HTTP in mind. There are other issues flying around, but I think it all boils down to HTTP not being treated as first-class-citizen in the Flex/Flash environment.

I guess that the reason is a historical one: all remote connection protocols where proprietary, only in the last years Adobe opened itself a little bit (by releasing BlazeDS and open sourcing Flex). Now I think Adobe should go 2 steps further:

1. implement standards (e.g. using HTTP how it was meant to be used)
2. open source the whole stack

This is highly speculative, but perhaps the "Nay" to EcmaScript4 was due to the apparent closeness of the Flash ecosystem.

The saddest thing is that Flex is great! Real good default (looks nice out of the box), a real component model, just plain fun! Next stop: Dojo, I think ...

Using Groovy Builders in Sling

Sling is a new approach in web development. It is, amongst other, a thin REST layer onto a JCR repository.

Sling also makes use of the language neutral scripting features of the java platform. Out of the box, several scripting languages are supported, like javascript and jruby. Since Groovy does have JSR 223 support, it is rather easy to create a groovy module to be used inside Sling. The only pity is that the Groovy Scripting Engine is not available via maven. See this Jira issue for some hints on creating a Groovy OSGI-module for Sling.

The thing I like most about Groovy is the real cool builder support. Using the MarkupBuilder, it is a snap to generate HTML or XML documents. I personally started to like MarkupBuilder syntax more than the templating approach.

The first time I saw something similar was at a demonstration of the excellent Seaside framework, where everything, including layout, is done in smalltalk. I am not sure wether the Groovy builders have been inspired by smalltalk or even Seaside, but both are sexy (I cannot speak for Seaside, haven't had the chance to play with it).

Anyways, on to some comparisons:

First a piece of jsp:


<%@page import="javax.jcr.query.Query"%>
<%@page import="javax.jcr.NodeIterator"%>
<%@page import="javax.jcr.Node"%>

<%@taglib prefix="sling" uri="http://sling.apache.org/taglibs/sling/1.0"%>
<sling:defineobjects/>
<div class="blueprint detail">
<a href="">.details.html"><%= currentNode.getName() %></a>
<h2>Properties</h2>
<h2>Controls</h2>
<div id="List">
<%
String q = "/jcr:root"+currentNode.getPath()+ "//*[@sling:resourceType='secmanagment/control']";
Query query = currentNode.getSession().getWorkspace().getQueryManager().createQuery(q, "xpath");
NodeIterator result = query.execute().getNodes();
%>Total <%=result.getSize()%>
<ul><%
while(result.hasNext()) {
Node n = result.nextNode();
%><li><%
out.flush();
sling.include(n.getPath() + ".overview.html");
%> </li><%
}
%>
</ul>
</div>
<div class="new">
<form action="">/controls/" method="POST">
<input type="text" name="name" value="Name">
<input type="hidden" name="sling:resourceType" value="secmanagment/control">
<input type="hidden" name="jcr:primaryType" value="nt:unstructured">
<input type="submit" value="create">
</form>
</div>


The same using Groovy with MarkupBuilder:

import groovy.xml.MarkupBuilder
import javax.jcr.query.Query
import javax.jcr.NodeIterator
import javax.jcr.Node


def q = "/jcr:root${currentNode.path}//*[@sling:resourceType='secmanagment/controls']";
def query = currentNode.session.workspace.queryManager.createQuery(q, "xpath");
def result = query.execute().nodes;

def builder = new MarkupBuilder(out)
builder.div(class:"blueprint detail") {
a(class:"blueprint details", href:"${currentNode.path}.details.html", currentNode.name)
h2("Properties")
h2("Controls") {
ul(class:"List") {
result.each { node ->
//this is necessary: need to put the outer tags explicitely
mkp.yieldUnescaped "<li>"
sling.include(node.path)
mkp.yieldUnescaped "</li>"
}
}
h3("Create new")
div(class:"new") {
form(action:"${currentNode.path}/controls/", method:"POST") {
input(type:"text", name:"name", value:"Name")
input(type:"hidden", name:"sling:resourceType", value:"secmanagment/controls")
input(type:"hidden", name:"jcr:primaryType", value:"nt:unstructured")
input(type:"submit", value:"create")
}
}
}
}



While not being too different, those 2 samples (hopefully) show the usage of MarkupBuilders as valid alternative to a templating engine like jsp or gsp.

Oh what irony

So, after some years of java-programming I am getting used to dynamic, loosely typed languages, walk like a duck, y'know the drill.

Then enters Flex, enters AS3 and you know what? Explicit type declarations all the way (Not mandatory at all, but, you know, the compiler complains and stuff, so you better behave...)

This is not a problem and all, but something about the whole thing just made me smile :).

Controls Managment Project: Desiding for JCR/Sling

I am pondering for a half year on the idea of creating a piece of software which allows to manage (security) controls. There are several programs which allow to manage risks, but they assume the existence of a complete business services catalogue, broken down to hardware installations and software instances. Which I do not have atm.

What we do have is a set of controls, together with measures which describe how to implement those controls. The very basic model is:

1 control <-> m measures
1 measure <-> m implementations

A set of controls can be packet together in a workbook (haven't found a better word for it), which then can be assigned to someone (e.g. infrastructure guys) to define the implementations and their respective fulfillment.

This is all kind of vague, and it will probably will remain to be vague and not 100% defined in a strict (relational) domain model. It might for example be possible that some controls have more attributes than others. This is of course possible to be modeled with object compositions, but this is always the point where ORM starts to produce to much friction heat...

And this vagueness is imho a indicator for the need of a kind of semi structured data model. And this again is a good sign for using the data first approach: use the hierarchy as structuring model, and, well, see to more structure later. Maybe :). Therefore JCR is the weapon of choice....

As for Sling: I am still completely indecisive regarding the right client technology. Therefore it makes sense to have a REST-full interface to the business domain.

And Sling is sexy. Want to use it. 'Nuff said.

Next steps would be to answer some questions regarding Sling development. Currently I am scouting the message boards and the (way too sparse) documentation...

• what's the best way to setup a Sling project? Use webdav for deployment?
  
• How to backup/restore work?
• How to design a JCR/Sling project? Top down? Paralell development of content model and functionality?
• OSGI Best Practises
  
• Which client-side technology to choose?

A first view at Sling

Sling is, well Yet Another Java Web Framework. But it adds some unique aspects, which might turn out to be a game changer:

• it focuses on resources
  
• it uses JCR as backend API (see jackrabbit as implementation)
  
• it adds a thin layer of REST over JCR
• it adds a dash of custom behavior by allowing dynamic languages (javascript, jruby, amongst others) to manipulate the REST request processing flow
  
• it uses OSGI and its plugin-mechanism for more heavyweight and/or integration stuff

Besides being rather hype compliant (JCR, jruby, osgi, REST, thank you), the most interesting feature is that it's inspiring: it makes me think, and this in a constructive way. It kind of makes REST more approachable as an architectural style rather than a framework.

In a sense, it is like learning a new programming language: it opens your horizons, and questions some established thought routines.

Go ahead and check it out, it might trickle in...

Grails, Flex, Soap

Today I have written a small PoC for Grails, Flex, SOAP. The initial task was (and still is) to find out which communication takes place in a Flex application.

Having no clue about Flex, a little understandig of Web Services and some minor understanding of Grails, it took me no more than 3 hours, including googling for web service usage in Flex and hunting of really stupid beginners bug.

This shows the real muscles of Grails and its really awesome plugin ecosystem.


grails create-app HelloFlex
cd HelloFlex
grails install-plugin flex
grails install-plugin xfire
grails create-service hello

Ok, everything needed is installed. 2 more things to do. in HelloFlex\services\HelloService.groovy:

class HelloService {
static expose=['xfire', 'flex-remoting']
def hello(String echo) { return echo.reverse() }
}


Note the use of expose: this service is both available via flex-remoting and via SOAP.

Second: create HelloFlex\web-app\test.mxml


<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
<mx:WebService
id="userRequest"
wsdl="http://localhost:8080/HelloFlex/services/hello?wsdl">
<mx:operation name="hello" resultFormat="object"
fault="mx.controls.Alert.show(event.fault.faultString)"
result="showResult(event)"/>
</mx:WebService>
<mx:Script>
<![CDATA[
import mx.rpc.events.ResultEvent;
import mx.rpc.events.FaultEvent;
import mx.controls.Alert;
[Bindable] private var passage:String;
private var options:Object = {"output-format": "plain-text"};
private function showResult(e:ResultEvent):void {
passage = userRequest.hello.lastResult;
}
private function send_data(input:String):void {
userRequest.hello(input);
}
]]>
</mx:Script>

<mx:Text text="Echo Service" fontSize="16" fontWeight="bold"/>
<mx:Text text="Input" fontSize="12"/>
<mx:TextInput id="lookupPsg" textAlign="center"/>
<mx:Button label="Submit" click="send_data(lookupPsg.text)"/>
<mx:TextArea height="352" width="590" id="psg" text="{passage}" editable="false" fontSize="11"/>
</mx:Application>

(sorry for the mess, dunno how to format this better )

Hitting http://localhost:8080/HelloFlex/test.mxml displays the Flex application which uses SOAP protocol to consume the webservice.

Built on the shoulder of giants...

Update 12th Jul: Marcel Overdijk has already written a similar (well, actually better:)) example back in january.