Viewing all posts tagged "flex"

Flex State Machine Release 0.1

http://github.com/visfleet/FlexStateMachine

I’ll call this the first release :)

Flex state machine is my attempt at getting a domain specific language (DSL) for state machines into Flex.

It’s missing a vital ingredient (to my mind), which is the ability to mix events and ‘cans’ (State events, not the Flex observer pattern) into another class instance.

The kludgy:

controller.machine.start()

should be replaceable with

controller.start()

I just need to take a closer look at the EventDispatcher mixin mechanism and see if I can use that to implement a ‘method missing’ solution that will at least work with controller/model/facade classes marked as dynamic.

Despite this annoyance, I love this class and it works beautifully in our production code. Please give it a whirl and feedback/fork away.

Posted 2 years ago by visfleet

Comments

Tags: flex, state machine, flexstatemachine,

Robotlegs. What I’m falling in love with.

Background

I just thought I’d comment on my latest endeavor at Visfleet. I’ve been a little worried about my cobbled together framework for our Flex codebase. It was designed and added too from the day we started with Flex 2 and hasn’t had a proper review since. It works, and we have workable code, but I find that the developers here have the same trouble using it over and over again. So I identified my biggest ongoing concerns:

Hard to Test Code

Sure some unit tests could be attached, but I use registries and locators for dependency injection. There are some really nice DI frameworks around now, it’s time to use one.

Sloppy Inversion of Control

IOC is sloppy due to many levels of inheritance. I use inversion of control by means of placeholder virtual methods, which after one level of inheritance still leaves us with a “call super” anti-pattern. Or with the need to add more virtual methods. I’d rather just not depend on inheritcance so often.

Namespace polution

There’s no convention in my current framework that makes enough sense when it comes to naming and positioning classes. I see Rails apps that do this so well and I get envious. Can haz conventions?

Service and Model mixed

Just don’t know what I was thinking. In the days of the mostly read only API (iVistra’s focus on visualization) I could get away with a “ListLoader” class that maintained a canonical representation of server side data using a limited CRUD command set and RESTful view of the data. RESTful is a great place to start with any service, but I think you’re a fool if you try to ‘Resourcify’ everything. It’s definitely not pragmattic, and it’s often not practical either.

[robotlegs]

This is robotlegs. Currently the documentation is a little confused about what Robotlegs is (or I find it confiusing). But here’s what I’ve gleaned from Shaun Smith (inventor) and Joel Hooks (major contributor):

[robotlegs] the DI automation framework

Robotlegs is a framework for the automation of Dependency Injection. It should be possible to plug any DI framework into it. At the moment, SwiftSuspenders is the only one successfully and completely “adapted”.

To quote Shaun:

Robotlegs aims (and does not succeed 100%.. yet) to be a set of tools for automating DI and nothing more. It’s not a DI framework itself.

It provides:

A CommandMap - for instantiating, injecting and executing Commands triggered by an EventDispatcher.

A MediatorMap - for instantiating, injecting and registering Mediators as view components arrive on stage in a given context

A ViewMap - for injecting directly into view components as they arrive on stage in a given context

SwiftSuspenders

SwiftSuspenders is a simple and fast DI framework. It uses very little metadata but I find it very effective. Just try it, even if you don’t use RL, it’s so simple and effective.

[robotlegs] MVCS

Let’s call this RL-MVCS for the purpose of this discussion.

This is a reference implementation MVC framework written using Robotlegs. This is where most of the confusion arises.

When you look at Robotlegs demos, it’s usually RL-MVCS. When you look at Robotlegs discussions, it’s often about RL-MVCS. When you read the best practices documentation, it is entirely about RL-MVCS.

That said. I really like this implementation. The only thing I’d like to see made simpler is the idea of “sub contexts”, which I use for separating components and for separating modules, where a module is a largely separate “application domain”.

What [robotlegs] Addresses.

Returning to my concerns for my current framework, SwiftSuspenders adresses my sloppy IOC and DI issues directly. [robotlegs] the DI framework is even better though because:

I get the ability to switch to a different DI framework (although I might have to write the adapter).
I get an easily introduced mechanism for adding DI to my existing MVC implementation.
I get documentation, open discussion and an open convention.

