Using a DataGroup as a ViewStack
Here is a very simple example that is a testament to the improvements in Spark. I’ve noticed a lot of people seem to be baffled by the lack of a Spark ViewsStack. A basic dataProvider-driven ViewStack is actually very easy to implement, and the bonus is that it supports virtualisation. A quick example can be found here(View Source is enabled).
If you prefer to declare the children up front it’s even easier. Just use a Group instead of a DataGroup (You will lose virtualisation support though).
There is a lot more to say on the subject, but it will have to wait until I have a bit more time.
Cedar – An RSL Seeder and a really bad Pun
Just upped a little library I’ve been using with a client of mine. The problem they initially faced is that they wanted to embrace Flex, but were not happy with the heavy download that Flex imposes for even the simplest file. Using the framework RSL was definitely a big improvement, but ideally they wanted their regular visitors (numbering many millions a week) to have as minimally disruptive an experience as possible.
My solution to this was to build what I have called an RSL Seeder. The Seeder is a skinny AS3 shell that loads a second swf (the Seed). The Seed is compiled to use the RSLs you want to use, signed or unsigned. The Seeder sits hidden on high-traffic pages frequented by your regular visitors and when you are ready, or after a specific duration, the Seeder will load the seed, causing the RSLs it contains to be cached in browser or Flash Player depending on whether they are signed or not. The Seeder contains a basic UI to monitor RSL loading and download times and display the loaded swf. However this is for debugging and setup only and ultimately you should switch its debug mode to false, causing it to hide all UI and not waste any time with rendering.
Ultimately this allows you to ensure your regular visitors have the required RSLs cached in advance of launching any apps or components which use them. This is particularly useful now that the Flex 4 SDK comes with 7 signed RSLs of a non-trivial size, and given that every time you upgrade your application’s SDK you need fresh signed RSLs.
There is an introduction and spec in the docs folder for more information. I plan to improve the UI and display more data about the RSL loading as and when I have time. Please note that you will need to visit Adobe’s shameful Flash Player settings Storage panel and turn of its ability to cache RSLs as unless you have been living in the desert for the few months, you will most probably have the Flex 4 SDKs cached already. You can see the Seeder doing its business here. If nothing happens, your Player has the RSLs already cached and you need to turn its use of RSLs off.
3D Effects For Flex 3
The additions to the Flash Player API allowing 2.5D transformations on DisplayObjects seem to have passed Flex 3 By. Flex 4 has some Effects allowing Components to be manipulated in 3D space, but there was nothing added in Flex 3.5. I have written two Effects to make use of the new APIs, allowing you to move and rotate Flex Controls & Containers in 3D Space. You can play with them by clicking the image below.
The handling of 3D is surprisingly buggy. These effects offer two built-in fixes that you can turn of if you like. The first compensates for the slight distortion to DisplayObjects’ X and Y scales when an Object has a 3DMatrix applied, and the second automatically swaps out the 3DMatrix for a standard (2D) Matrix when the Effect target’s rotation and position allow (Basically, if the Object is at 0 on the z axis and is not rotated at all on the x or y axis).
__
Orchid prerelease is out
Samuel Agesilas has just announced that his Orchid component framework is finally seeing the light of day. You can download the prerelease here. Docs are included and also online here. If the length of time he has spent cooking this up is any indication, it will be sweet. More exciting is the prospect of Saffron UML seeing the light of day at long last.
Stripping out trace code.
I use a logger. Most of the time. But though I’m ashamed to admit it - Sometimes I go loco with traces. Sometimes I just can’t help myself, and before I know it, I have obscure messages popping up in my console from places I had forgotten existed. Usually these binges happen as I try and chase something down, and when I manage to sober up, I need some way of cleaning up quick. Before anyone finds out. Before my dirty little habit is exposed.
This little string of characters does my caretaking for me. Its a simple Regx that matches all the traces in your project.
trace\(.*?\);?
In Eclipse (FDT/FB):
- Open the search panel: Search from the menu then open the File Search tab
- Paste: trace\(.*?\);? into the Containing text: input box.
- Tick the Regular expression Checkbox over to the right.
- Make sure File name patterns input box contains the right file types for your project. For Actionscript and MXML it should look like this: *.as, *.mxml
- Click Search or Replace…
I also use this in my ANT build file for any release builds.
<replaceregexp
match="trace\(.*?\);?"
replace=""
flags="gs">
<fileset
dir="${temp.dir}"
includes="**/*.as"/>
<fileset
dir="${temp.dir}"
includes="**/*.mxml"/>
</replaceregexp>
For lots more ANT goodness check out AntFunk
Making Robotlegs’ Mediation of Views More Flexible Part II
In my previous post, I modified Robotlegs’ MediatorMap to allow classes that were part of the view, but not necessarily on the display list to be Mediated. This worked nicely in some cases, but this morning I was playing around with the PresentationModel. The big difference between the presentation Model and MVC/MVP is that instead of a passive view observed by the Controller / Presenter, it is the PresentationModel that is ignorant of the view. My previous code didn’t allow for this relationship. It assumed that the interceeding class wanted a reference to the view, but what if it was the other way around?
I solved this problem using a Factory. A simple factory is passed into the InterceedingMediatorMap, along with the Interceeding class (or the Interface the Mediator uses to store its instance). This factory abstracts the wiring up of the view. Inside the MediatorMap, just before the Mediator is created, an instance of the InterceededViewFactory (Yeah I know these names don’t roll of the tongue). The viewComponent instance is passed to it and it returns the interceeding class to be injected into the Mediator. For example in the case of a view that uses the Presentation Model, the factory creates the presentationModel instance and passes a reference of it to the view, then returns it. This way, the Mediator gets its reference to the presentationModel and so does the viewComponent, but the presentationModel remains ignorant of both.
Here is the ApplicationContext:
override public function startup() : void {
//Controller
commandMap.mapEvent(ColourSelectionEvent.SELCTION, UpdateModelCommand);
//Model
injector.mapSingletonOf(IDataModel,DataModel);
//Login View Injection Points
injector.mapClass(ViewModel, ViewModel);
injector.mapClass(ViewData, ViewData);
//Interceeded Mediators
interceedingMediatorMap.mapInterceededView(app.view.components.MVP.View, MVPMediator, MVPFactory, Presenter);
interceedingMediatorMap.mapInterceededView(app.view.components.presentationModel.View, PresentationModelMediator, PresentationModelFactory, PresentationModel);
//Standard Mediators
interceedingMediatorMap.mapView(app.view.components.autonomousView.View, AutonomousViewMediator);
super.startup();
}
I’m going to do some more work on this as there are a few things I don’t like about the way things are set up – too may arguments on mapInterceededView for example, but for the moment, here are the classes, along with two example factories.
The Very Hungry Caterpillar vs My Macbook Pro
I hope the little guy manages to cling on to the unforgiving aluminum finish. I’ll keep you posted.
Using Very Hungry Caterpiller Stickers (Amazon)
Making Robotlegs’ Mediation of Views More Flexible
I have been using Robotlegs in my last few projects, and found it to be an excellent step on from my previous favourite; Pure MVC. I won’t go into the reasons why I like it so much, though there are many, but in general it feels far more flexible and requires less boilerplate than other solutions. However, no matter what framework you use, sooner or later you will hit a wall, needing to implement something can’t accommodate. I hit such a wall last week with the way Robotlegs wires up Mediators to their views.
Update: I have taken things a bit further along here.
I’ve been having an ongoing discussion with my good friend Simon about effective ways to implement views, and more recently, how to do so in Robotlegs. Obviously a Mediator is beneficial in keeping your view ignorant of your chosen framework, but where we’ve both been unsatisfied is in the organisation the view itself. I’m using view in the sense of a complex view as opposed to a simple component, or a more abstract notion of ‘The View’. It is perfectly possible to work on a very granular level and Mediate every single control in your application, but in my opinion this is painfully cumbersome, and results in your code being far too distributed and difficult to work with, especially if you are dealing with ongoing changes to UI. My preferred solution to this particular scenario is to break my application into views – logical collections of controls which might equate to a screen, or to a logically related chunk of functionality like a sidebar or a simple gallery. Of course all views are composite, and you could easily argue that even a simple control is a collection of other simpler controls which it has chosen not to expose directly, but for my purposes, I am talking about small collections of controls that are logically related.
By Mediating views on this level, I can be sure that a lot of the trivial inter-control communication can be kept out of my framework level communication, leaving the framework to deal with more important, abstracted notions of communication. In short, If I have a gallery view, the framework only needs to know when someone saves an image to their profile, not (necessarily) when a new image loaded or tagged. That kind of basic functionality can be kept in the view. Apart from anything else, I find it far easier to understand what is going on within a view because I don’t need to chase application flow out through the framework (except where necessary). It is also far easier to snap off chunks of functionality for development by separate individuals who need no knowledge of the framework or application as a whole.
Conversely, the problem with more complex views, is that there is more code in one place, and we have been looking for better ways to split this code down into logical pieces that are also practical to use when developing. The Mediator exists outside the edge of the view. It is a part of the view in the sense that it Mediates the view, but it is not a part of the view itself. Often when people talk about the Mediator, they compare it to a Presentation Model, but we both think that this is an incorrect comparison. A Mediator is there only to interpret communication from framework to view and view to framework. A Presentation Model is much more closely tied to its view. Here is Martin Fowler’s take:
Presentation Model pulls the state and behaviour of the view out into a model class that is part of the presentation.
and
Presentation Model may interact with several domain objects, but Presentation Model is not a GUI friendly facade to a specific domain object. Instead it is easier to consider Presentation Model as an abstract of the view that is not dependent on a specific GUI framework.
In short , it is not intended to to be framework dependant in the way that the Mediator is, and this is an important distinction. It is not an alternative to other presentation patterns but can compliment them.
What we wanted to avoid were mongrel MXML classes containing a nasty cocktail of MXML components, event handling, view logic, state and localised models, often in the form of a dataprovider or VO, or perhaps a series of disparate variables. Certainly this approach has its place. It makes sense for code examples, low fidelity prototypes and quick/dirty projects, but on longer or larger projects, it’s disadvantages outweigh its flexibility. What we wanted was to look at different ways of architecting our views, with the following constraints:
- The view should contain no framework specific code.
- The view should allow as much as possible of itself to be tested without any interaction testing.
- The view should be easy to work with and easy to understand; data flow should be clear and consistent.
- The view should offer a simple interface which hides its implementation from any framework that utilises it.
To solve this problem I have subclassed MediatorMap, modifying its API to allow another class reference to be passed in – an IInterceedingClass. When the mapped viewComponent is added to the stage, the Mediator is created as usual, but instead of the viewComponent being in injected into it, the viewComponent is injected into a new instance of the IInterceeding class which is itself then injected into the Mediator. This allows for many different types of view to be used with Robotlegs’ IMediators, not just a DisplayObject derived viewComponent. For example if an MVP triad was being used in the view, the Presenter could be mediated without the IMediator knowing about the viewComponent. Here is an example of the modified MediatorMap being used in an ApplicationContext:
//----------------------------------------------------------------------
// assemblerMap
//----------------------------------------------------------------------
protected function get interceedingMediatorMap() : IInterceededMediatorMap {
return super.mediatorMap as one.frameworks.robotlegs.extended.InterceededMediatorMap;
}
//----------------------------------------------------------------------------------
//
// Methods
//
//----------------------------------------------------------------------------------
public function ApplicationContext() {
super();
// Create our alternative implementation of IMediatorMap which
// subclasses MediatorMap
_mediatorMap = new InterceededMediatorMap(contextView, injector, reflector);
}
/**
* @inheritDoc
*/
override public function startup() : void {
//Controller
commandMap.mapEvent(ColourSelectionEvent.SELCTION, UpdateModelCommand);
//Model
injector.mapSingletonOf(IDataModel,DataModel);
//Login View Injection Points
injector.mapClass(ViewModel, ViewModel);
injector.mapClass(ViewData, ViewData);
//Interceeded Mediators
interceedingMediatorMap.mapInterceededView(app.view.components.MVP.View, MVPMediator, Presenter);
interceedingMediatorMap.mapInterceededView(app.view.components.viewHelper.View, ViewHelperMediator, ViewHelper);
//Standard Mediators
interceedingMediatorMap.mapView(app.view.components.autonomousView.View, AutonomousViewMediator);
super.startup();
}
In later posts I will talk about different approaches to organising complex views and how best to wire them into Robotlegs. Also keep an eye on www.newtriks.com for related posts and Chandima’s forthcoming series on Presentation Patterns.