Nullifying selected objects

[Paul Stone]

I'm looking at writing a mobwrite.nullify function that can be used to
nullify individual forms / form elements. This could be of use when
there are multiple, separate forms on one page and the user wants to
discard the changes made to one of them.

I'm looking at adding a nullify property to
mobwrite.shareObj.prototype, which would be checked during syncRun1_.

Does the above idea and approach sound reasonable? I also have a quick
question about mobwrite.unshare (since mobwrite.nullify will be
similar) - when an element is passed into unshare(), the function
loops through the shareHandlers in order to get the ID. Would it not
be easier just to use element.id? Or is this done in case there are
some shareHandlers that don't use an element's ID attribute?

Thanks,
Paul

[Neil Fraser]

2009/10/29 Paul Stone <ston...@gmail.com>:

> I'm looking at writing a mobwrite.nullify function that can be used to
> nullify individual forms / form elements. This could be of use when
> there are multiple, separate forms on one page and the user wants to
> discard the changes made to one of them.
>
> I'm looking at adding a nullify property to
> mobwrite.shareObj.prototype, which would be checked during syncRun1_.

That sounds good. I chose mobwrite.nullifyAll since I couldn't think
of a realistic use-case for partial nullification. Looks like I was
wrong.

However, there's something extra needed here. The shareObj is not
part of the API, nor is the mobwrite.shared property which is the only
way to look up a shareObj. I'd rather not make these part of the
official API since they are pretty low-level and doing so would
effectively tie my hands when improving MobWrite's internals.
Therefore I'd prefer that there be a function on mobwrite (copied from
unshare) that sets this property for the user. That gives a much
cleaner API.

> Does the above idea and approach sound reasonable? I also have a quick
> question about mobwrite.unshare (since mobwrite.nullify will be
> similar) - when an element is passed into unshare(), the function
> loops through the shareHandlers in order to get the ID. Would it not
> be easier just to use element.id? Or is this done in case there are
> some shareHandlers that don't use an element's ID attribute?

Correct. For everything currently handled by mobwrite_form.js, all
shared elements have an id property. But MobWrite is more general
than that. A hyopthetical mobwrite_svg.js might not have id
properties. Efficiency could be improved by changing .shared from a
list to a hashtable. However I don't think the extra complexity would
make any real-world difference since a) the number of shared objects
is probably less than a hundred, and b) unsharing is something that
happens rarely. There are some functions in MobWrite (particularly in
the DMP library) where I tear my hair out over single-operation
optimizations, but this isn't one of them.

Linking these two items together, if I ever decided to change .shared
into a hashtable, that change would be impossible if .shared was part
of the API.

--
Neil Fraser, Programmer & Wizard
http://neil.fraser.name