The conventions would help me improve my namespace pollution issues, but I’d still need to do a lot of work and document it myself. Ditto for the service/model coupling I have.

So this is why I love RL-MVCS, I get all of the RL-DI improvements plus:

An MVC implementation that has examples, open convention, and open discussion.
A thoroughly well thought through best practice guide.
A framework based entirely on OO best practices. It’s actually quite hard to cut corners with RL-MVCS.
Conventions that pry my classes apart until they are testable.
Conventions that let me readily reduce my long inheritance chains through DI.
Nice examples of working projects with tests in place (but not compiled into the final product, Yay!)

Also, I’ve edified myself on RL-MVCS by picking one system component of our application and only implementing it there. So right now, I have my own application mostly untouched, with just one little corner of it’s world implemented in RL to prove its value. It’s no mean feat for a MVC style framework to be able to work so readily inside another.

Posted 2 years ago by squeedee

Comments

Tags: flex, robotlegs, swiftsuspenders,

Mediating ItemRenderers

ListBase, what it is and is not.

The ListBase classes are containers. In their simplest form, they mimic a typical OS list. In this capacity they work fairly well, and I see very little reason to mediate ItemRenderers. But they can be used for things far outside the scope of a typical list. This other use, I will refer to as the “Optimised Continuum Container”. Cool name eh? :)

Continuum Containers.

A “Continuum Container” is any container that presents a collection (the continuum) along an axis (1). VBox and HBox are prime examples. When the continuum get’s long, we need a scrolling mechanism to present the continuum to the user (2).

When the continuum gets very long, we need to ‘Optimise’ the container such that it only instantiates enough children to represent what’s on screen (3). That’s what the ListBase classes do.

A UX decision

We decided that we wanted to present a list of items to the user in such a way that common goals (actions upon the items) were easy to find and use. Lets say its an employee list. Here’s a typical implementation of a list, with actions associated:

Maybe not too typical, this obviously has some design challenges. Common actions for a list item should be readily locatable. One way of doing this is shown above, you keep the actions still (motionless, in one obvious place), and you select the item upon which to act.

When your list window gets large, as ours often do, the travel time with the mouse to the action items becomes frustrating and can cause disorientation. So what we do is (and you’ve seen this many times before) is to group the actions with the list item:

Not a typical ListItem

So suddenly we don’t have typical list items. Each list item has more than one “concern” now:

Present the name
Present the state of “in/out”
Accept input to change “in/out” state
Accept input to launch the editor
Accept input to edit the item
Accept input to launch an email window

It get’s even more complicated when there are modelled conditions that lie outside the VO, for example, if the user does not have permission to send emails from the application, we don’t want to show the email button.

I personally believe that these concerns should be seperate. When I first saw an example of a view-mediator tuple for a single button, I thought “What horrendous overkill”. Now I’ve been Robotlegging it for a while, I can’t imagine a life less granular, and I always try to get my view/mediator “concern count” near to 1.

If you don’t agree with that last paragraph, then you won’t need to mediate ItemRenderers.

The view for my list item in that example includes several child views (and mediators) for each button. This is so clean and simple to refactor, and to read, that I would not have it any other way (pragmatically speaking).

Mediating ItemRenderers

ItemRenderers and ItemEditors lead a fragile existence and are not straight-forward to mediate. This does not mean you can’t mediate them, it means you must know your enemy.

ItemRenderers are re-used.

So when an item goes off the list, it’s renderer does not get destroyed, instead the ‘data’ property is set to a new item and the renderer is moved into place on the list.

This means that you can’t simply rely on instantiation and the event bus to observe when you need to mediate your view. You need to also watch the data property. That’s not so hard now is it?

Typically when you mediate, you establish state on instantiation (if necessary) and modify state as changes come off the event bus (and binding). This means that you establish an accurate reflection of state by knowing the previous “reflection of state” was correct

That’s what makes ItemRenderers a little harder, you need to reset state more often, and there are more gotchas.

