This is fascinating... I wasn't aware that anyone was using QC for
such large-scale projects. An eye-opener.
a|x
On 8 Dec 2010, at 12:55, 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-
[email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartzcomposer-dev/the_voder%
40yahoo.co.uk
This email sent to [email protected]
_______________________________________________
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]
