Hi Sebastian, I really appreciate the overview, thanks! That seems sensible, and is generally the way I do it when making something with commands. What I am getting out of this is that I probably should be going the command route more often than I do. I have an upcoming project that should be a nice test, hopefully I end up a convert : ).
Cheers, Robin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of sebastian Sent: Sunday, November 02, 2008 11:24 PM To: Open Source Flash Mailing List Subject: Re: [osflash] Q:Basic AS3 MVC question Sorry I used the word 'command' over-and-over when I meant to say 'controller' -- my brain is still a bit short wired from the week! ;) sebastian wrote: > Hi Robin! > > Ok, the storm has passed, > :) > > Regarding the utility of the Command in the MVC; it really makes sense > to not have the C part of the V or the M. > > Consider a button. > > If the button has to open a page, and you use a 'C' in your pattern, > all the button says is something like: > > commandObject.openPage(__nameOfPage); > > And the commandObject knows what to do. > > If you stuffed the button's logic in the view, it would have to be > where...? Well, it could be in the class that is calling the page -- > but what if other buttons on other class files also want to call a new > page, should they repeat the same code? If they did.. that would be > silly! And lead to headaches no less when you had to hunt for the logic! > > If you put 'openPage' in the Model, your model can become very > convoluted. Now I don't know about your projects, but it is common for > my Command and Model to be long enough as it is, if I had to combine > them it would become a real scroller! > > I've done projects with multiple MVC loops, or with a main MVC and > then some additional auxiliary classes/modules. If you don't use a 'C' > there is no central component, and you are back at the same problem as > before > -- stuffing similar commands in each Model, when it can be centralized. > > Another advantage is indeed the modularity; and the multiplicity. If > you have all your commands in one place, then in principle you only > ever need to write one AS3 class that deals with a specific action; > say opening and parsing XML, and then in every project you ever do > afterwards, you never have to write that code again. It's just > available for your command to call. Same with any other command. So > the command module can become a dispatcher; where in different > projects different stimuli result in different actions; but in all the > different projects, certain patterns are the same = certain code is interchangeable. > > This means that your code is not only easier to swap in one project; > but also between projects. Less coding & less debugging = faster > development = faster work for same rate = more money/hour and more > advanced applications in less time. > > Now making it all modular and super-MVC'ed out is totally unnecessary > in smaller projects; and on other's its totally insufficient! I > generally make a judgment call on how complex it is [now] and how > complex it is likely to become [in the future] and then choose an > architecture that corresponds. Modular code however is generally > always re-used or created [for next projects] when possible. > > MVC's are not hard to debug; I'd argue they are easier. Like I stated > in my previous email -- I actually find it a lot harder to debug code > that is all stuffed in one hyper-long class that is doing waaaay more > than it should than a simple class that is just doing one or two things... > > The only thing we are missing perhaps, is a way to code and view the > relationship-maps at the same time. So that you could 'see' > connections, as it is actually coded, as an UML diagram and then click > on each class to call up its source code... but hey -- that's probably > an idea better suited to a new OS project... > ;) > > As for 'real' flash apps; there are lots of RIA, "WEB 2.0/3.0" apps > out > there: > > http://www.adobe.com/resources/business/rich_internet_apps/examples/ > > Hope my feedback was of interest. > > Kindly, > > Sebastian. > > Robin Debreuil wrote: >> Hi Sebastian, >> >> Thanks for the overview, no objections with Commands from me, that is >> for sure : ). So as for the controller, is that basically an event >> mapper for you, or an 'event bundler' for commands, or maybe there is >> more you do in there? What kind of advantages do you find with having >> it separated from the model like that? Is it for organization, or >> reuse, or maybe your model is more for pure state data..? Also, not >> sure if I got that right, but are you keeping track of who is >> subscribing to events as well? (I don't do that, but I have a lot of >> utility code that tracks that kind of thing down on dispose >> -- maybe formally keeping track of that is a better solution..? hmm). >> >> As for maintaining code, I totally agree that MVC would mean you are >> at least at a reasonable/high level of code.. I had two projects in >> the last year that were a *mess* of garbled timeline code that needed >> fixing and scaling - ugh, that almost broke my sanity. My negative >> experiences with 'over-patterning' are more from Java -- where >> certainly the code was solid in the normal sense, just I found the >> philosophy hard to swallow as it got extreme. Ok, it actaully made me >> really really mad and eventually I had stop to do something else : ). >> I'm not sure if some people are more comfortable with that kind of >> thing, or if it was just made by people who think their crap is >> golden (honestly I'm still torn and undecided on that one). >> >> I sometimes think there are a whole bunch of "real deal Flash >> applications" >> that I'm missing. Certainly you can go far with solid design, and >> anything is possible with flash now -- I should probably spend more >> time looking around for that kind of thing. >> Oh, have to say, your comment on exceptions (so true) really brought >> me back to Antlr - where exceptions were used for flow control in the >> generated code. It was the worst thing in the world to sift through. >> It was a classic example of overdoing a good thing, in order to make >> it a bad thing. >> I'm sure >> it is better now, and I guess that is how we learn the limits of >> these things, but it still hurts when it bites you : ). >> >> Cheers, >> Robin >> >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of sebastian >> Sent: Tuesday, October 21, 2008 12:31 PM >> To: Open Source Flash Mailing List >> Subject: Re: [osflash] Q:Basic AS3 MVC question >> >> Hi Robin, nice input. >> >> In my experience, separation of the controller become more critical >> once you start using a Command Pattern or when you simply have a lot >> of different gestures [user initiated actions]. >> >> When to use a command pattern or not depends so far on one of two needs: >> >> 1. the need to separate each 'action' into a standardized object. So >> that you can add/remove actions easily. >> >> 2. the need for 'undo' or 'redo' history arises or will arise in a >> future release. >> >> I've built pretty complex apps using MVC, and I must say that the >> separation of all 3 was very useful. The command class was also >> supplemented in my hand-over documentation with a UML diagram listing >> all of the events who was listening to it and for what purpose. >> Having all the commands in one place is essential when you have many >> classes all working on something different... in our project the View >> area of the software had more than 30 classes alone! >> >> I've also taken over other peoples code, and so far the most annoying >> aspect of that is seeing code where classes are not properly >> encapsulated. So one class might be doing 3 things instead of just 1 >> thing or within a class that is called it also does things like build >> user components, buttons and then animate them. This makes debugging >> a pain. >> >> But by far the most problematic is 'hacks', where exceptions are >> created to accommodate for unexpected changes or troubleshooting and >> then the exceptions are dealt with in a backhanded manner which means >> that every new additional feature is going to have to deal with >> exceptions created by previous problems... >> >> Just like in real life, the messier the house becomes, the messier it >> tends to get! [there is an acceleration effect in place] >> >> Every once in a while I like to take the time to re-factor code, >> encapsulate, separate, simplify etc. This 'house cleaning' chore not >> only makes your code easier to use in the current project, but it >> also gives you RE-USABLE code for other projects!!! Which will >> quadruple (or >> more) your resulting speed at writing new code; and thus it can't be >> over stated enough... >> >> Sebastian. >> >> Robin Debreuil wrote: >>> I think if you read again, most people aren't 'against patterns' >>> (unless you equate not being super enthusiastic with being against, >>> not uncommon these days). Eventually everything has a place. As for >>> MVC, probably everyone separates the model and view to some extent, >>> and has since shortly after the Turing Machine. The controller idea >>> has always been the bastard stepchild of the arrangement though. MVC >>> like many other design patterns always assumes you are going to have >>> all these plugable options and things will be able to magically >>> interchange each part without problems. In reality you almost never >>> need to interchange things like that, and they will still break >>> assumptions when you do. So what you often end up with is a very >>> disconnected set of functionality, where it is hard to find and >>> trace through things. Of course if you write the code yourself it is >>> a bit easier, but stepping into someone else's code can be a genuine >>> pain (which >> I've done a few times). >>> While I'm certainly not 'against' patterns, I do think there is a >>> lot of kool-aid drinking going on, that you have to be wary of. In >>> general I find the end result of patterns is often somewhat >>> subverting things like static typing -- sometimes that is what you >>> need, but always that is something you want to avoid if you can. >>> Also they often hobble tools that can't pick up on these metapatterns. >>> Often they also make it very hard to find functionality in code. >>> They add a lot of noise, even with things like naming. These are big deals. >>> >>> As for an alternative to MVC, I would suggest that in most projects >>> it isn't necessary to separate out the controller (much of that is >>> already separated into base classes, and what isn't generally is >>> very specific and not reusable or confusing). At one point you know >>> what you need, you have lots of organizational tools in you language >>> and IDE, and there is absolutly no need to abstract things further. >>> Now please don't read that to mean never use MVC, certainly there is >>> a place. Usually though, it is used where it just complifies things. >>> Looking over the showcase at the pureMVC site for examples, we have >>> some websites, a video list, a task list, and a 15 slider puzzle. I >>> don't think you need a diagram like this >>> http://puremvc.org/component/option,com_wrapper/Itemid,34/ for a 15 >>> slider puzzle. Not a knock on anyone, I'm sure some people are >>> comfortable using it, some were learning more about it, and no doubt >>> it is a solid implementation. Just the idea that the world would be >>> a >> better place if everyone programmed like this is wrong, imo. >>> Happy to hear counter arguments, esp wrt the controller part (I am >>> easily swayed by good examples : ). >>> >>>> "Why is this relevant to this list?" >>> If "approaches to making Flash based software better" isn't relevant >>> to this list please let me know. Open source is the ultimate water >>> cooler in the software constrcution conversation, because you can >>> debate with barrier free working code. If this is more for >>> announcments of OS products or something, my bad and sorry, but then >>> I >> clearly need a different list. >>> Cheers, >>> Robin >>> >>> >>> >>> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Jaakko Manninen >>> Sent: Monday, October 20, 2008 5:23 PM >>> To: Open Source Flash Mailing List >>> Subject: Re: [osflash] Q:Basic AS3 MVC question >>> >>> Most of you seem to be against using the pattern on this list. So >>> what would you suggest doing instead of using MVC to achieve the >>> same goals? MVC certainly has its applications and will inherently >>> help you organize things well in those scenarios, given a proper >>> implementation and use :) I'm sure everyone understands that it >>> doesn't apply universally to every software project. >>> >>> Why is this relevant to this list? >>> >>> Jak >>> >>> On Tue, Oct 21, 2008 at 12:14 AM, Scott Langeberg >>> <[EMAIL PROTECTED]> >>> wrote: >>>> I've shuddered to find classes typed: Model, View, Controller in >>>> projects I've been assigned to work on. ;) >>>> >>>> -Scott >>>> >>>> On Mon, Oct 20, 2008 at 3:28 PM, Robin Debreuil >>>> <[EMAIL PROTECTED]> >>> wrote: >>>>> For a horrifying look at over-pattern-itis, have a look at the >>>>> eclipse source code. Not to say patterns aren't useful, but they >>>>> aren't useful to the point that they should be treated as some >>>>> high level language construct (at least the ones that haven't >>>>> migrated to become that already : ). Often something being an >>>>> 'approved pattern' >>>>> is treated as sufficient justification to use it, which of course >>>>> is crazy. It is something like saying, 'my code has no bugs >>>>> because it has unit tests'. >>>>> >>>>> Computer Science at any time is 60% fashion -- you have to >>>>> constantly be on guard for these things. >>>>> >>>>> Cheers, >>>>> Robin >>>>> >>>>> -----Original Message----- >>>>> From: [EMAIL PROTECTED] >>>>> [mailto:[EMAIL PROTECTED] On Behalf Of sebastian >>>>> Sent: Monday, October 20, 2008 2:20 PM >>>>> To: Open Source Flash Mailing List >>>>> Subject: Re: [osflash] Q:Basic AS3 MVC question >>>>> >>>>> Not sure I understood all that was written below, presumably due >>>>> to English not being your first language. >>>>> >>>>> The advantage of using good design patterns is to ensure >>>>> future-scalability and the modularity of your code. >>>>> >>>>> I often come across code that is half-object orientated; where one >>>>> class does two things instead of one, or the code is not properly >>> encapsulated. >>>>> Design patterns, or a micro-architecture such as pureMVC help us >>>>> to ensure that our code follows proper separation or encapsulation. >>>>> >>>>> Naturally an MVC architecture is not required on a simple site, >>>>> nor is a micro-architecture on a simple MVC implementation; but >>>>> applied to the right scale/type of project, it can make all the >>>>> [long term] difference. >>>>> And a common micro-architecture makes it easy to understand new >>>>> projects when old ones follow identical patterns. >>>>> >>>>> I'm curious as to why you have such strong negative feelings... >>>>> have you struggled with projects that are over-structured? >>>>> >>>>> Kind, >>>>> >>>>> Sebastian. >>>>> >>>>> iteratif wrote: >>>>>> The whole question is: is what you spent pureMVC because you >>>>>> perfectly mastered the MVC model or rather lack of knowledge on >>>>>> the >>> subject. >>>>>> Because the use of abusive patterns in the frameworks have no >>>>>> meaning, it proves the lack of knowledge about the subject. >>>>>> Otherwise the GoF would have done it a long time ago. >>>>>> >>>>>> These frameworks do live that those who create and be a shame not >>>>>> good enough for you anlgais in the show technically. >>>>>> >>>>>> Indeed this is not the patterns or even less frameworks that >>>>>> guide a project, these are the needs. So if a project does not >>>>>> recquire model MVC not need to implement ... when it was well >>>>>> understood and we understand the full meaning of object-oriented programming ... >>>>>> >>>>>> bonne continuation >>>>>> Iteratif >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> osflash mailing list >>>>>> [email protected] >>>>>> http://osflash.org/mailman/listinfo/osflash_osflash.org >>>>>> >>>>> _______________________________________________ >>>>> osflash mailing list >>>>> [email protected] >>>>> http://osflash.org/mailman/listinfo/osflash_osflash.org >>>>> >>>>> >>>>> _______________________________________________ >>>>> osflash mailing list >>>>> [email protected] >>>>> http://osflash.org/mailman/listinfo/osflash_osflash.org >>>> >>>> -- >>>> : : ) Scott >>>> >>>> Helping your grandma on the interweb >>>> at: http://blog.criticalpile.com >>>> >>>> _______________________________________________ >>>> osflash mailing list >>>> [email protected] >>>> http://osflash.org/mailman/listinfo/osflash_osflash.org >>>> >>>> >>> _______________________________________________ >>> osflash mailing list >>> [email protected] >>> http://osflash.org/mailman/listinfo/osflash_osflash.org >>> >>> >>> _______________________________________________ >>> osflash mailing list >>> [email protected] >>> http://osflash.org/mailman/listinfo/osflash_osflash.org >>> >> >> _______________________________________________ >> osflash mailing list >> [email protected] >> http://osflash.org/mailman/listinfo/osflash_osflash.org >> >> >> _______________________________________________ >> osflash mailing list >> [email protected] >> http://osflash.org/mailman/listinfo/osflash_osflash.org >> > _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
