We have a client with a slick-looking Flex GIS client. All good, but now they want to add editing to the mix. Editing with Flex isn’t until 9.4 (why is it that every feature you ever want is in the _next_ version?), which is out of the timeframe for delivery so we’re stuck between a rock and a hard place; the stubborn rock of the ADF and the hard place of writing product where there is none in Flex/WCF/SOE.

ADF is pretty well documented. For Flex we would have to have an architecture like so:

Flex <-> WCF <-> EditingSOE <-> Nonversioned / Default Geodatabase

Flex Woes

Here are just some of my Flex editing woes :

1) We have committed to doing job workflow for approving etc (e.g. using M&M SessionManager/ESRI JTX or Workflow Foundation). This is a major headache because it implies that we will be doing versioned editing. The REST API does not give you the ability to switch versions on-the-fly. With a stateful mapserverobject accessed by the ADF you can create/change versions.
2) Client-side editing (i.e. manipulating graphics) in flex might involve some effort without the help of an esri library. [Glenn has found this
http://thunderheadxpler.blogspot.com/2008/12/editing-graphic-geometry.html]. Second biggest woe under this heading is undo-redo.
3) Tight time constraints, the ADF editing is pretty much out-of-the-box. How long will flex editing take to implement?

Elephant in the Room

And here, for completeness, is the elephant in the room (ADF):

1) Expectation set by delivering a Flex client of a responsive, AJAX-y interface without fuss. ADF is a lumbering fool.
2) Getting the existing Flex interface to seamlessly integrate with ADF.
3) Ongoing reliability concerns, issues with stateful services.

Time to get prototyping…