machine501

Let me start by providing examples of Flex Framework Frameworks (FFF): Cairngorm, PureMVC (I know, it’s not just Flex), Mate, Swiz.  You get the idea.  All these frameworks provide ways to deal with Event Handling, Command or Action handling, ease separation of concerns so you can code in MVC, some provide inversion of control, or some combination of Enterprise Patterns.

Developers who are looking for a solution to bootstrap their application development are looking at the wrong abstraction level when they evaluate these frameworks.  You can’t base an entire application on just these frameworks.  If you do, you’ll be coding at too low a level.

What is needed is a library or framework above MVC, a framework that provides a core set of services that are present in most run-of-the-mill applications you’ll code in Flex, and a standard way for you to write your app on top of these services.

What’s a run of the mill Flex application?  I’m talking about business applications that may be deployed over a browser or in AIR and that allow the user to enter information in a form, to create a dashboard.  I’m not talking about other types of online apps like Blogs where you just read information and post (sure, there’s a form, but whatever), advertisement sites like movie websites (these mostly use Flash and are highly interactive but the focus is not to gather information from the user.   I hope you get the picture.  If I had more time I’d come up with a better bullet point list.

So, what are the base services for these applications?  I’ll try to describe them without resorting to Enterprise pattern names like Commands or Actions and just describe what I want my app to do.

I want to …

1. be able to have buttons, menu items, links, and other UI widgets through which the user can perform the same action.  So there might be an undo button, an undo menu item, and an undo menu item in a context menu and clicking or selecting it should execute the same action.  They should be enabled or disabled automatically for me, their visibility should be set to true or false automatically.  I should be able to declare their enablement/view states and their position on a toolbar or menu without my having to add any code or have any giant switch statements.
2. have undo/redo
3. handle long running operations with the ability to provide feedback to the user and the ability to cancel them
4. have the same button or menu option perform what seems like the same action based on what thing I currently have selected or what view I currently have selected
5. global item or resource selection handling
6. Modularity so that functionality can be added by providing another module and not by recompiling the whole thing
7. Context based action enablement

Ok, I’ll stop there because that last one is very jargony.  I’m basically talking about something like the Eclipse Rich Client Platform (RCP) but for Flex.  Moccasin, a Flex framework for graphical editor apps has history  management and editor functionality.  I want a library that goes further.

If you’re not familiar with the RCP, that’s OK, let me explain how this mythical framework might handle the features up there:

Commands and Handlers

The RCP has the concept of a Command, which is just a declaration of an intent to perform some action. It doesn’t actually do anything, it’s just a marker.  For example, “Cut” is a command.  It doesn’t actually know how to perform anything.

In order to actually do something you have to provide a Handler for a command and tell the framework when your handler should be invoked.  For example, let’s say your application has a tree on the left that shows a hierarchy of files.  And there’s a text editor on the right, which just shows the contents of the selected file.  If you currently have a file selected on the tree and you click on the “Cut” button then the Cut File Handler is invoked.  It knows how to take a file, delete it from the current location and store the contents in the clipboard.  If instead your text editor had focus and you had selected a piece of text then clicking on the Cut button would invoke the Text Editor Cut Handler which knows what part of the text is selected and can yank it out of the editor then store that in memory.

How did the framework know which handler to invoke?  When a handler is declared in the system you must also provide an “activate when” expression.  The activate-when for the Cut File Handler might be something like:

if Selection == Resource of type File

for the Text Editor Cut Handler it might be:

if selectedView == editor and and selection length > 0

Handlers can also be declared with “enabled-when” and “visible-when” expressions that allow the framework to dynamically, automagically enable buttons, menu items, links or whatever other UI widget is currently hooked up to a command, if the expression executes true.  ”visible-when” expressions would remove or add the widget if the expression were true.

That’s how we deal with 1, 4, and 7.

Undo/Redo – History Management

This one’s easy, but I haven’t seen any framework address it directly. It’s a pretty generic feature and even if your app is whiz bang it can still use the same basic generic solution.  The solution is simple:

Execute stuff in an undoable operation interface (call it IUndoableOperation).  Put it in some manager that has two stacks, an undo stack and a redo stack.  Implement an redo/execute method or methods and implement an undo method.

If you want to get fancy, use Undo Groups so that you can group together a set of operations that should be undone/redone as a group though each operation by itself may be undo/redone independently.  That takes care of 2.

In order to do this right in Flex, however, the history manager should anticipate having to perform its undo/redo/execute asynchronously because some operations may require network access and their completion can only be determined asynchronously.  Which brings us to my next topic:

Long Running Operation

In fact, the spark that started this post brewing in my head was when Ted Patrick tweeted about their being so many Flex Framework Frameworks.  The conversation turned into creating a library of useful patterns that Flex developers could use and feel confident in using them.  That the benefits it would provide would be to cut down on development because we wouldn’t have to reinvent the wheel, that we could share projects more easily because they wouldn’t depend on different libraries that performed the same thing though slightly different.

Anyway, one of the features or patterns requested was a way to perform long running operations, something that looks like threads (there’s a google code project for this in Flex).  I think this is a useful pattern that should be available in this framework I’m dreaming about.  And that there’d be support in the UI for monitoring its progress and canceling it.  It seems easy, have the method implement an ILongRunningOperation interface which can report progress as well as human readable information like the task it is currently performing.  This interface can take an IProgressMonitor interface object to which it can report its progress.

On the UI side, the framework can provide a simple, standard, sample progress bar that implements the IProgressMonitor and that is hooked into the Long Running Operation manager of the framework, so that all the developer has to do is declare a long running operation, give it to the manager, and the manager knows to perform this operation when all other ops are done, or maybe concurrently if the operation does not have to block.

That takes care of 3.

Global Resource Selection Handling

I’m not talking about the Flash global selection handler, I’m talking about a manager above that to which your views can set the selection of native objects in a standard way.  For example, if I have selected a node in the tree example above then the selection would show as an array of one object of type FileResource.  If I’d selected several nodes then the selection would be a flat list but would have an associated hierarchical selection.   If, instead I’d selected text in the editor it would be a one element array with an object of type TextRunSelection (or something) that encapsulated the start, end and any other attributes of the text.

This selection manager is an essential component that can be used by the command/handler framework when evaluating active-when, visible-when, enabled-when expressions.

That takes care of 5.

Modularity

This one obviously would use Flex modules at its core, but would add a layer above it that would provide the following:

Extension Points: Extension points are basically where you declare your application hooks and in which other modules or plugins can hook into to provide functionality.  An example extension point is an Editor, for example.  Let’s say that I can have different types of editors based on the extension of the file I have selected.  My main application would declare that there’s an extension point called editor through which other plugins or modules can add their own editors.

Extensions: These are the actual things that modules or plugins provide.  My XML editor plugin can provide an extension to the editor extension point that says: If you have selected a resource of type file with the filename ending in “.xml” then use this editor.

The framework would not provide a set of defined extensions, but just the ability to declare extension points.  And it would provide an easy way for applications to request what extensions are declared for some extension point.

If we wanted to get fancy, the plugin framework would allow the developer to provide all this in a plugin descriptor as well as initial proxy objects that would delay the actual loading or instantiation of a plugin until it was actually needed.  I think this level of delaying might not be desirable, however, as it would add a level of complexity to the extension user because they’d have to account for the asynchronous nature of module loading when accessing proxy classes.

One additional benefit of a layer above Flex modules is that developers would not have to worry about adding the latest best practices to flex module  handling that are discovered as bugs and other “features” of Flex modules pop up.  It would also relegate the need to deal with application security mostly to the plugin framework and away from the application developer.

That takes care of 6.

Stuck in the Weeds

My old business partner had a great expression: Whenever I’d start proposing solutions in terms of MVC or using httpservice vs. remoteobject he’d tell me: “Robert, you’re stuck in the weeds!”  It’s obvious what he means: I’m focusing too much in the details without stepping back and looking at the whole problem.  What am I trying to accomplish?

When I picked up Flex I started without a framework, then I started with Cairngorm.  The application grew in complexity and it seemed Cairngorm just made it too hard to keep going.  Then we stepped back and we thought about MVC and how we could use the basic stuff that Flex provided to code in MVC rigorously.  It worked, but we were still stuck in the weeds.  It was hard to add stuff to our application.  One sign of the problem with just thinking in MVC was that when we talked to the client they didn’t talk about views or models or controllers, they talked about editing things, loading resources, selecting stuff, undoing this, selecting that file, selecting this text.  Cutting and pasting that, adding a page.  (forget about use cases and user experience for now)

So I stepped back and started thinking about application level services.  I’d worked with Eclipse for a long time before Flex and I remembered how easy it was too think in terms of what the application does.  I’ve written some complex stuff in Eclipse and it wasn’t trivial but it was fairly easy.  Why couldn’t I do the same with Flex?

I don’t mean to say that the frameworks out there are focusing on the wrong things; they are targeted at the layer they are meant to target.  I think many Flex developers are stuck in the weeds, however.  They’re looking at the wrong level when they’re looking for a framework to build their apps on top of.  Where the focus is wrong, I think, is in the energy devoted to creating these frameworks and advocating their use as the solution to Flex application coding difficulties.

Why don’t I start this framework?  I may. I’m not sure what the level of interest is.  I felt the need to put this out there to see if I can make the case that the majority of Flex developers are stuck in the weeds.

Tagged: flex