RunRev for iPhone and iPod Touch
ambassador at fourthworld.com
Sat Feb 23 20:37:46 CST 2008
Björnke von Gierke wrote:
> You complain that my handler deletes the data, so it seems I wasn't
> clear enough. Obviously there's a custom property, called "data". This
> is what you use to show later parts of, or sorted stuff of, in the
> field. That is why I said "less memory efficient", because there's an
> additional property containing all the data. Sure, dividing the
> presentation from the actual data is much more work then having both
> in one, but it also gives you more control.
True, but if the object the data is stored in is part of the UI doesn't
it obviate many of the benefits of such separation? And if the data is
already stored in a database or other file then that's just an extra copy.
But storage aside, if we delete the ID field from the record before we
display it how do we know which record the user clicks on?
So in addition to adding the line of code about the itemdel, we need to
add another which stores the sorted list back into the property before
stripping out stuff for display, so we can later look it up in response
Doable, yes, but requires a bit of forethought, strategy, and time.
> Again I'm not against having all the data in a field, and I never
> claimed my way of doubling everything in a cprop is simpler. But no
> matter if runrev agrees that your proposal is a nice thing to have or
> not, it isn't available now.
As one who generally shares your interest here in focusing on immediate
solutions, I appreciate your help with the scripting.
But stepping back to the original context of this thread, this was a
conversation about relative ROI of proposed features, and this
admittedly tiny feature of zero-width columns was presented in
conjunction with independent column alignment.
The column alignment is absolutely critical for broad adoption in
business environments. And fortunately the good folks at RunRev have
previously acknowledged the importance of independent column alignment.
Extra bonus points that when they find themselves diving deep into the
field object to make that happen, they'll be in a position to add
zero-width columns for very little additional effort.
Like Linux support, this zero-width-column thang is a feature that, if
well-timed, has an unusually high ROI because it has such an uncommonly
And to bring all this back to the iPhone, if the API presents a very low
cost to port then of course it should be pursued at whatever point in
the priority list where its ROI ranking would put it. But the iPhone is
not a Mac, and I suspect there will be many differences in how apps must
be built for each.
Managing Editor, revJournal
Rev tips, tutorials and more: http://www.revJournal.com
More information about the use-livecode