I'm not sure QC could ever fully satisfy strict MVC design requirements due to the inherent nature of it (execution is driven by consumer/rendering patches, for a start), so I think the Controller/Viewer blur is a common difficulty that may be inevitable.
That said, I'm convinced MVC can certainly help structure big Quartz Composer projects. I don't consider there to be one perfect methodology, and we've spent years experimenting with different approaches. Currently in our projects we tend to have lots of discrete 'scenes' that are either shown or not shown. We tend to encapsulate those as separate QTZ files (which helps the team to work on them concurrently) and then have a top-level QTZ with an all-in-one controller JS patch that is responsible for logic and storyboard flow, triggering those scenes, etc. Data is loaded and processed by a separate section (again, usually in an external QTZ) and currently I'm favouring bundling all data, settings and values in a single Structure that gets passed along to whatever needs it, like a poor-man's global object. There are downsides to this of course. For example, our recent installation at Imperial War Museum in London (did I mention we have a big QC powered exhibit in the new Lord Ashcroft Gallery there?) passes about 4000-6000 values and objects (even images) in a single nested Structure object. Kind of mad but it works efficiently and massively reduced our noodle usage. So yes, it got difficult keeping track of what was actually in that Structure, especially as it's a royal pain to inspect them at runtime, but it made it very easy to separate model, view and controller into individual parts. Best, A. On 8 Dec 2010, at 12:20, Alastair Leith wrote: > "Also consider that this technique could help encourage a MVC paradigm within > Quartz Composer." > > It's apt that you mention that^ because MVC is exactly the reason I made this > JS patch suggestion. Currently I'm trying to model a prototype a MVC set-up > in a QC comp or even perhaps 2 or 3 comps (one for each part). (Happy to > share it when I get somewhere I'm modelling that Simon musical button game > for a case study). In QC it's a special challenge to do this as it's a > functional environment with no resources specifically devoted to MVC like > Cocoa has. > > Say one has 3 JavaScript patches for each of Model, Controller and Viewer, > does one pass messages between the JS patches with codified constants (eg: > var k_play_an_A_ON = new Number(); k_play_an_A_ON =1; > result.Message_to_Viewer = k_play_A_ON; ) to get parsed whenever the other > Module is ready to do so. Or could one have live 'State' booleans that > determine if, say, the Viewer module should be accepting Inputs and live > Structures that are immediately interpreted to, say, display particular > Output states. > > I've been reading a fantastic book of interviews with well known programmers > (Coders at Work) and one take-away I got was not to over generalise my code, > only bite off what I need to do — don't over-engineer for expansion/more > function than required; leave that for later. I'd like to have a go at MCV > inside QC because I have made an Application in QC that drives other .qtz > compositions. I'll probably use Quartz Builder to distribute the App, at this > stage. > > My Javascript patch for parsing the 28+ on screen button inputs is becoming a > bit unwieldy in terms of adding functionality without breaking existing > functionality — it's Viewer and Controller all in one, and then I have > another JS patch (hooked to tons of structure patch noodling) for the Model > which is not talking to any other JS patches yet just responding to manual > inputs. > > The idea of separating into MVC seemed like a good organising principle as > much as a code beautifying / rationalising one. Communication between the MVC > parts / modules is what I am probing / flailing around with at present. Any > advice welcome. > > Best to all > Alastair > Useful Design > > > > > On 08/12/2010, at 9:51 PM, Adrian Ward wrote: > >> >> Hear hear. >> >> rdar://8743194 >> http://openradar.appspot.com/radar?id=953401 >> >> >> >> On 8 Dec 2010, at 06:14, Alastair Leith wrote: >> >>> Would it be possible to implement composition/application wide globals for >>> the Javascript patches in a future QC revision? >>> >>> I know graph evaluation and free global variables could create a headache >>> if used unwisely, but it would be kind of neat at times to have a >>> composition-wide layer to read/write get/set to. Couldn't it just operate >>> on an ad-hoc basis read to whenever (whatever JS patch is being evaluated) >>> write whenever (same). >>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
