Hi both,
Yes, I'm still here reading.
I hadn't particularly thought of it as an issue impacting on the end
user's ability ("right"?) to design the ui, I thought it was me doing
that not them. It was more about the linked data issue and therefore
about designing so that cancelling an editing session really cancels
all the changes made in that session.
Seems to me the views here cause the problem (though being a good
idea from another perspective of course), how do different views of
similar data communicate, particularly when they're buffered, without
changing the underlying data store?
Yes, it makes for a messy ui implementation, and that was why I
started wondering about it, on the basis that often a design becoming
messy is a sign that it's going the wrong way. Unless of course,
it's just "real life" being messy, as usual.
More of the problem seems to (me to) be that SQL doesn't work on
buffered or "local" (to the data environment) data, but the tables on
disk, so if I've got a clutch of rows to be added as a result of a
users click I either can't do that, or I have to compromise the
local, buffered, data, and save data to a "real" file.
Sounds like picking it apart into separate screens *is* the way to
go, because that gives at least some indication of why some data has
been committed and other data hasn't.
Mark Stanton
One small step for mankind...
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
