On Wed, Dec 26, 2018 at 8:44 AM Sannyasin Brahmanathaswami via use-livecode <use-livecode@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 _______________________________________________ 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
