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 / Architecture / Re: Help with Commands on: February 08, 2009, 08:41:25
Thanks everyone!  Cliff & Shauno really hit the nail on the head of what I was getting at.  My Cairngorm apps did end up having a lot of Command classes.  Additionally, I've had the same problem using MVCS.  I still use it today with smaller apps, but for the bigger ones, even multiple Controller classes gets challenging to manage, so I stick with another framework.  Additionally, my Commands really do what you said Cliff... they just initialize things.

What I was trying to avoid was having 2 Commands for what I usually used 1 for in Cairngorm.  I'd need to ask the server to do something, and depending on the result, do something else.  Since Commands cannot receive Notifications, I'd end up creating 2 Commands; 1 to make the request, and another to respond to it. 

Now, however, it sounds like my use of Mediator's & Proxies is correct and I shouldn't worry about not having as many Commands.
2  Announcements and General Discussion / Architecture / Help with Commands on: February 07, 2009, 08:13:50
PureMVC n00b here.  Complex question, so short version and long version.

Short Version: What are commands supposed to do in PureMVC?  What do your commands typically do?

-----------------

Long Version

First, some context on why I ask...

I consider myself an expert in Cairngorm.  Back in 2006, Thomas Burleson from Universal Mind and I were arguing daily about the best way to allow View's to know what was going on in the Controller layer of Cairngorm long before the UM Cairngorm extensions were released.  If you looked at most of the examples of the time, they assumed all Commands really did is set data on the ModelLocator, or performed other application logic (or even business logic depending on how you define it).  As your app would increase in scope, a simple 1 line of setting the ModelLocator (singleton from which you bind View controls to) would no longer be the case.  Most applications I worked on, both those that had a heavy back-end usage, and even those that only used 1 or two services to save & update data still would have pretty complex commands.  To me, it clearly seemed like Cairngorm was doing its job.

However, even simple things like errors couldn't be easily handled by View's.  You'd see horrible examples of Alert dialogues being thrown in Business Delegate's or Commands.  There were decent attempts at keeping the View references clean, sometimes using interfaces, etc... but at the end of the day, it'd be tightly coupled to the View, or Views.

Then, Joe Berkovitz released MVCS, although he didn't mean for his 9 page DevNet article to imply "MVCS was a true framework".  Inevitably, it was.  It showed people that you can implement MVC almost to the letter, and it still works great.  One side effect, however, was if you look at Joe's Controllers, they clearly show how far abstracted away Cairngorm's Commands are from the View's.  MVCS controllers can dispatch events, thus giving you very intricate information of what is happening to the state if your app, a service... anything you deem worthy of dispatching an event for, and a View can optionally listen in, and react accordingly.  This becomes very important in regards to state.  If you Mediator code (usually a higher level View in Cairngorm) managing application state, using those events makes it really easy to correctly react.  In Cairngorm, however, there wasn't a way to do that.  So, we created callbacks so Commands could dispatch their state.  It was an extension on top of Cairngorm, and did require some learning time for those already familiar with Cairngorm, but at least it stayed out of your way, tucked underneath inheritance.  It's very similar to the UM Cairngorm Extensions of today.

Now, you could build View's with confidence they'd know if a login actually worked our not without binding to a bunch of singleton state variables.  Sometimes really complex things would happen, and binding to a variable wasn't enough; the context you needed could be contained in an Event.

So, Commands could call web services with context, update your data model, and adjust application state.  It worked great, although, the up-time to get started gave rise to code generators.  Once your project was underway, you really didn't need them anymore.

Enter PureMVC

When PureMVC came out, I saw some things I loved, and some things I hated.  After a harsh blog entry, I learned a lot, but still didn't know enough.  Putting my money where my mouth is, I used it on 2 client projects, one Flash for Hyundai's website, and one for a huge Flex product.  After both projects, I get everything about PureMVC... except Commands.

Coming from Cairngorm, Commands were the lifeblood of your application.  The Business Delegates got your data, you stored it a ModelLocator, a Factory potentially parsed your data... but nothing complicated at all.  All the hardcore code was either in your higher level Views, or Commands.  The Commands would ask for data, get it, and do stuff with it.

That doesn't seem to happen in PureMVC.  My Proxies basically get the data, modify it, and send notifications on if something important changes.  My Mediators either ferry requests so my Proxies can get updated, and in turn they funnel data back.  The system works as advertised... except Commands.  They basically don't do anything important.  The documentation talks about re-use, but since they themselves cannot listen for notifications, all my Commands end up doing is making sure a Proxy is in fact registered, a Mediator is in fact registered, and calling a method on a Proxy that the Mediator was more than capable of doing.  I've talked to another guy on Twitter who already had this issue, and just has his Mediators call the Proxies directly.  I'm liable to agree.  Without Commands having the ability to recognize HOW the data has changed, they really can't do all of the application logic... just half, and the half of initiating the operation.  The Proxies end up managing both the data model as well as that logic.  That's ok with me, but I remember the documentation on best practices clearly mentioning that you should really keep your Mediator's simple; listen to View events, and update them with notifications sent from Proxies.

In short, to me Commands seem useless beyond the required PureMVC plumbing of registering Mediators and Proxies... especially when you come from using Cairngorm.

Am I missing something?


Pages: [1]