For example, when we save an edit on a list item, we tell the Renderer (not the editor) to switch to a busy “spinny circle” state. If the item goes off screen, the Renderer get’s reused for something else, and we must reset it’s state such that it doesn’t look busy. If the item comes back on screen while still saving to the server (hello New Zealand ping times), then we need to reset it’s state to busy.

I’ll try to write a follow up article on best practices for resetting ItemRenderer state.

ItemEditors stand in for renderers.

When an item is editable and the user begins an edit, the ItemRenderer is hidden, and a new ItemEditor is instantiated. This means that whatever mediation you use for the renderer, may well need to be duplicated for the editor. I keep these concerns seperate and look for common code via common refactoring methods (extract*).

Stick with the basics.

Despite all this, we do have a simple set of rules we always follow, no matter the renderer. I’ll spell them out here, and in my next article I’ll show some working code.

Use the VO dependency provided by the list (.data property)
OnItemEditBegin and OnItemEditEnd are handled at the parent (list) mediator.
When an edit begins (OnItemEditBegin), our list mediator asks the model for an editable VO and provides that to the list in place of the original VO.
When an edit ends (OnItemEditEnd) the list mediator issues a command to save the modified VO. This keeps us canonical with the server/services.

Posted 1 year ago by squeedee

Comments

Tags: Robotlegs, flex, mediator, itemRenderer,

Verbose is a dirty word

I’m not saying verbose should be a dirty word, just that it does have a pejorative meaning. If you’ve used *nix command line tools often enough, you’ll know that -v is often used as a flag for “verbose”. This usually ends up in some useful information coming out of the log or stdout. -vvv usually means “very verbose” and too much information pours out to be of any use. And this is the risk:

If verbose is your end-goal, then the more verbose you are, the better.

Right? I mean that makes sense. If “quality” is your end-goal, then more and more quality is a thing to strive for. Same goes for “agile”, “fair”, “loyal”, “just”. All these words suggest that the more you pile it on, the better. This is not true of verbose. Keep getting verbose, and in fact, you just get more noise.

I’m probably nitpicking this to death, but I’m only doing so, now, because I think I have a better quality to strive for:

Expressiveness

Really in our code, we wan’t to be more expressive. We want every line we read to convey it’s meaning.

If you check out expressive at dictionary.com there’s also a nice set of synonyms:

Synonyms: These adjectives mean effectively conveying a feeling, idea, or mood: an expressive gesture; an eloquent speech; a meaningful look; a significant smile.

I think eloquent is a good word too, it usually conveys meaning in a terse manner. That’s right, less verbose, just enough meaning and no more.

Readable Code

This code is readable, but not expressive:

public class EmployeeModel {
    ....
    public function save():void {
        if ((editingEmployee.name.length > 0) && (employees.checkUnique(editingEmployee.ssid))) {
            employees.comit(editingEmployee);
        }
    }
    ...
}

Expressive Code

So now I refactor it.

public class EmployeeModel {
    ....
    protected function employeeIsValid(employee:EmployeeVO):Boolean {
        return ((employee.name.length > 0) && employees.checkUnique(employee.ssid))
    }

    public function save():void {
        if (!employeeIsValid(editingEmployee)
            return;

        employees.comit(editingEmployee);
    }
    ...
}

I use a guard clause for starters because they convey intent more clearly.

Then I extract the method (all praise ctrl-alt-m in IntelliJ IDEA) employeeIsValid(). This gives the guard more meaning, and also gives the extracted condition more meaning. It’s a win-win.

Verbose Code

Now, is this the following code more expressive or more verbose?

public class EmployeeModel {
    ....
    protected function employeeNameIsValid(employee:EmployeeVO):Boolean {
        return employee.name.length > 0;
    }

    protected function employeeIsValid(employee:EmployeeVO):Boolean {
        return (employeeNameIsValid(employee) && employees.checkUnique(employee.ssid))
    }

