On 02/14/2011 11:14 AM, Craig Latta wrote:
[SNIP]
This scheme is readable, editable, easy to store, and amenable to
framework change (the four things you were after).
Thinking about this a bit more I realize one interesting aspect:
Your stuff is basically low level serialization support - right? So...
it all boils down to what kind of object model you pick. Now... come to
think of it - readable and editable? Not sure how you mean there,
counting the designer tool as the editor is kinda cheating :)
But that was not what I was thinking about - you say that it is
"amenable to framework change", and I just wrote that serialization
generally is really bad for that.
Thinking more closely, as I said, it boils down to the object model. On
nice way to make a GUI description to be very robust against change is
to let it be the representation of "a sequence of commands aimed at a
builder API". Thus, the actual UI framework can change all it wants, as
long as the builder API still works.
So, if your object model is such a "command sequence" then I agree, it
would be as robust as the same thing in Tirade. But... if your model is
the actual built UI then I don't agree that it is as robust - supporting
"migration" from one object model to a new one is kinda complex.
Anyway, I was not really meaning to argue against Spoon - my main point
was that representing a UI as a "recipe" for constructing it is probably
the most robust way to do it. And isn't VW specs actually something like
that?
And the corollary is that representing UIs as "snapshots" of them when
they are constructed (using serialization schemes) is IMHO not at all as
robust.
regards, Göran
