Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought

Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Show Posts

| * |

  Show Posts
Pages: [1]
1  Announcements and General Discussion / General Discussion / Facade.removeCore() throws error using FB 4.x framework on: August 14, 2010, 03:21:43
Hey guys,

I have been working with this issue for several hours and I have found that calling the static removeCore() causes an error on line 10632 of UIComponent.

To catch you up with what I have done, I build an app with a Module using multicore from the ground up. Everything works fine with creating the module through the module manager and the core if I never plan to remove the module's core.  However, what is interesting is once I place the removal call in my code (it doesn't have to get called) then I get the error. (And the error is thrown when the module is attached to the display... weird).

So I downloaded the GarbageCollectingPipes example and found the same error being thrown, but commenting out the remove core in the command does not have the same effect.  I'm now playing with that project to see if I can isolate what is triggering the error.

Does anyone have a clue as to a workaround for this?  I don't wish to downgrade my project to 3.x. 

2  Announcements and General Discussion / General Discussion / ?? Best Practice Flash Builder 4 Value Objects and View / framework separation on: January 29, 2010, 02:25:35
I've been doing some developing in Flash Builder 4 Beta.  Seems from what I have read and implemented in some projects I am playing with, the new fx:Declarations tag is where you would declare your VO's along with other misc non visual elements. 

So I read on a blog about '10 Best Practices for PureMVC' http://www.websector.de/blog/2007/12/25/10-tips-for-working-with-puremvc/ that VO's, not being actors of the frame work are a good way to react to changes in the model without breaking the rules....   

After reading this and trying to conceptualize a bit of ambiguity from that post it got me thinking about a possible solution to allow the view to react to model updates directly vs waiting on the proxy to send a notification, a mediator or command to process it, and finally update the view accordingly (possible not breaking the rules as the article so elegantly expresses?).

Here's my thought:

In your vo package, define a bindable Value Object class

In your view, declare an instance of the vo in the fx:Declarations tag.  Then bind whatever controls to it, it's properties, etc...

On the proxy, create a property of the VO and have the responder cast the result to the VO property.  Create your getter/setters for it as well.

In the mediator, depending on your style, either access the proxy through the facade and set the VO in the view to the VO on the proxy, or send a notification and let a command do it... Something like:
mediator.myView.myVo = proxy.myVo;

So, being of curious mind, I tried this and it did work.  The view's declared VO was set before the data was ever received from the server and I saw the control populate after the data was received.  I did not have to send a notification and notifiy a mediator or command of the data received. 

Would this be 'breaking the rules'?  I do have a couple of scenarios in my projects where an ArrayCollection of data objects may get updated by a new record or a record deleted.  It would be nice to have this wireup between databinding of the control and the proxy just to save some time and code, but at the same time I would not want to paint myself into a corner down the road. 

Any thoughts or advice?

I strip down my example and post the code if I can make time this afternoon.
3  PureMVC Manifold / Demos and Utils / State Machine and ViewState example - Flex 3.4 on: December 14, 2009, 02:23:29

I just started playing around with the FSM StateMachine utility and in my process of getting a grasp on how it works through viewing other examples, I created my own example which utilizes 1 button to cycle through states with 1 Action message.  I've also setup the app to use a flex ViewState in conjunction with the FSM.  The purpose here is separate out the different parts of the application as loosly as possible.  In my comments you will find some ideas on a more complex proxy than the initial included proxy.  Also in the Injector command I explain in more detail a concept for state cycling via 1 action command. 

The methods here behind my madness are to keep the view as uncoupled as possible - specifically the mxml file(s).  Personally, I like to avoid actionscript in the mxml file and directly binding functions in the event attributes.  I'd rather register listeners in the mediator and handle as much of it as possible there.  So other than the Facade setup, and 1 dispatcher function (left there for simplicity), the rest of the AS code is in AS files.

If anyone has an example of a better or even different way of tying the FSM to ViewStates, I'd love to see them and I am completely open to suggestions. 

This simple example is a result of me examining the StopWatch example and then building from the ground up based on the concepts found within the StopWatch project.  So it should be fairly familiar in general for much of the core.

Enjoy and I look forward to any comments/responses.

4  PureMVC Manifold / MultiCore Version / Need Pipes help. I think mine are clogged on: October 14, 2009, 11:23:21
I've been using multi core for a few projects now and found my first need for pipes. PureMVC was pretty easy to get the hanng of, so pipes seem to be the obvious solution. I have been through several sites and examples like PipeWorks and thus tried to implement some simple pipes in my project, but with no success.  Upon further digging for examples and docs, I found the simple HelloPipes example and decided to build a quick test project based on that example and work my way up to something more elegant like pipeworks to gain a good understanding of how it works.  So start simple and build upon what I learn, right?

Studying the HelloModules example, I personally prefer to let the mediators mediate and handle the brunt of the logic. Therefore, other than an interface for the module and defining those methods in the mxml of the module, and facade startup, I have moved most of logic into mediators. 

I've started a simple project and written enough code that I can attach a module, plumb it, and send a message down a pipe from the module to the shell, however my shell does not hear the message.  I've checked to make sure I have my pipes registered, listener is registered, mediators are registered, etc.  Obviously I have missed something, but I have been through the code several times and I am just not sure what I have missed. 

Attached is the archived project.  I am using Flex 3.4 SDK.

I am the only flex coder at my company, so if someone here wouldn't mind taking a quick look to point out the errors of my ways, I would be most thankful.
Pages: [1]