Musings on Architect, MVC, Nested Behaviors

[Brian Milby]

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 <use-livecode at lists.runrev.com>, wrote:
> J. Landman Gay wrote:
>
> > On December 27, 2018 2:36:16 PM Richard Gaskin via use-livecode
> > <use-livecode at lists.runrev.com> 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
> ____________________________________________________________________
> Ambassador at FourthWorld.com http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode