Hi,

 pureMVC is good for games.
 I myself made couple of huge projects with it.

The community around it is huge, and you will find support easily with other flash programmers, but... it's not the fastest option, and not the one that produces cleanest code.

 I am currentry investigating mvcExpress framework : http://bit.ly/wis7uO

I wonder how it compares with pureMvc.

Another post on the subject...

http://www.mindscriptact.com/robotlegs-vs-puremvc-performance-battle/

 Hello,

 I wrote a post comparing PureMVC and RobotLegs.

From information I have - it looks like RobotLegs is better for me..

Could you review the post, and tell me if I am missing same argument?
Or maybe I have wrong info or errors...

http://www.mindscriptact.com/puremvc-vs-robetlegs-match-up/


 Thank you very much.

http://www.mindscriptact.com/blogFiles/DerilsPureMvcTemplates.zip


More details at: http://www.mindscriptact.com/magic-there-flashdevelop-meets-puremvc/


If you have any suggestions or critique - I would be happy to hear them!

Cliff has a good point.

 imagine your application done in units or modules.
Those modules are not dividable, and they can stand more or less on there own.

 one module can use and aggregate other modules. but it should not implement those.

 Then I see that my code does not meet this characteristics, I naturally start to feel that something is out of place.. with time you start to feel it like intuition.

 Now if there is the need to create sub System that does not fit that picture - it will not find place in PureMVC folders. PureMVC will probably have Proxies and VO that will hold artifacts from those subsystems, but it will not implement it, and it will not have code of it.

 Imagine utility that abstracts XML... you could call it... XMLData.as in utility folder. Now XmlProxy.as could hold instances of XMLData in VO's and use it as it needs to. but XMLData implementation should be completely separated from PureMVC.


 About games... I work in big online game making company. I have examined/collaborated on couple of huge project and was leading one that uses PureMVC.. (60000+ line of code game and growing.)

 Yes. You can and in lot of cases you should use PureMVC in games.

There are 2 main reasons for that... (not to mention array of minor once..)
 - big games tend to change much. if you don't have a good framework you will end up with a mess.
 - big games tend to have many programmers, and over long time they change.. everyone has his programming stile. If you don't use framework you will end up with mess done by "coding in different directions"

 Have fun.

Hi,

 its a good practice to use VO with value objects.

 If you see VO in the class you instantly know that this is just data container. Nothing else.

If you have complex data structures, for example that needs to have some inner mechanics that work as black box, and it is not just value object anymore - it's better to avoid adding VO. Name whatever makes sense... "Data", "Info", "Attribs"...

 In almost all cases Proxies juggle plain data, thats why Value Object naming convention is used.. if you don't have value object - don't use this convention.

Plain classes is best used with View clases. "MainMenu", "PromptWindow" and so on.


I have little personal practice to name Command that passes temporal Value Object as body with ending "Param" to know that those are purely temporary VO classes just to sent data around, they have same role as parameters sent to function. I create them near command under "param" folder.
(Of course sometimes commands gets VO to body, this way I know this is data that is not temporal and needs to be stored in proxy somewhere, or is taken for proxy.)

Have fun.

Hi,

 sorry if I misunderstood you in any way. All I meant is to help, and see how other people use PureMVC.

I think the reason of our miss-communication is because from my view point, you are braking the very reason we use PureMVC. And that reason is decouple mediators from data and from each other. And if you do that, the order of notifications makes no difference. (mediator will just show most recent data...)

 In any case.. as I mentioned before: do what works for you.


Have fun.

In short: Mediators are the only class that can send/receive notifications....

well.. no.  Commands can do it also.

 logic should not be in mediator or proxy, they must be in commands.
Mediators generally listen for note to tell them what to show, and it is best that they should do it ignoring any sort of logic.

Hi,

 Sorry I didn't read all your reply... but here is your problem:

These observers only react to the ENTER key if their sprite is visible.

... as we mentioned already. Mediator should not keep or manage state.

Proxy should keep the state..
Commands should manage state.
and mediator is that DUMB entity that just SHOWS IT.

so.. your sentence should sound more like this... :

"The ENTER key is pressed, and command gets trigered, it changes the proxy, then proxy sends the note that state have changed for all 12 observers, These observers react to the proxy note, then they check the proxy, and if it says they should show sprite.. they show it.. if it says it must be hidden... they hide it."



 Observers-mediators should not care about state of sprite, as view object. The mediator could (and most probable should) check if sprite is visible just to know if it needs to change it. For instance if sprite in not visible, there is no need to hide it. But it should not do LOGIC based on the sprite state.


 My guess is that you fixated on your current implementation, and you don't want to change it... but try to change everything around it to meet it. (including framework in this case...)
 Let it go! try to approach you problem differently!

Hi,

 you mentioned that you need persistent command. Why?


 some of my thoughts...

