On 2017-08-18 18:05, Brian Milby via use-livecode wrote:
What about a non-binary stack file format? Something XML based and
derived
from the actual in-memory stack object (would need to be integrated
with
the IDE/engine to be really useful though - to allow seamless/native
import/export).
I think Monte's lcVCS might well be a good starting point for that -
there's no real need to have engine support as long as we make sure all
the things you need to know to deconstruct / reconstruct a stackfile are
accessible from script (which is where the engine support kicks in).
That being said, there is one piece of engine functionality which would
make lcVCS and similar tools much simpler - the ability to ask the
engine for a LiveCode array representing the actual persistent state of
any LiveCode object. If you have an array which contains a faithful
representation of the persistent state, then you can write serializers /
deserializers to whatever text (or other!) format you like in LiveCode
Script (which is a much much better place for such things to be!).
There is a starting point here for this. In order to allow lcVCS to
support widgets (which can have arbitrary persistent state), we added a
new form to the 'export' and 'import' commands:
export <widget> to array <arrayVar>
import <widget> from array <arrayVar>
We also added 'is strictly' operators which allow you to detect the
actual dynamic type of a value, rather than what values it could be:
put "100" is a number -- true
put "100" is strictly a number -- false
This allows lcVCS to create a faithful representation (in JSON) of the
values in LiveCode variables - in particular, in those returned from
export/import widget.
The reason I mention this is that this ability really is the precursor
to eliminating the engine's dependence on a bespoke binary stackfile
format (which is actually a huge problem - for all kinds of reasons) -
if we had a fully faithful (in the strict mathematical sense!)
import/export array ability - a stackfile could just become an array
which has been encoded with any hierarchical data encoding format (of
which the arrayEncode format is one, JSON is another, BSON is another,
YAML is another, ...).
It might be that the part of lcVCS which does the JSON mapping might
well be completely sufficient - perhaps Monte could chime in here to
comment and remind me of the issues he had / faced with it.
I can recall one significant issue - the properties we set on objects
(or widgets - lamentably) are not necessarily reflective of the
persistent state. What I mean by this is that, in some case, you cannot
directly set one of the internal persistent state variables of an object
directly by a property - it can only be done by setting a combination,
or by other actions (I'd need to look through the engine code to remind
myself where this occurs).
However *that* is fixable - we make sure that there are suitably human
understandable properties for all objects which ensure you can easily
import and export them using just those properties. For widgets, it
comes to down to imposing a simple rule:
Any piece of state which is saved into the state array (on OnSave)
*must* be accessible by a public property.
This would actually simplify widget creation - as you wouldn't need an
OnLoad / OnSave handler at all then. It would just be a case of
serializing the properties which are marked as 'persistent'. This is one
case where I modelled the engine's behavior, and shouldn't have done - I
should have ignored how the engine did things and just gone with 'what
made more sense'!
Anyway, I'd suggest we start looking at lcVCS (in terms of its object
import/export - not the VC related aspects) and see what issues it has;
then look at starting to fix those issues in the engine; then look to
start adding array import/export methods for all LiveCode objects...
Assuming this is an interesting project someone (not looking at anyone
in particular ;)) would like to take up...
Warmest Regards,
Mark.
Mike Kerner wrote:
> I've been thinking of developing a deconstructor to use with Levure.
> The idea is that you would lay out the objects, but then the
> deconstructor would pull all the properties of each object, put them
> in a YML, JSON, or other similar file, and then they would be built in
> the app by script, when needed.
That would be handy. I've considered making one, but the cost/benefit
relative to other commitments here has prevented me from diving in. I
appreciate your interest in this, and know you'll do a fine job with
it.
While it's understandable that Git can't handle LC's binary files, one
of
the strongest benefits of "The xTalk Way" is visual design.
This is why so many of us have written libraries to automatically
instantiate mobile-specific controls for us from LC-native objects,
because
it lets us enjoy the fluid development workflow that characterizes
xTalks,
rather than defining objects by typing long blocks of object
definitions in
scripts, which is a very C way of doing things.
Automating use of Git through binary->script decomposers allows
developers
the full benefit of the best of both xTalk and lower-level workflows.
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
--
Mark Waddingham ~ [email protected] ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
