Musings on Architect, MVC, Nested Behaviors

[Trevor DeVore]

Ugh. I accidentally hit send before finishing the email. Here is the
finished version.

On Wed, Dec 26, 2018 at 1:09 PM Sannyasin Brahmanathaswami via use-livecode
<use-livecode at lists.runrev.com> wrote:

>
> With that in mind, though you say "Levure doesn't have a strong opinion
> one way or the other. There is no code that is designed specifically around
> the Model-view-controller (MVC)
> pattern." I want to start using you conventions. A few more questions...
>
> 1) "to separate each stack with UI objects into a separate stack
> file and to use behaviors assigned to the card "
>
> You keep these in a separate folder, 1 per stack and behavior(s)?
>

Yes. An app that fully embraces the Levure approach has a `ui` folder which
contains any number of sub-folders. Each sub-folder has a binary stack with
the UI objects and a `behaviors` folder with any behaviors. The wiki has a
visual:

https://github.com/trevordevore/levure/wiki/ui#adding-ui-stacks


> 2) Are behaviors loaded in memory when a user loads the card and
> "unloaded" from RAM when the  users closes card? That question goes to
> performance on libraries (open at start up) versus behaviors. I don't know
> if these texts script will impact performance, relative to a JPEG that you
> bring in, or a deep dbase query... Mark once said that scripts  are not "a
> problem" but more about what they tell the CPU to do and what  UI is doing
> to the pixels on screen - Images etc. But I keep wondering about that.
>

Behaviors attached to a UI stack will be loaded when the UI stack is
loaded. If you have the `destroyStack` set to true then the stack will be
unloaded when it is closed but the behaviors will not be. Monte recently
told me about the `revbehaviourses` function which can be used to unload
behaviors which are not in use by any other stacks. There is an open issue
to add support for removing behaviors from memory when closing a stack. See
here:

https://github.com/trevordevore/levure/issues/124


> 3) What do you think of nested behaviors,  where the "uber parent" is a
> model and the child behavior is a view/UI behavior, controller VS just
> keeping that model in libraries that remain open all the time? Goes to #2
> above.
>

While I've never done it that way (I have defined my model interfaces in
library stacks out of habits established prior to behaviors) there could be
value in that approach. Take a model interface that can have multiple
instances of the model. If you use a library script you have to pass a
model instance identifier to every handler in the library. Using a behavior
script attached to a card could remove that need as each behavior has it's
own instance of the script local variables used in the model behavior
script. The approach could also simplify callbacks because the target would
always be the object the model behavior is attached to.

Nested behaviors can become complicated but your project organization can
make that easier to follow. For example, models can all be stored in a
`models` folder. In Levure the `app.yml` file would tell you if the scripts
were being loaded as libraries or behaviors. You could even be more
explicit and store them in a `behaviors/models` folder so that it was
obvious they were used as behaviors. Or in `libraries/models` if you use
the library approach. The point is, the configuration and/or structure of
your project can educate a new person about how code is being used.


> My guess is that, if the code is being reused enough, it's just a text
> file (hardly adds to the RAM) , and debugging--  also "to figure out how
> all of the code works together when you revisit the project or try to add a
> developer" -- that using a library and keeping it in a library folder,
> probably keeps it simple/more easily understood.
>

See my comments above about organizing your files. If you have clearly
organized your files and you explicitly set up nested behaviors in your
code that initializes a stack when it opens, then it may be clear enough
for a new developer. A new developer may be more likely to see the chained
behavior if the behaviors are explicitly assigned in code vs having to use
vs going to the IDE to look up what the behavior chain is.

Regarding your questions about resource usage – I haven't seen your project
but usually I'm not concerned about having library stacks used for models
sticking around. While I haven't done any tests, I would be surprised if
they made much of a difference in how your project performed. Large image
files are going to have a more significant impact.

-- 
Trevor DeVore
CTO - ScreenSteps
www.screensteps.com