I am preparing first stable framework release(v1.0), and I have ‘some’ changes coming. After release I will do only changes that are backward compatible.
I am very exited about these updates! they will give framework wider range of usage! but first… lets get ugly out of the way. (These 3 changes are Backward Incompatible.)
setDebugFunction(trace); is replaced with MvcExpress.debugFunction = trace;
debugFunction will still be called only with CONFIG:debug set to true, but setting it as constant is cleaner and more straightforward approach.
mediateWith() is removed
I have some mixed feelings about this function.
It could be potentially used to mess up single mediator mapped to single view object principle.
But in some cases maybe it could be used to more conveniently manage view objects… I still fail to architect such a case. In cases then objects needs different behavior it is better to subclass them into dedicated view classes and map dedicated mediators(even if view class will end up being empty.) So unless good work-flow scenario will need this function lets keep it out.
all sendMessage() function got new parameter: targetAllModules:Boolean = false.
I was full of doubt about this change(an it is visible from my git log…), but couple of spectacularly failed module use case scenarios convinced me. Things can become ugly fast if you allow everything travel everywhere.
So from now on messages by default will go only to same model handlers there it was send from. You will have to manually specify witch messages you want to send out to all modules. It is less convenient, but it gives control back to programmers hands. (I will prepare module use sample project to show how it works soon.)
ok… enough about the past… lets talk future!
Additionally to ModuleCore – ModuleSprite and ModuleMovieClip is added.
(ModuleApplication and ModuleGroup will be added for flex users soon.)
These new module classes is designed to create new modules easier and faster.
Sadly they are a bit confusing to newcomers as they end up having 2 responsibilities. One responsibility is to be a view object and another is setup/start-up a module. In practice you don’t have much code to write for one of those responsibilities, or you can do it with one line.
I talked with couple of people who liked the idea… and couple who hated. So I want to leave this as a choice: If you don’t like mix of responsibilities, use ModuleCore everywhere. If you want to have more straightforward module classes, and you know what you are doing – use ModuleSprite. (event if you end up having too much code for both mentioned responsibilities it is easy to re-factor it into 2 classes.)
Choice is yours.
New constructor parameter added to modules : moduleName
From now on all modules will have unique name. You don’t have to provide it if you don’t want to – framework will generate unique name (‘module1′, ‘module2’…)
(you have not much use for it yet… it will be used to resolve dependencies between modules in v1.1 and for better logging)
Added support for pending injections.
Support for pending injections means… that you can create the object, without having all of it’s dependencies ready. You have to specify how much time framework will be waiting for dependency to be set before it will complain.(by throwing error) If your object has pending injections – it will not be registered until it has them all.
By default this feature is disabled. you have to set : MvcExpress.pendingInjectsTimeOut to milliseconds you want your application to wait for missing dependencies. (good idea is to give time for several frames to render. )
This feature solves circular dependency problem… (then ProxyA needs ProxyB, and ProxyB needs ProxyA.) (I will have sample soon.)
addListener, removeListener and removeAllListeners added.
These are added for better event management. All events will be weak referenced by default, also you will be able to remove all such listeners with one function!
If you remove mediator – removeAllListeners remorselessness will be called automatically.
Documentation is updated.
Both class and implementation documentation is written in details. It is far from professional documentation(as it lacks in-detail usage explanations with examples). But it is quite detailed and useful.
I am planning to release it in a weak or two. So everyone who use it could try out, suggest problems, fixes and ideas.
Thanks all for your support and ideas!