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 to clicks.
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 low cost.
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.
-- Richard Gaskin Managing Editor, revJournal _______________________________________________________ Rev tips, tutorials and more: http://www.revJournal.com _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