    public function save():void {
        if (!employeeIsValid(editingEmployee)
            return;

        employees.comit(editingEmployee);
    }
    ...
}

I extract the name comparison (pretend for a moment that it couldn’t be done in the VO) - employeeNameIsValid().

This is not too bad, I think. It expresses that an employeeName that’s greater than 0 chars long is valid.

However this is easily inferred from the previous example, because the test is inside ‘employeeIsValid’ - It would read just as well, and so I wouldn’t bother with this extra step. At least, not until it got more complex. Remember, most refactorings are bidirectional.

Posted 1 year ago by squeedee

Comments

Tags: flex, clean code, expressive, verbose,

On Robotlegs UI Architectures

There are now Caveats to all my posts.

I am considering everything in this post from the point of view of a N-Tier RIA developer’s point of view.

The Robotlegs MVCS presents a myriad of ways you can work with your tiers, without adding one line of extra framework code or departing from the Best Practices. Then there are the few presentation model mods I’ve seen around, such as Elad Elrom’s.

I quite like the “Robotlegs is the presentation model” one we use at Visfleet. Below, I give a little bit of backstory and explain why I like it so.

“MVC”

I find that the original beauty of MVC is somewhat lost in most breakdowns of MVC-like architectures. I have to wonder if I’m missing something.

Originally the “View” of MVC was a Component, The original SmallTalk MVC was component oriented. From Fowler’s UI Architecture Article:

At this point I should stress that there’s not just one view and controller, you have a view-controller pair for each element of the screen, each of the controls and the screen as a whole.

There are reasons this approach died off and isn’t considered practical. Noteably, when the components are generic (yay re-use) and encapsulate their own modelling. For example, a checkbox has it’s own selection state and transition modelling. All you get as a consumer is a public interface (on the “View” no less) consisting of properties (e.g.: checked), methods and signals (e.g.:VALUE_COMMIT).

However there is a beauty to the idea of having control/model support for these component views in your MVC-like architecture. This is something I’m a proponent of. Verbs like “select”, “move”, “reorient”, “announce”, “publish”, “change”, “commit”, “save” etc can all become adjectives of state: “Jobs[1] is selected”, “task is running”, “person is facing east”.

I consider a lot of what most would call ‘view state’ (something kept by view, mediator or presenter) is in fact domain modelling.

Domain Modelling

Again from Fowler’s UI Architecture Article:

The idea behind Separated Presentation is to make a clear division between domain objects that model our perception of the real world, and presentation objects that are the GUI elements we see on the screen. Domain objects should be completely self contained and work without reference to the presentation, they should also be able to support multiple presentations, possibly simultaneously.

I worry that the domain modelling found in the client-tier of most N-Tier applications (read database backed with a server encapsulating business logic) is often treated as a model of the business logic.

Certainly there is a good case to model some business logic in the client for speed and responsiveness, networks aren’t terribly fast compared to my computer’s bus. However that “business logic” being modelled is actually a part of the client domain model. It should be considered a utility and not actual Business Domain Modelling.

Let’s reiterrate that through example.

The business tier (server) says that:

A “Job” may transition state from “started” to “finished” or to “not started”.
A “Job” can not transition from “Started” to “Deleted” (you have to finish the job or back out of it before removing it)

When enforced on the business tier, this is “Business Logic” or “Business Domain Modelling”

When mimicked in the client tier, this is “Client Domain Modelling”. It is not:

Canonincal. So I’m calling it untrusted
Business Logic. Let’s not have it in two places.

Client Domain Models in N-Tier application clients are there to serve the purpose of presenting the business to the user

What I take away from this is:

A “Start” method is a domain model action.
selectedItem is domain model state.
runningJobs is domain model state.
etc…

To put it another way, I see my whole Robotlegs MVCS stack as one giant ‘Presentation Model’

Re-tiering feels pointless

What a lot of people do in their presenters and mediators is have a local state and message bus. This feels awkward to me. Suddenly I’m without a prescription, and frankly it’s really easy for me to write crap again. I can fill my mediator or presenter with awkward code that unsuprisingly is often best served by the MVC pattern.

I could treat my mediator as the context for another Robotlegs stack, however there is one clear drawback to this: Views, with their own concerns, cannot change containment easily. I explain this with the “Doorbell Model” later.

One context to rule them all

Or most of them… There’s lots of good reasons to use subcontexts, but within a context, I want to use a single MVCS 4-Tier.

I mediate as many components as I can, it gives me some of the elegance that the original MVC had. Each component action is mapped to a command, the command changes state in my modelling in some way, the mediator and view ensure they represent the new state. Again, I’ll outline this in the “Doorbell Model”

If I want to ‘genericise’ a component, and thus limit other users to it’s view’s public interface (as with most UIComponents), then I still create a robotlegs 4-tier stack and pass in dependencies via the view’s public interface. Then the context for the component uses these values as injection mappings (often named value mappings). I don’t do this very often mind you, a single context doesn’t cause me any real pain. Sub contexts might make for less clutter and I look forward to investigating those further.

The Doorbell Model

A simple analogy for why I don’t want any more tiers than the 4 in MVCS.

First, the views

A House is composed of a roof, a floor, and walls.
Walls are composed of Mortar, Bricks, Windows, Adornments and Doors
Doors have Adornments.
Example Adornments are: Lights, Doorknockers, Doorbells, Plaques etc..

A doorbell, where you might find it.

I’ve seen Doorbells on Doors, on the Wall beside Doors , and even at the back of a House (for a teenage boy’s mates to ring late in the evening.)

My original design might call for the Doorbell to be beside the frontDoor, thus contained by the frontWall, in turn contained by the house.

This frontDoorBell could be mediated by House’ or Door’s mediator. But why? Why not put a mediator on DoorBell. Then when I go to put a DoorBell on the backWall, and move the frontDoorBell to the frontDoor itself, nothing needs to change.

I almost imagine the DoorBell’s mediator to be a little circuit that hooks it to the wire on the House’ event bus.

An identifiable doorbell

Did you notice the arrival of the DoorBell on the backWall. This puppy makes it interesting. The event bus wants to ring two different bells, one for the teenageKidsRoom.bell and one for the hallway.bell. How would we identify the messages coming from these objects? That’s easy, the parent container of the DoorBell can inform it of it’s location (or the doorbell could ask the parent, it’s not an issue we need to care about right now).

The DoorBell.location property can be used to identify it’s position within views. This is appropriate intimacy and requires nothing but an obvious refactor to introduce it.

All those classes!

This approach to architecting my UI means that I have a proliferation of class definitions, and all within the convention of /model /view /controller /events /service. That’s OK. I compartmentalise component of the system by namespaces. Take a look at our namespace-prescription (living document) for Visfleet’s vWork product.

RFC

If you think I need to clear up anything or ammend anything or consider something, please comment. I crave peer input :)

Posted 1 year ago by squeedee

Comments

Tags: flex, actionScript, robotlegs, UI, Patterns, MVC, Presenter,

Robotlegs Plugin for IntelliJ

So I started a little plugin a few days ago. I’m writing it for IntelliJ and it’s designed to make your life a little simpler, letting you navigate between classes with known ‘Up’ and ‘Down’ relationships in Robotlegs MVCS. Eg, The view is “Up” from the mediator and the service is “Down” from a command.

IntelliJ is really cool.

Apart from finding great little timesavers all the time, this is my first exposure to the underlying code of IntelliJ. It looks a little ‘patternitis’ but everything makes sense, and even the closed source ‘JavaScript’ plugin was easy enough to take advantage of with just headers.

It’s also my first time into Java, and the experience has been made sweet because:

IntelliJ is a great IDE and makes light work of what would be chore-like coding
IntelliJ is written with IntelliJ, and all the Best Practices and quality coding behaviours that IntelliJ promotes, are included in the “OpenAPI”

I mean the Javadocs are ancient and out of date, and some things are clearly legacy, and yet me, a n00b Java programmer had no trouble cobbling together the first part of the Robotlegs plugin.

The Plugin, where’s that then?

Here: http://plugins.intellij.net/plugin/?idea&id=4685 which means it’s also available in your IDE.

You may need the EAP version of IntelliJ as that is what I coded against.

It only does one thing right now. If you are in a mediator, then Ctrl-Alt-PageUp will take you to the linked in view. There is a roadmap here and all the source is here

All the design is in place and a lot of the ‘discovery’ is done. So things should fall into place. Let me know if you have any trouble with it.

Posted 1 year ago by squeedee

Comments

Tags: flex, robotlegs, intellij idea,

Visfleet’s Radiator (v 0.0.1)

I started a project not too long ago to implement an information radiator here at Visfleet. The first milestone has been reached: Show the status of important Hudson builds

And here it is:

The source is on github

I started out with the intention of using Flex 4 skinning to make a super-modern, slick looking radiator like Panic’s. But somewhere along the way I ended up with a two tone border, it reminded me of my Commodore days, and the rest is ugly :)

