Re: Musings on Architect, MVC, Nested Behaviors
Andre Alves Garzia wrote: > Be aware that YAML is tricky to parse, there are better formats such > as TOML which are much easier and tend to be less error prone. It is > very easy to get some indentation wrong in YAML and move something up > or down a level. TOML is IMHO a better format for such stuff. > >YAML: http://yaml.org > >TOML: https://github.com/toml-lang/toml > > There is also StrictYAML which removes some problematic features from > YAML. Anyway, I think that if all you need is something that maps to a > hashmap that is not too deep (thats important) then TOML is a better > format. https://xkcd.com/927/ Story so far: Assertion: XML will solve everything! Reality: bloated Assertion: JSON will solve everything! Reality: If you happen to do everything in JavaScript Assertion: YAML will solve everything, and be human-writable! Reality: Sure, but it's so hard to parse not even robots can do it well. Assertion: TOML will solve everything, and be human-writable, and be easily parseable! Reality: I'm dizzy, and going to lie down. Wake me when anything actually solves all everything, or next Tuesday when the next serialization-format-du-jour is premiered as the thing that will solve everything, so we can all enjoy throwing away this week's code for a week with the new kid on the block until next week's kid on the block shows up. :) The longer I've been in this business the more comfortable I've become defining my own purpose-build formats as needed. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Re: Musings on Architect, MVC, Nested Behaviors
Be aware that YAML is tricky to parse, there are better formats such as TOML which are much easier and tend to be less error prone. It is very easy to get some indentation wrong in YAML and move something up or down a level. TOML is IMHO a better format for such stuff. YAML: http://yaml.org TOML: https://github.com/toml-lang/toml There is also StrictYAML which removes some problematic features from YAML. Anyway, I think that if all you need is something that maps to a hashmap that is not too deep (thats important) then TOML is a better format. On 28/12/2018 18:00, Richard Gaskin via use-livecode wrote: Sannyasin Brahmanathaswami wrote: > @ y'all about revision control of binary stacks and YAML properities > (front matter) for text only scripts.. cool musings! but they might > want/need different threads? One of your team members requested extending the format of script-only stacks specifically to support your project's goals. YAML is a notation for expressing name-value pairs in a format optimized for human writing, something we LC fans like in a language. It would seem to lend itself well to the request made here in support of your work. Not at all my intention to hijack your thread by exploring that option further to see if we can arrive at an actionable plan. On the contrary, it is in direct support of pursuing solutions specific to your needs. We could rename this part of the discussion, but since it involves nested behaviors, MVC, and architecture, and is occurring for the purpose of helping your work, if we did so you might miss something useful for you. ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
Mark Wieder wrote: > On 12/29/18 10:27 AM, Alex Tweedly via use-livecode wrote: > >> Could breakpoints also go in an LSON file ? Is there a way that a >> script can set breakpoints into a script? (i.e. not insert eh command >> into the script, but set a dynamic breakpoint like are stored in a >> binary-stack) ? > > There is indeed. 'The breakpoints' is the list of the currently active > breakpoints, and you can manipulate that list in memory as needed. > It's a cr-separated list of long id,line number. ^ this Everything in xTalks are objects with properties, and very few of those properties are read-only. A good reminder that LC is one of only two IDEs I've ever seen in the xTalk world (the other being Gain Momentum) in which everything we interact with is made in the scripting language itself. So when you see a Script Editor that can set breakpoints, you can trust that's using a property that can be set from script. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Re: Musings on Architect, MVC, Nested Behaviors
On 12/29/18 10:27 AM, Alex Tweedly via use-livecode wrote: Could breakpoints also go in an LSON file ? Is there a way that a script can set breakpoints into a script? (i.e. not insert eh command into the script, but set a dynamic breakpoint like are stored in a binary-stack) ? There is indeed. 'The breakpoints' is the list of the currently active breakpoints, and you can manipulate that list in memory as needed. It's a cr-separated list of long id,line number. -- Mark Wieder ahsoftw...@gmail.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
Re: Musings on Architect, MVC, Nested Behaviors
In another email on the list, Richard said something like : > relatively easy to use a parallel LSON file and load via a library and On 29/12/2018 18:03, Richard Gaskin via use-livecode wrote: Breakpoint support may well be a uniquely valuable addition worth considering. I rarely use them myself, but I can appreciate their utility for many. But if we go down that road we should probably ponder whether that's where the road ends, and if not how we want to travel the rest of that road. Could breakpoints also go in an LSON file ? Is there a way that a script can set breakpoints into a script? (i.e. not insert eh command into the script, but set a dynamic breakpoint like are stored in a binary-stack) ? Alex. ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
Quentin Long wrote: >> From: Richard Gaskin >> By what means would be indicate which properties we want saved there >> and which ones we don't care about? > > To a first approximation, I'd say that any property which has been > changed from the engine's built-in default value should be saved. One > would expect that the engine's defaults can be easily accessed for > such a purpose? If completeness were the goal that would of course be a good way to handle it. But is complete representation of all properties the goal with script-only stacks? The binary stack file format we've been using for decades does a complete job of retaining all persistent properties as-is, along with anything else a stack file can contain. Script-only stacks were added to the mix of options to allow us to factor code from UI in ways that work well with the many existing versioning systems. Expanding on that to transform them into a complete representation of a stack file may not be difficult, but is a different mandate. And if we err on the side of completeness we may find unwanted side effects for that intended purpose. For example, what if you slide a script-only stack out of the way to look at something, and then save it. If the format includes the rect the file is marked as changed, yet that change is not something the developer using a script-only stack would care about. So ideally there would be a way to flag rect as a property we don't want to track in the file. Or conversely, there could be a mechanism for flagging only those properties we do want, and ignore others. This seemingly-simple idea turns out to have some sticky implications, which is why, after many years of exploring various serialization formats for stack files, the team opted for script-only stacks as a simple solution for the most common use case. Breakpoint support may well be a uniquely valuable addition worth considering. I rarely use them myself, but I can appreciate their utility for many. But if we go down that road we should probably ponder whether that's where the road ends, and if not how we want to travel the rest of that road. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Re: Musings on Architect, MVC, Nested Behaviors
Sannyasin Brahmanathaswami wrote: > Richard wrote: >> Not at all my intention to hijack your thread by exploring that >> option further to see if we can arrive at an actionable plan. On the >> contrary, it is in direct support of pursuing solutions specific to >> your needs. > > I don't mind hijacked my thread. > > It just that I see it as important innovation. > > To make sure such a good idea that it was "hidden" "Showing" would be the submission of an enhancement request. At this early stage "hidden" is simply not in that appropriate venue for implementation recommendation, a discussion here among users of a proposed feature to make sure whatever we recommend truly satisfies our needs before we take the time of the core dev team to explore it further. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Re: Musings on Architect, MVC, Nested Behaviors
Bob Sneidar wrote: >> On Dec 28, 2018, at 09:49 , Richard Gaskin wrote: >> >> In the beginning, script-only stacks contained only a script. >> >> Later, accommodation was made to allow the behavior property there, >> using the "with behavior" clause. >> >> Now we're considering adding breakpoints. >> >> Are we sure that's where it ends? >> >> It might be. But are we sure? >> >> Using a paired LSON file for other properties is reasonable enough. >> Should that be used for breakpoints as well? >> >> Where should the dividing line fall with what's included in what used >> to be script-only stacks? > > I think most would agree with you on this Richard. It's like stack > files are evolving into flat files. Soon we won't need to write code, > we will just think it. It's kind of like a Star Trek episode, only for > software developers. :-) To be clear, I don't actually have a position on this to agree or disagree with. My questions are in earnest. There is obvious merit in script-only stacks. And the team has seen merit in adding support for behavior declarations in them. Whether we leave it at that or add support for other properties is an open question. I see merit both ways, esp. given the relative ease and flexibility of using a paired LSON file for properties. Indeed, that could be done with a library, requiring no engineering from the core dev team. Direct engine support is always easier for us, of course, but it wouldn't be the hardest thing we've ever done to put props in a separate file and have a handler that opens the script-only stacks and sets its properties accordingly. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Re: Musings on Architect, MVC, Nested Behaviors
> From: Richard Gaskin >> J. Landman Gay wrote: >> >> On December 27, 2018 2:36:16 PM Richard Gaskin via use-livecode >> wrote: >>> >>> Sounds like one more reason to allow stack properties as YAML >>> frontmatter in the file. Ever since I suggested that a couple >>> years back, the range of valuable use-cases keeps growing. >> >> I wouldn't mind if you poked them again about it. > > At your prompting I started to open an enhancement request for this, but > not long into it I hit on why they probably haven't done this yet: > > By what means would be indicate which properties we want saved there and > which ones we don't care about? To a first approximation, I'd say that any property which has been changed from the engine's built-in default value should be saved. One would expect that the engine's defaults can be easily accessed for such a purpose? "Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length" Read the webcomic at [ http://www.atarmslength.net ]! If you like "At Arm's Length", support it at [ http://www.patreon.com/DarkwingDude ]. ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
Trevor wrote: set the behavior of stack "MyStack" to the long id of stack "MyBehavior" BR: ahha... Simple enough to do; and then it you wanted to undo the "binding", you do it in the script editor itself. Trevor: " Perhaps the SE could use an update that shows the behavior assigned to the object of the script you are editing?" ditto that ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
I don't mind hijacked my thread. It just that I see it as important innovation. To make sure such a good idea that it was "hidden" BR Richard wrote: YAML is a notation for expressing name-value pairs in a format optimized for human writing, something we LC fans like in a language. It would seem to lend itself well to the request made here in support of your work. Not at all my intention to hijack your thread by exploring that option further to see if we can arrive at an actionable plan. On the contrary, it is in direct support of pursuing solutions specific to your needs. ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
I think most would agree with you on this Richard. It's like stack files are evolving into flat files. Soon we won't need to write code, we will just think it. It's kind of like a Star Trek episode, only for software developers. :-) Bob S > On Dec 28, 2018, at 09:49 , Richard Gaskin via use-livecode > wrote: > > J. Landman Gay wrote: > > > On December 27, 2018 8:54:29 PM Richard Gaskin via use-livecode > > wrote: > >> > >> At your prompting I started to open an enhancement request for this, > >> but not long into it I hit on why they probably haven't done this > >> yet: > >> > >> By what means would be indicate which properties we want saved there > >> and which ones we don't care about? > > > > I wasn't thinking that expansively. I'd be happy with just the ability > > to use breakpoints during development, perhaps tied to the Test button > > as the remote debugger is now. As Brian said, if we want it to act > > like a regular stack we can just use one. > > In the beginning, script-only stacks contained only a script. > > Later, accommodation was made to allow the behavior property there, using the > "with behavior" clause. > > Now we're considering adding breakpoints. > > Are we sure that's where it ends? > > It might be. But are we sure? > > Using a paired LSON file for other properties is reasonable enough. Should > that be used for breakpoints as well? > > Where should the dividing line fall with what's included in what used to be > script-only stacks? > > -- > Richard Gaskin ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
On Thu, Dec 27, 2018 at 10:43 PM Sannyasin Brahmanathaswami via use-livecode wrote: > ... > > BUT: " 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." > > That is a problem using "Navigator" (does not show nested behaviors) or > the Project Browser which simply as (2)(1)(5) too obscure > > " if the behaviors are explicitly assigned in code" > > How would you do that? Currently it is obfuscated from the developer by > the IDE > I was thinking of something like this in whatever code loads the stack that has the model attached to it: set the behavior of stack "MyStack" to the long id of stack "MyBehavior" > " script "behavior_MyAudio" with behavior "behavior_ListenUI" > > Does not appear in the Script Editor. I consider that a "deficit" > attribute of the "whole system" of nested behaviors. > I forgot about that. I always use SublimeText to edit my project scripts so I see the entire script. Perhaps the SE could use an update that shows the behavior assigned to the object of the script you are editing? -- 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
Re: Musings on Architect, MVC, Nested Behaviors
J. Landman Gay wrote: > On December 27, 2018 8:54:29 PM Richard Gaskin via use-livecode > wrote: >> >> At your prompting I started to open an enhancement request for this, >> but not long into it I hit on why they probably haven't done this >> yet: >> >> By what means would be indicate which properties we want saved there >> and which ones we don't care about? > > I wasn't thinking that expansively. I'd be happy with just the ability > to use breakpoints during development, perhaps tied to the Test button > as the remote debugger is now. As Brian said, if we want it to act > like a regular stack we can just use one. In the beginning, script-only stacks contained only a script. Later, accommodation was made to allow the behavior property there, using the "with behavior" clause. Now we're considering adding breakpoints. Are we sure that's where it ends? It might be. But are we sure? Using a paired LSON file for other properties is reasonable enough. Should that be used for breakpoints as well? Where should the dividing line fall with what's included in what used to be script-only stacks? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Re: Musings on Architect, MVC, Nested Behaviors
Sannyasin Brahmanathaswami wrote: > @ y'all about revision control of binary stacks and YAML properities > (front matter) for text only scripts.. cool musings! but they might > want/need different threads? One of your team members requested extending the format of script-only stacks specifically to support your project's goals. YAML is a notation for expressing name-value pairs in a format optimized for human writing, something we LC fans like in a language. It would seem to lend itself well to the request made here in support of your work. Not at all my intention to hijack your thread by exploring that option further to see if we can arrive at an actionable plan. On the contrary, it is in direct support of pursuing solutions specific to your needs. We could rename this part of the discussion, but since it involves nested behaviors, MVC, and architecture, and is occurring for the purpose of helping your work, if we did so you might miss something useful for you. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Re: Musings on Architect, MVC, Nested Behaviors
In some of my projects, I have a handler in my stack script to help with this. It requires one extra click (to step out of th handler) - but I often find it's worth that for the other advantages. The minimalist version is on mybreakpoint breakpoint end mybreakpoint while the fancier version is more like: on mybreakpoint pLevel if pLevel < gBreakLevel then exit mybreakpoint put item -2 to -1 of line -2 of the executioncontexts after msg repeat with i = 1 to paramcount() if param(i) is an array then printarray i, param(i) else put i &"::" & param(i) & "::" after msg end if end repeat breakpoint end mybreakpoint I don't have it in a standard library because I tend to customize what it does, whether it logs calls to a file, etc. as I go ... Sometimes I use a "level" fpr whether or not to break, other teims I name each call, and have a (global) list of named calls that should actually break, etc. Alex. On 27/12/2018 22:34, J. Landman Gay via use-livecode wrote: Yeah, I know breakpoints don't hurt in standalones but during active debugging you have to keep moving them around or deleting them to avoid unintended breaks. At least with red dots you can zap them all at once with a menu selection. I've had more than one brush with the law you mentioned. :) -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 27, 2018 3:40:31 PM Mark Wieder via use-livecode wrote: On 12/27/18 10:21 AM, J. Landman Gay via use-livecode wrote: I've heard you can insert hard-coded breakpoint commands in the script instead but I haven't tried that yet. (Then you need to track them down and remove them when they are no longer needed.) If you don't have remote debugging enabled then hard-coded breakpoints in a standalone app should have (almost) no effect. The mechanism in the engine that triggers breaks will fire, but if nothing is there to catch it then execution will continue as if nothing happened. That said, it's probably good practice to remove them before shipping anyway because of the Law of Unintended Consequences. -- Mark Wieder ahsoftw...@gmail.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 ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
On December 27, 2018 8:54:29 PM Richard Gaskin via use-livecode wrote: At your prompting I started to open an enhancement request for this, but not long into it I hit on why they probably haven't done this yet: By what means would be indicate which properties we want saved there and which ones we don't care about? I wasn't thinking that expansively. I'd be happy with just the ability to use breakpoints during development, perhaps tied to the Test button as the remote debugger is now. As Brian said, if we want it to act like a regular stack we can just use one. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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
Re: Musings on Architect, MVC, Nested Behaviors
I see nested behaviors and all behaviors in fact, like I see constants in relation to variables. Behaviors are or ought to be a structural thing fixed at startup, much like constants are declared at compile time and fixed. If a set of handlers needs to be declared, then that is what start using is for. Bob S > On Dec 27, 2018, at 20:43 , Sannyasin Brahmanathaswami via use-livecode > wrote: > > BUT: " 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." ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
That's an interesting idea! Bob S > On Dec 27, 2018, at 20:13 , Brian Milby via use-livecode > wrote: > > I’ve briefly looked at the load/save code and think that it would be doable > to extend the export code from just covering widgets to covering entire stack > files. That would yield a regular array that could be exported as YAML, XML, > JSON or some other format that would be Git compatible. (Only real issue is > ID conflict resolution on import - my take would be to allow the developer to > specify merge, replace, skip, or deconflict ID.) ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
Ha! Fixed... I have using Navigator for so long I have hardly touched the PB. And on the big monitor the tools tip are small, be yes, they are there! BR On 12/28/18, 1:29 AM, "use-livecode on behalf of Niggemann, Bernd via use-livecode" wrote: "too obscure"... in Project Browser those are ordinal numbers and as such not very informative. But the tooltip shows you the actual script they are referencing. ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
Sannyasin Brahmanathaswami wrote > BUT: " 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." > >That is a problem using "Navigator" (does not show nested behaviors) or the >Project Browser which simply as (2)(1)(5) too obscure "too obscure"... in Project Browser those are ordinal numbers and as such not very informative. But the tooltip shows you the actual script they are referencing. https://github.com/livecode/livecode-ide/pull/1508 at the request of Sannyasin Brahmanathaswami https://quality.livecode.com/show_bug.cgi?id=18176 maybe the tooltip helps. Kind regards Bernd ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
Well, this stimulated a quite a discussion. @Trevor: Thank you about tips on staying organized. An very good points on how useful it could be the have nested behaviors though you have not used it yet this was an important observation :" 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." Wow... BUT: " 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." That is a problem using "Navigator" (does not show nested behaviors) or the Project Browser which simply as (2)(1)(5) too obscure " if the behaviors are explicitly assigned in code" How would you do that? Currently it is obfuscated from the developer by the IDE " script "behavior_MyAudio" with behavior "behavior_ListenUI" Does not appear in the Script Editor. I consider that a "deficit" attribute of the "whole system" of nested behaviors. I put comments at the top of my "child" behavior, so that it appears the SE. //> This script has a parent behavior //> behavior_ListenUI @ Richard "Or maybe I misunderstand. Is the issue with script-only stacks, or with deeply-nested parentScript chains?" The "scary" thing about the original project, ( that Jacqueline referred to) was code,( not written by me or anyone here), that used Get and Set properties that sometimes went through four-five libraries before they "resolved themselves" to get what the calling function "wanted" and when one function call to a library would have done the same. Or to use, Jacque MO, to one huge stack script. It was not about script-only and deeply nested-parentScript chain. @ Jacqueline: I have refactored 95% of the code that drove us nuts before. Now debugging that is to 1- 3 libraries at the most. There are many libraries, but discovering "what is wrong" will take to you one or two at the most, "whew!" -- GIT has been indispensable, not only for collaboration, but the way it handles branches, being about to fetch revisions. @ Bob S. Very good and useful examples (dategrid) of how and why to use nested behaviors. I think my query was too generalized, like everything else "depends what you are trying to do" @at all -- Andre's "aagNetTracer" is the "bomb" for debugging, on the desk top and on the phone. He has "leaped frogged" far beyond the whole issue of breakpoint in code. @ y'all about revision control of binary stacks and YAML properities (front matter) for text only scripts.. cool musings! but they might want/need different threads? BR ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
Part of the reason is that it is a “script only stack” and as soon as you start adding other things it is no longer script only. If you need to store other things, then why not just use a binary stack file? Version control... use ScriptTracker (or some other method of script export that allows it). If you want to version control those other properties, then a more general solution would be warranted (like Monte’s work). I’ve briefly looked at the load/save code and think that it would be doable to extend the export code from just covering widgets to covering entire stack files. That would yield a regular array that could be exported as YAML, XML, JSON or some other format that would be Git compatible. (Only real issue is ID conflict resolution on import - my take would be to allow the developer to specify merge, replace, skip, or deconflict ID.) This solution would allow a dev to export the stack, remove the keys they don’t want saved, and create a file with these properties that can be loaded at runtime. The script itself would be left separate and the other properties would be merged. Of course this can be done now in pieces. But if import was in the engine and you didn’t need to version control the individual properties, it would be a one liner to import a LSON property file. Thanks, Brian On Dec 27, 2018, 9:53 PM -0500, Richard Gaskin via use-livecode , wrote: > J. Landman Gay wrote: > > > On December 27, 2018 2:36:16 PM Richard Gaskin via use-livecode > > wrote: > > > > > > Sounds like one more reason to allow stack properties as YAML > > > frontmatter in the file. Ever since I suggested that a couple > > > years back, the range of valuable use-cases keeps growing. > > > > I wouldn't mind if you poked them again about it. > > At your prompting I started to open an enhancement request for this, but > not long into it I hit on why they probably haven't done this yet: > > By what means would be indicate which properties we want saved there and > which ones we don't care about? > > For example, we only care about the behavior property if it's non-empty. > > Should that same rule apply to breakpoints? Would there be cases where > we wouldn't want them included? > > We probably don't want the rect saved, but what if someone does? How > would they indicate to save the rect? > > And so on for colors, and the rest. > > I'm assuming customProps should always be there, yes? Are there cases > where they shouldn't? > > Help answer these and I'll submit the request for their consideration. > > -- > Richard Gaskin > Fourth World Systems > Software Design and Development for the Desktop, Mobile, and the Web > > ambassa...@fourthworld.com http://www.FourthWorld.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 ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
J. Landman Gay wrote: > On December 27, 2018 2:36:16 PM Richard Gaskin via use-livecode > wrote: >> >> Sounds like one more reason to allow stack properties as YAML >> frontmatter in the file. Ever since I suggested that a couple >> years back, the range of valuable use-cases keeps growing. > > I wouldn't mind if you poked them again about it. At your prompting I started to open an enhancement request for this, but not long into it I hit on why they probably haven't done this yet: By what means would be indicate which properties we want saved there and which ones we don't care about? For example, we only care about the behavior property if it's non-empty. Should that same rule apply to breakpoints? Would there be cases where we wouldn't want them included? We probably don't want the rect saved, but what if someone does? How would they indicate to save the rect? And so on for colors, and the rest. I'm assuming customProps should always be there, yes? Are there cases where they shouldn't? Help answer these and I'll submit the request for their consideration. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Re: Musings on Architect, MVC, Nested Behaviors
On 12/27/18 4:13 PM, Mark Wieder via use-livecode wrote: Especially since there's already code in the engine to handle the "metadata" keyword for LCS. Er... I meant, of course, LCB. -- Mark Wieder ahsoftw...@gmail.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
Re: Musings on Architect, MVC, Nested Behaviors
On 12/27/18 3:18 PM, J. Landman Gay via use-livecode wrote: On December 27, 2018 2:36:16 PM Richard Gaskin via use-livecode wrote: Sounds like one more reason to allow stack properties as YAML frontmatter in the file. Ever since I suggested that a couple years back, the range of valuable use-cases keeps growing. I wouldn't mind if you poked them again about it. Especially since there's already code in the engine to handle the "metadata" keyword for LCS. Seems like that could easily be misused^H^H^Hrepurposed to handle properties, breakpoints... -- Mark Wieder ahsoftw...@gmail.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
Re: Musings on Architect, MVC, Nested Behaviors
On December 27, 2018 2:36:16 PM Richard Gaskin via use-livecode wrote: Sounds like one more reason to allow stack properties as YAML frontmatter in the file. Ever since I suggested that a couple years back, the range of valuable use-cases keeps growing. I wouldn't mind if you poked them again about it. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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
Re: Musings on Architect, MVC, Nested Behaviors
:-) > On Dec 27, 2018, at 14:37 , J. Landman Gay via use-livecode > wrote: > > It's to keep you safe, like the TSA. And if you complain they'll make you > debug with your shoes and belt off. ___ 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
Re: Remote Debugging (Was Re: Musings on Architect, MVC, Nested Behaviors)
I should have guessed why you wrote that. :) -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 27, 2018 2:40:30 PM Andre Alves Garzia via use-livecode wrote: Dear Jacque, I know too well the rabbit holes that lies deep into some LC projects. As Richard have guessed, by using a ton of behaviors and libraries, you can end up with code that you can't easily trace and also which becomes quite hard to debug. As Jacque and I worked on the same project, one that is quite hard to debug on mobile, I came to realize that we needed some better tools. To solve that I made a "Network Tracer" tool to help me debug exact those apps. Think of it as a message box with more features, allowing you to not only display text and variable contents but also trace back where those texts are coming from. The network tracer work over LAN so you can have the phone and LC IDE on the same wifi network and should just work. I made a video showing it working at: https://vimeo.com/296722452 There is more information about it at my homepage at: http://andregarzia.com/livecode/ Cheers andre On 27/12/2018 18:21, J. Landman Gay via use-livecode wrote: The issue is remote debugging. Script only stacks save nothing but scripts. Breakpoints are stored as custom properties which are lost when the stack is saved as part of a standalone, so when testing a mobile app they are gone and the debugger is unavailable. I've heard you can insert hard-coded breakpoint commands in the script instead but I haven't tried that yet. (Then you need to track them down and remove them when they are no longer needed.) Another way, which I did try, is to insert a temporary red dot breakpoint into the binary stack script and then step into the handlers in the script only stack from there, but in my case that meant stepping over a few hundred lines, which was tedious, and then when I got to the handler in question, the erroring line took over and ran to the end without stopping. I'd heard that once the debugger is triggered you should be able to add new temporary breakpoints dynamically, but when I tried that after stepping into the script only stack it didn't work. This was before the fix that removed the ghosted remote scripts, so maybe it would work now. At any rate, remote debugging a script only stack isn't easy and is sometimes impossible. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 26, 2018 10:51:25 PM Richard Gaskin via use-livecode wrote: ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
It's to keep you safe, like the TSA. And if you complain they'll make you debug with your shoes and belt off. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 27, 2018 3:48:41 PM Bob Sneidar via use-livecode wrote: Wait, they made that into a law?? Can't I even just be free to screw up anymore??? So oppressive! Bob S On Dec 27, 2018, at 13:37 , Mark Wieder via use-livecode wrote: That said, it's probably good practice to remove them before shipping anyway because of the Law of Unintended Consequences. -- Mark Wieder ahsoftw...@gmail.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 ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
Yeah, I know breakpoints don't hurt in standalones but during active debugging you have to keep moving them around or deleting them to avoid unintended breaks. At least with red dots you can zap them all at once with a menu selection. I've had more than one brush with the law you mentioned. :) -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 27, 2018 3:40:31 PM Mark Wieder via use-livecode wrote: On 12/27/18 10:21 AM, J. Landman Gay via use-livecode wrote: I've heard you can insert hard-coded breakpoint commands in the script instead but I haven't tried that yet. (Then you need to track them down and remove them when they are no longer needed.) If you don't have remote debugging enabled then hard-coded breakpoints in a standalone app should have (almost) no effect. The mechanism in the engine that triggers breaks will fire, but if nothing is there to catch it then execution will continue as if nothing happened. That said, it's probably good practice to remove them before shipping anyway because of the Law of Unintended Consequences. -- Mark Wieder ahsoftw...@gmail.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 ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
Wait, they made that into a law?? Can't I even just be free to screw up anymore??? So oppressive! Bob S > On Dec 27, 2018, at 13:37 , Mark Wieder via use-livecode > wrote: > > That said, it's probably good practice to remove them before shipping anyway > because of the Law of Unintended Consequences. > > -- > Mark Wieder > ahsoftw...@gmail.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
Re: Musings on Architect, MVC, Nested Behaviors
On 12/27/18 10:21 AM, J. Landman Gay via use-livecode wrote: I've heard you can insert hard-coded breakpoint commands in the script instead but I haven't tried that yet. (Then you need to track them down and remove them when they are no longer needed.) If you don't have remote debugging enabled then hard-coded breakpoints in a standalone app should have (almost) no effect. The mechanism in the engine that triggers breaks will fire, but if nothing is there to catch it then execution will continue as if nothing happened. That said, it's probably good practice to remove them before shipping anyway because of the Law of Unintended Consequences. -- Mark Wieder ahsoftw...@gmail.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
Remote Debugging (Was Re: Musings on Architect, MVC, Nested Behaviors)
Dear Jacque, I know too well the rabbit holes that lies deep into some LC projects. As Richard have guessed, by using a ton of behaviors and libraries, you can end up with code that you can't easily trace and also which becomes quite hard to debug. As Jacque and I worked on the same project, one that is quite hard to debug on mobile, I came to realize that we needed some better tools. To solve that I made a "Network Tracer" tool to help me debug exact those apps. Think of it as a message box with more features, allowing you to not only display text and variable contents but also trace back where those texts are coming from. The network tracer work over LAN so you can have the phone and LC IDE on the same wifi network and should just work. I made a video showing it working at: https://vimeo.com/296722452 There is more information about it at my homepage at: http://andregarzia.com/livecode/ Cheers andre On 27/12/2018 18:21, J. Landman Gay via use-livecode wrote: The issue is remote debugging. Script only stacks save nothing but scripts. Breakpoints are stored as custom properties which are lost when the stack is saved as part of a standalone, so when testing a mobile app they are gone and the debugger is unavailable. I've heard you can insert hard-coded breakpoint commands in the script instead but I haven't tried that yet. (Then you need to track them down and remove them when they are no longer needed.) Another way, which I did try, is to insert a temporary red dot breakpoint into the binary stack script and then step into the handlers in the script only stack from there, but in my case that meant stepping over a few hundred lines, which was tedious, and then when I got to the handler in question, the erroring line took over and ran to the end without stopping. I'd heard that once the debugger is triggered you should be able to add new temporary breakpoints dynamically, but when I tried that after stepping into the script only stack it didn't work. This was before the fix that removed the ghosted remote scripts, so maybe it would work now. At any rate, remote debugging a script only stack isn't easy and is sometimes impossible. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 26, 2018 10:51:25 PM Richard Gaskin via use-livecode wrote: ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
J. Landman Gay wrote: > The issue is remote debugging. Script only stacks save nothing but > scripts. > Breakpoints are stored as custom properties which are lost when the > stack is saved as part of a standalone, so when testing a mobile app > they are gone and the debugger is unavailable. Ah, yes. Now I understand. Thank you. Sounds like one more reason to allow stack properties as YAML frontmatter in the file. Ever since I suggested that a couple years back, the range of valuable use-cases keeps growing. -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Re: Musings on Architect, MVC, Nested Behaviors
The issue is remote debugging. Script only stacks save nothing but scripts. Breakpoints are stored as custom properties which are lost when the stack is saved as part of a standalone, so when testing a mobile app they are gone and the debugger is unavailable. I've heard you can insert hard-coded breakpoint commands in the script instead but I haven't tried that yet. (Then you need to track them down and remove them when they are no longer needed.) Another way, which I did try, is to insert a temporary red dot breakpoint into the binary stack script and then step into the handlers in the script only stack from there, but in my case that meant stepping over a few hundred lines, which was tedious, and then when I got to the handler in question, the erroring line took over and ran to the end without stopping. I'd heard that once the debugger is triggered you should be able to add new temporary breakpoints dynamically, but when I tried that after stepping into the script only stack it didn't work. This was before the fix that removed the ghosted remote scripts, so maybe it would work now. At any rate, remote debugging a script only stack isn't easy and is sometimes impossible. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 26, 2018 10:51:25 PM Richard Gaskin via use-livecode wrote: J. Landman Gay jacque at hyperactivesw.com I know there is enthusiasm for script only stacks and they are really helpful for those who use git. But when git isn't a target, the old fashioned way is really much easier to follow and debug. Being script-only is just the storage format on disk. Operationally, stacks are stacks, regardless of the storage format. Or maybe I misunderstand. Is the issue with script-only stacks, or with deeply-nested parentScript chains? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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 ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
What I did to make this easier is I created a Development menu in the stack menu that I remove in standalones. Openstack builds a submenu in the Development menu for all the behavior buttons (but they could be script only stacks) so that I can click Development/Scripts/ to edit the script of any of my behaviors. Obviously this approach could be expanded to include behaviors that the IDE is presently using. Bob S > On Dec 26, 2018, at 21:31 , Trevor DeVore via use-livecode > wrote: > > 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. ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
Precicely why I wanted to nest datagrid behaviors. This is working really well for me by the way. I have about 8 datagrids on what I call the Main Form, all running the same nested behavior inserted before the default datagrid behavior. If I need grid-specific code called from the behaviors I simply put that code in the datagrid script itself, then use dispatch, as it will not fail if it cannot find the handler (brilliant idea that). My other "form" stacks all have another nested behavior. Bob S > On Dec 26, 2018, at 21:20 , Trevor DeVore via use-livecode > wrote: > >> 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. ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
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 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 ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
On Wed, Dec 26, 2018 at 1:09 PM Sannyasin Brahmanathaswami via use-livecode 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. Or you could store them in a `behaviors/models` folder so that it was obvious they were used as behaviors. Or in `libraries/models There are come designs that could be simplified The nice thing about behaviors is that each instance has it's own script local variable values. Depending on what your model interface looks like you might be able to do away with having to pass an "id" to each model handler to uniquely identify the model associated with a particular view. > 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. > ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
On Wed, Dec 26, 2018 at 2:42 PM J. Landman Gay via use-livecode < use-livecode@lists.runrev.com> wrote: > Besides the impact of my current workload, I'm afraid this complexity is > what prevented me from continuing to work on Swami's project. There are > now > so many disparate parts and pieces that unless you have a firm knowledge > of > every library and behavior script, there is no easy way to participate. In addition, remote debugging doesn't work with script only stacks so > that's > an additional obstruction to overcome. > I thought I had used the remote debugger with iOS development before. I just add a "debugger" line to the script and the debugger opens up. Perhaps I'm misremembering though. What is it that doesn't work? > I know there is enthusiasm for script only stacks and they are really > helpful for those who use git. But when git isn't a target, the old > fashioned way is really much easier to follow and debug. Behaviors and script only stacks can lead to confusing designs if not organized thoughtfully. My feeling is that either approach can lead to a confusing architecture though. Whether you use all binary stacks or you mix in script only stacks, a lot of it comes down to organization and the ability to browse based on organization. -- 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
Re: Musings on Architect, MVC, Nested Behaviors
J. Landman Gay jacque at hyperactivesw.com > I know there is enthusiasm for script only stacks and they are really > helpful for those who use git. But when git isn't a target, the old > fashioned way is really much easier to follow and debug. Being script-only is just the storage format on disk. Operationally, stacks are stacks, regardless of the storage format. Or maybe I misunderstand. Is the issue with script-only stacks, or with deeply-nested parentScript chains? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.comhttp://www.FourthWorld.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
Re: Musings on Architect, MVC, Nested Behaviors
Besides the impact of my current workload, I'm afraid this complexity is what prevented me from continuing to work on Swami's project. There are now so many disparate parts and pieces that unless you have a firm knowledge of every library and behavior script, there is no easy way to participate. In addition, remote debugging doesn't work with script only stacks so that's an additional obstruction to overcome. I know there is enthusiasm for script only stacks and they are really helpful for those who use git. But when git isn't a target, the old fashioned way is really much easier to follow and debug. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com> Trevor DeVore via wrote: 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. ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
Happy Holidays Trevor Thank you for the thorough response. The Levure architecture, and what we came up with SivaSiva app is very close. It would not really be to difficult to port it one day to Levure. 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)? 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. 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. 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. Brahmanathaswami Trevor DeVore via wrote: 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. ___ 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
Re: Musings on Architect, MVC, Nested Behaviors
On Wed, Dec 26, 2018 at 8:44 AM Sannyasin Brahmanathaswami via use-livecode 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
Musings on Architect, MVC, Nested Behaviors
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? BR ___ 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
