For whatever its worth, the 'massive structure in lieu of millions of noodles;' approach is one I've taken too as well, but not quite to your scale ;)
Seems rather silly but also looks like the best option of all of them. On Dec 8, 2010, at 7:55 AM, Adrian Ward wrote: > > 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 (Quartzcomposer-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/quartzcomposer-dev/doktorp%40mac.com > > This email sent to dokt...@mac.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list (Quartzcomposer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
