Recreating a binary stack from xml text

Pete pete at mollysrevenge.com
Mon Feb 20 23:45:09 EST 2012


I find this a fascinating topic!

The following thoughts are related to to a tool that identifies changes
between versions of a stack.  Recreating a stack is another issue.  A full
blown version control system is yet another issue and it's entirely
possible that such a beast isn't possible with Livecode stacks if you want
all the features of a traditional version control system.  In fact, it
probably isn;t since nobody has come up with one yet!

It's interesting that the opinions seems to be towards using an existing
diff tool.  I understand that, but those tools are based on text
comparisons (I think) and  other than scripts, we're not talking about text
here, we're talking about objects.  Yes, the objects in a stack could be
reduced to text descriptions but somehow that seems artificial to me.

On the topic of renaming an object, I don't think this is really an issue
in this context.  Object IDs within a stack don't change (except for
stacks) so I believe any comparison has to be based on object IDs, not
names.  If the name of an object changes, it will simply be reported as a
change to that object, just like any other property change.  Of course this
ignores the new ability to change object IDs and other "legal" means to
change an object id, but if an object ID changes, then by definition it is
a different object; the original object would be reported as deleted ( or
still existing as the case may be) and the new one as being new.  I see
nothing wrong with that.

I would be tempted to assign an altID to stacks (if not already specified)
since they can and do change ID in a legal fashion but remain the same
object.

This is why I think the way to do this is with a database.  Each object
would have it's own primary key that would be a combination of its stack
(alt)id and its own object id and would bind the db tables together  to
uniquely identify that object.  The db would include a version ID for each
version of a stack file.  After that it would be easy to compare two
versions of a stack and identify changes of any sort to an object using
standard SQL and Livecode. For scripts, a gross comparison could be done
with SQL (if scripta<>scriptb) and if changes were detected, hopefully
there would be way to copy the scripts out to files, invoke a standard diff
tool to identify the exact changes, and get the results back for reporting
purposes.

As for datagrids, the controls that are permanent fixtures of a datagrid
are easily identifiable, the rest should not be considered in this scheme
since they change dynamically every time data is loaded into a datagrid,
not when the datagird structure changes.  The job of a version comparison
tool is to detect permanent structural changes, not temporal or data
storage changes.  The properties of the datagrid itself and the properties
of the controls in it's template are all that matters since the latter form
the basis for any temporary controls that are created in the datagrid.

OK, time for another glass of wine!

Pete

On Mon, Feb 20, 2012 at 7:05 PM, Alejandro Tejada <capellan2000 at gmail.com>wrote:

> Hi Geoff,
>
>
> Geoff Canyon Rev wrote
> >
> > [snip]
> > For FileMaker, it's the easy database, but equally important, it's the
> > fact
> > that all items -- scripts, layouts, columns, tables, etc. -- are
> > abstracted
> > from their names. In FileMaker, if you change the name of a table, then
> > everywhere in any script that refers to that table, the script changes
> > automatically to match. Change a layout name, same thing. That's
> something
> > I wish every environment I use could have. Given that FileMaker has had
> > this since at least 1994 or so, it's frustrating that no one else has
> > picked it up. It's one of those things that seems obvious once you've
> > experienced it </rant>
> >
> > So I agree, reconciling the source when someone changes the name of an
> > object would be a pain.
> >
>
> This is exactly the reason that drive me to ask
> if it is possible to rebuilt a binary stack from xml
> source: Does every control keeps its original ID?
>
> Because if that were the case, then it's only a matter
> of use only IDs to reference controls in the scripts and
> never, never use their names.
>
> This should be easy to add in the script editor as a menu
> option selectable by the developer:
> "Use only IDs References."
> In this way, every time that you compile a script, the
> script editor verify that after every reference to a control
> there is the keyword "ID" and a valid reference to an
> existing control or shows a warning to the developer.
>
> Another way is to make the conversion automatically
> in the script editor while compiling, adding the
> selectable menu option to:
> "Convert Controls Names to IDs"
>
> Of course, if there is a message to catch a name changed,
> like the message "selectionchanged" for selections,
> then it's just a matter of writing a plug-in to catch the
> renaming event and proceed to search and replace it
> in all the scripts... (Honestly, I find scary an automatic
> search and replace like that)
>
> Well, suppose that every challenge is sorted and it's possible
> to use xml files with version control software as GIT for
> teamwork in this platform, then...
> Would be possible to use the browser to edit scripts and
> control properties and using LiveCode Server to output a
> binary stack to download and run locally???
>
> Just a wild guess, but an interesting one!
>
> Al
>
>
>
>
> --
> View this message in context:
> http://runtime-revolution.278305.n4.nabble.com/Recreating-a-binary-stack-from-xml-text-tp4400122p4405848.html
> Sent from the Revolution - User mailing list archive at Nabble.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
>
>


-- 
Pete
Molly's Revenge <http://www.mollysrevenge.com>



More information about the use-livecode mailing list