Near term plans include:

Show C64 raster bars around building jobs
Use a horrible blink to highlight broken builds
Show who has claimed a build

Then:

Show which of our feature build servers has been claimed for a feature branch.
Show our twitter feed.
Get a much bigger screen.

Posted 1 year ago by squeedee

Comments

Tags: CI, Continuous Integration, Hudson, Flex, Radiator,

Builder pattern is so easy in Robotlegs

The Builder Pattern is a breeze in Robotlegs

public class ConcreteWidgetBuilder implements IWidgetBuilder {

  [Inject]
  public var injector:IInjector;

  public function buildPart(parameterised:IThing):IWidget {
    var widget:IWidget = injector.getInstance(IWidget);
    widget.param = parameterised;

    return widget;
  }

}

Parameterized builder

If you want to control what gets instanced based on a parameter:

public class ConcreteWidgetBuilder implements IWidgetBuilder {

  [Inject]
  public var injector:IInjector;

  public function buildPart(parameterised:IThing):IWidget {
    var interface:Class;

    switch(parameterised.style) {
      case ThingConst.COOL:
        interface = ICoolWidget;
        break;
      case ThingConst.HOT:
        interface = IHotWidget;
        break;
      default:
        interface = IDefaultWidget;
    }

    var widget:IWidget = injector.getInstance(interface);
    widget.param = parameterised;

    return widget;
  }

}

