I'd say there's still lots of things wrong :)
--
you say that call and send only pass strings, but they can pass aynthing,
including binary and arrays, so that seems to be wrong to me.
you say that you call librarystacks, but it's way easier to just let messages
fall trough to them, because they're in every objects message path, for
example:
put functionInALibraryStack("parametertext",anArray) into theResult
Incidentally, librarystacks are missing in your messagepath (after mainstack,
before backscripts)
In theory i like the "can be" connection between stacks and library stacks, but
then mainstacks can be librarystacks too. also _everything_ that has a script
can also be a front or backscript, so... dunnow.
you omitted behavior buttons.
where's parent of parent group ;)
--
i guess there's more that i didn't see, but the messagepath is really a beast,
especially if one is not used to its way of thinking. Incidentally, what is a
MVC, and why are you trying to create one?
you didn't say if you'd do a presentation next saturday, please confirm with a
yes or no :)
cheers Björnke
On 22 May 2011, at 12:56, Keith Clarke wrote:
> Ah, thanks, Björnke - you have successfully reset my frame of reference for
> this now. The message flow passes through ALL the various set containers
> whether or not there is a handler to catch (and optionally, pass) the
> specific message.
>
> I had the wrong model in my head from my initial research on the subject -
> primarily through misunderstanding Richard Gaskin's excellent article
> http://www.fourthworld.com/embassy/articles/revolution_message_path.html As a
> novice, I had no choice but to take the section headings literally - that
> 'LiveCode's Native Message Path' meant the full path - and the 'Extending the
> Message Path' meant inserting new handler containers into the native path.
> This is the model map was showing. I see now that these headings really imply
> 'Basic LiveCode Message Path' and 'Full Full LiveCode Message Path,
> respectively - which is the model you describe.
>
> So, I have updated my map and added my initial thoughts on an MVC code
> framework http://db.tt/AKtyMeD
>
> I'd be happy to walk through this on a Saturday event once it resembles a
> version of a partial truth! ;-)
>
> Any feedback most welcome.
> Best,
> Keith..
>
> Figure 2 in Richard's article
>
> On 21 May 2011, at 17:28, Björnke von Gierke wrote:
>
>> On 20 May 2011, at 15:45, Keith Clarke wrote:
>>
>>> It's probably about differences in 'brain-wiring' but I find that level of
>>> abstraction too difficult, when learning new concepts, training others or
>>> (the real purpose for my map) deciding where to hang the various lumps of
>>> code for my MVC application architecture.
>>
>> It's not really an abstraction to me, because all I need to think is of the
>> "flow". So the messages go up trough all the stations, unless they're
>> "trapped" by a handler. Besides then executing, that handler can even choose
>> to pass the message on (pass myMessage), to continue the "flow".
>>
>>>
>>> So, my map is based on a slightly more concrete 'object-level' model, where
>>> the message flows involve only those classes that have been instantiated.
>>
>> See, that confuses me, because there's no instatiating happening. An
>> object/card/whatever script either is in the path or not, thats how it is to
>> me.
>>
>>
>>> I will update the map to show message flows through both 'container
>>> classes' and 'instantiated objects'. That way, I should be able to confuse
>>> all of the people, all of the time! Maybe a Saturday evening presentation
>>> - now there's a threat ;-)
>>
>> I'll write you down for the Saturday in a week, ok?
>>
>> Björnke
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
