Musings on Architect, MVC, Nested Behaviors

[Trevor DeVore]

On Wed, Dec 26, 2018 at 8:44 AM Sannyasin Brahmanathaswami via use-livecode
<use-livecode at lists.runrev.com> wrote:

> Always interest in improving (often terrifying beginning) my architecture,
> having read Andre's book on MVC.  It comes to mind that we could use a
> standard structure, like
>
> 1) Card or Group
> 2) Assigned in a unique view e.g. "behavior_viewHomeStory"
>         * handles the controls on the card and group
> 3) Assigned to that a Parent Behavios (nested)  general model e.g.
> "behavior_modelNarrative"
>           * handles getting quotes from database; XML/JSON from servers,
>
> and it this case
>
> --any "style" sheet assigned to the "stories" with should be used
> everywhere -- might consider a "view" component, but the style "brief"
> should be followed (mostly) everywhere app.. for things like quotes, pull
> Quote, headline, type faces.. it seems to be a "model" ... which could be
> over ridden with handlers  in the view script #2, as needed
> # 3 can to generalized and used everywhere.
>
> Anyone doing "Levure"? How does Levure handle this?
>

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. Levure helps you organize existing LiveCode features such as
libraries, behaviors, frontscripts/backscripts, widgets, and stacks with UI
elements.

That being said, Levure certainly encourages some of the MVC principles. If
you organize your stack files the way that Levure suggests then your code
will be separated from stacks with UI objects. For example, Levure
encourages you to separate each stack with UI objects into a separate stack
file and to use behaviors assigned to the card so that your code is stored
outside of the stack file. This separates your view (the UI elements) from
the controller (the card script stored in the behavior) and facilitates
simultaneous development between more than one developer. If your model
code is located in a library stack file then that code is stored separately
from the controller and view (stacks with UI objects and their behavior
scripts). Even if you decide to move some controller code into it's own
library stack file than the controller code remains independent of the
model and view.

Overall Levure doesn't try to force you into designing your app a certain
way. It encourages you to organize your application in a certain way and it
provides the Levure Helper interface. This organization allows Levure to
automate a number of things for you during the authoring and distribution
stages. It also helps you keep your sanity as you work on an app, as well
as when you return to the project months (or years) later after not having
looked at the code. The Levure Helper interface allows powerful features to
be added to a Levure application in a very straightforward way without
causing bloat within Levure itself.

Levure could certainly be extended via a helper(s) to add features specific
to MVC. Levure Helpers allow a developer to extend Levure in any number of
ways. If a developer came up with an MVC approach in LiveCode that required
libraries, frontscripts, certain configuration options, plugins or handlers
for use while working in the IDE, etc. then that functionality could be
wrapped up into a Levure Helper and dropped into an app. For example, I
have a helper I use internally that adds support for something I call
embeddable views. It allows me to treat groups that are on a card as their
own distinct stacks during development. It does this by automatically
updating the card whenever the stack representing the embeddable view is
saved. The helper also performs some operations when the application is
packaged for distribution. While this functionality is outside the scope of
Levure itself, it wouldn't be nearly as easy to implement without the
Levure app.yml configuration file and the hooks that Levure provides when
packaging an application for distribution.

One final thought I will add is this – whatever you do come up with,
consider if it will be understandable to you and other developers working
on the project later on. It is possible to get so wrapped up in separation
of code that it becomes very difficult to figure out how all of the code
works together when you revisit the project or try to add a developer.
Search for the right balance.

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