mvcExpress v2 rc3 released with more protected proxies


First of all - Happy new year!

2013 was very exiting year for mvcExpress framework! It evolved into version 2, and I see people using it more and more everywhere! I have a new year present for you.

I am adding new feature to mvcExpress, feature I like very much:

Idea is very simple – mediators should not be able to inject proxies, so by default mvcExpress will not allow it throwing an error if you try. But in some cases we want proxies in mediators(to avoid unnecessary commands, or just for convenience).  In these cases you have to specifically allow proxy to be injected into mediators.

So basically this change keeps all options what you can do with proxies as before, but it trades some convenience for more control. And I think it is a good trade.

This is how you map proxies now:, name:String = null, injectClass:Class = null, mediatorInjectClass:Class = null);

You can notice this function have changed a lot, and actually is not backward compatible. (Sorry about that, just change name with inject class in your code if you get an error then you compile your code.)

  • name and injectClass parameter order switched. (more intuitive.)
  • name is defaulted to null, null will be treated same as empty string.
  • mediatorInjectClass parameter added. If it is set to null – this proxy will not be available for injection into proxies and will throw error. To enable it – just provide class you want your proxy to be injected into mediators as. (Best practice is to use get data only interface)

I also found and fixed lot of bugs with lazy proxies in this update, I rarely use those, so I missed it. Sorry.

mvcExpress logger is improved and updated to work with RC3 and up.

You can get RC3 from GitHub.

Thank you for your support and feedback! This gives me lot of motivation to continue working and improving the framework.

More and more people point out that mvcExpress lacks good learning material. I will focus on fixing that next year!

9 thoughts on “mvcExpress v2 rc3 released with more protected proxies”

  1. Great job – and I’m glad to see you’re still fighting the good fight for high quality as architectures.

    However when looking at v2, I was wondering, if you would also pick up on Robotlegs great fluency naming changes? I can see great changes on modularity, which are highly appreciated and really feel like the tough part. :)

    Again, great job – I hope to be able to use mvcExpress on whatever comes next!

    1. Hi,

      thank you for you kind words!

      I have double feelings in regards modularity robotlegs has. It gives flexibility but also have a cost, both in performance and extra set-up work you have to do.

      mvcExpress has a different vision, it tries to do one thing, and one thing only – but do it very well. mvcExpres v2 adds possibility to extend framework functions, but it is a bit clumsy, it is functional but not convenient. (build on inheritance, instead of composition as robotlegs 2.) but.. its fast!

      In any case, I am open to new ideas, and would like to prototype different approaches, maybe for v3..?

      Regarding function chaining in robotlegs 2 – it’s more of style choice. I have no plans to add it to v2. Have to research what other people using mvcExpress thinks about it. I myself am not strongly for or against it.

      Have fun with mvcExpress!

  2. when searching for mvcexpress and starling compatibility, I found articles about moduleSprite and moduleMovieclip. I am using v2 rc2 and hadn’t found them. What happened with those two?

    I am currently got trouble with mvcexpress, starling and iOS that app got crashed immediately after the splash screen. Tracing around I found trouble probably came from mvcExpress.

    It would be glad that you could explain me the uses of ModuleSprite and ModuleMovieclip before, that would somehow help to solve my problem.

    (I have tweak a little bit in mvcexpress Mediator to work with Starling’s MovieClip and Event instead of Adobe’s ones)

    1. Hi,

      ModuleMovieclip and ModuleSprite classes were deprecated in v2, they only confused things and did not added much value, useful only in multi-modular applications. Just create module instance inside view object you want to use as root for module in multi modular application.

      Its unlikely you have problems with IOS because of that. But I did get weird report about one problem with IOS build, that was fixed in v1. (
      I will have time next week to port it to v2. (

      I hope that helps.

      Thanks for using mvcExpress!

      1. Glad to know you are working on it! Yes that is correct about “useLegacyAOT no”. Actually I am working insanely hard to submit another version to AppStore this week because after Feb 1, no legacy build is allowed to submit.

        Good luck and happy new Lunar Year!

Leave a Reply to Yoba Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>