Bit freakin’ sexy if you ask me.

Posted 1 year ago by squeedee

Comments

Tags: flex, robotlegs, builder, factory,

Couch and Flex. First Steps.

I had this idea that I wanted to replace TraceTarget (the default Flex logging target) with CouchTarget. That way, instead of producing .csv text I could sort and filter in excel. I could get realtime (or close to) in couch and write views/shows that narrowed down my debug session.

So off I went, and it did not go well.

Step 1: Installing CouchDB

I have an Ubuntu instance so I just installed couch with Aptitude. I did some tutorials and was loving Couch in minutes.

Step 2: Talk to couch from flex.

Ouch. So couch wants ‘PUT’ methods, and fair enough too. But I know I can’t do that from URLLoader. I played with some other solutions, like the as3http library, but I really didn’t want something so OTT for a simple logger. So I searched for a magic bullet I knew had to be there.

PUT when you can’t

In RubyOnRails rest calls, you simply provide _method=put as a parameter to a POST and you get PUT. This is because some clients (Flash player included) cannot PUT, they can only GET and POST.

So I went looking throught the CouchDB docs to see if it supported an alternative to ‘PUT’. Nothing came up. I was still sure it MUST support it somehow though. So I went looking around for other alternatives. I finally stumble upon the X-HTTP-Method-Override header.

Eureka! right? wrong..

X-HTTP-Method-Override support

I tried it, it did not work. I thought, well, couch does not support this…

Searching for X-HTTP-Method-Override and CouchDB finally turned up a changelog, where it was added in some version, which was clearly newer than the 0.10 version Ubuntu installs.

Moral

Install CouchDB >1.0.

CouchOne do great installers

Example

Heres the crufty first draft of my Logger

It has dependencies you wont have so don’t expect it to run, or play nice. But it does show how I got posts going. RestfulX provided an easy method for adding headers and also kept me believing it was possible with URLLoader, because they do it too.

Posted 1 year ago by squeedee

2 notes

Comments

Tags: flex, couchdb,

Dominic Graefen introduces a Flex/Flash Buildr Extension

Dominic Graefen (@devboy_org) introduces a Flex/Flash extension for Buildr. I recommend Buildr over Maven or other declarative build/dependency systems. Give it a go :)

Posted 1 year ago by squeedee

9 notes

Comments

Tags: actionscript, flex, compiler, buildr, ruby,