Imagine TimerMediator that would send ViewNote.GAME_TICK notices.
Then command (most likely macro) picks it up.. change proxy data if needed..
Then mediators react if needed.

 This fits well for top layer game logic, "macro world" how I call it...

For "micro world" (lets say you have 1000 items that needs to animate, and maybe change every tick) the trick I use is to have mediator that manages ALL those 1000 animations as components, and single note to update it with some clever/convenient data object.. (maybe array of object that must change only.) The state of those 100 could be still handled by command, using proxy, doing some math magic and stuff.

 Another strategy that could be used, is looking at that View with 1000 animations as a "black box" that has inner world of its own, interaction, tick engine and everything could be done inside of it (I don't suggest doing it in one class... just looking to view as very complex subsystem), and interacts with PureMVC at very high level. Mediator for that view could be only as bridge, that cares little what happens inside of that black box.
 You will not cover that subsystem in PureMVC, but if you decouple WHOLE subsystem from PureMVC - it's not a problem.


 What is your arguments on having persistent command?

Do you see something wrong with wanting that a notification is received by all observers before subsequent notifications are received?

 The only thing that is wrong, is that your mediators has this dependency that should not be there.

My guess is that your data tear does not have everything it needs to handle state properly..

but hey.. do whatever works for you.

Mediator should not decide anything... its a job of logic tear to think about things.

 Lets see... I still missing some details.. Depending on what you are doing one or another approach could be better.

you are sending notice on Enter press. That's great! That's exactly how it should be..

Now we have 2 options.

1 - note is cough by mediator and processed.
2 - note is cough by command and processed.


 both cases are valid, but depending on what you are doing one approach is better then another.

for 1 if your key pressing action changes view in straightforward matter,  that does not require "thinking" - its perfect way to go!

 for example... I want my item to be shown then I press the button, and hidden then release. and nothing more. Lets say other parts of application don't care about this show/hide behavior, then I don't need a proxy to store state.

 but in your case it looks like your have more complex case. So I say.. lets go with option 2!

so... then enter key is pressed "HANDLE_ENTER_KEY" note is sent and HandleEnterKeyCommand is executed.

Next. As I mentioned before - you need a proxy!

depending on what you are doing you could have very different proxies. from what I know 2 options sound logical :

Option A : KeyPressProxy. This proxy stores key press state. In this proxy you would store key press boolean, count.. or whatever you need.
Option B : ViewElementStateProxy ... or something in that direction. This proxy would concentrate on remembering data you need to think about that evolves around your view, if you need data about 2 view objects that has nothing in common, maybe you even need 2 proxies. one for each mediator.

 Then you create proxies try to think less about view.. and more about state of your application and how it needs to change. Mediators are needed just to show it.

Here is scenario :

HandleEnterKeyCommand uses whatever proxies is best for you, think about meaning of life.. and other stuff.. and changes data to whatever you need to care about. And don't touch view at all.

Proxy classes gets data changed, and sends a note(or notes) to tell about it to whatever cares to listen. in your case you have 2 mediators.

 those mediators would get state with note(or get it from proxies), and just show it, without "thinking".

keep in mind that those 2 mediators should most likely know nothing about each other. And proxy data should be all and not more what they need for whatever they are showing.


I hope it helps.

Hi,

 its a bit hard to guess what you are doing... it feels like you just have error there somewhere... lets me theorize a bit for fun..

Lets think.. Note1 and Note2 can have separated or connected concepts.

#1 Notes have connected concepts.... if that's the case both should be based on one proxy, that whould represent that connection in your needed abstraction level. Then it does not matter what note comes first. mediator just takes needed proxy and do what it needs to do. If mediator1 getting note1 needs to change mediator2 behavior somehow... it should change proxy data via command in most cases, (instead of sending note to mediator2).

#2 Notes have different, not connected concepts. In this case, they should not depend on any Boolean stored in mediator.. (why you have Boolean in mediator to decide on how to react to notices in the first place? proxy should keep the state. not mediators.)

lets have a look in your questions...

1: think about your implementation.. you are doing something in wrong place.. or coupled something to tightly..
2: sure.. everything is possible! Instead of sending second notice, put it in the stack of some sort. Then with delay or after note1 confirms that it is done with his work, send note2 ! ... some extra coding needed.. but possible.
3: there is no good reason to change current behavior on notes.


Just think about putting conflicting state into proxy, and build from that up.

 In most cases I want to encapsulate data because I want to notify about data change by sending notification, and the best place to do it -function that changes data.

 In some cases it's not needed, and you could use proxy as "raw" data holder only.
That's there getData() could be used.

 I am checking my code to find those places.. but in vain maybe in the future...

That's interesting...

 it looks like we have different ideas how framework should be used.. 

I will investigate your ideas... thanks.