saving within the save callback and bypassing the system's save

[naglists]

Hi,
I am considering deploying some code that will save a document within the
save callback during the first pass and return a do not proceed code so the
rest of the callback is not executed but also (and this is the key) avoiding
the actual save.

Huh? Yeah, me too.

My understanding of the save and save callback program flow is this:

1) A save is initiated.
2) The function assigned to the save callback is called with op=1. If the
function returns -1, the save is aborted. Otherwise, the flow proceeds to
step 3.
3) The function assigned to the save callback is called again. This is where
code to be executed prior to the save is placed.
4) Once the function is complete and returns, Editor performs a save.

Am I missing anything important? Is my understanding correct?

My plan is to perform the save during step 2 above ... the first call to the
function assigned to the save callback and abort further processing.

What do I need to consider in order to fully evaluate the risk of deploying
this strategy relative to my goals? In other words, what can "go wrong" or
what "goodness" will I be missing by circumventing Editor performing the
actual save (and anything else Editor does that I am not aware of)?

Is anyone doing this already for some reason? Have you run into any gotchas?

--
Paul Nagai

[bbeetcher]

Paul,

Regarding your question on possible gotcha's in performing the actual save operation during the op=2 call of a save callback, I can share the following which may or may not apply to your situation.

The current save call back design is limited in that it only provides for callbacks that occur prior to the actual save being performed by the editor. That is there is no post save callback. This has created a problem for our customization of the editor in that we're thrown into plug-in wars during save callback processing. In our environment we have 3 editor plug-ins that need to perform special processing during a save operation:

1. Our own SAS plug-in which needs to do pre-save processing to fill in certain attribute values on selected tags prior to the save occurring.
2. A mathflow plug-in which needs to do both pre and post save processing to manage how equations are displayed under the editor. The default (out of the box) implementation of this plug-in does as you are suggesting and performs the actual save during the op=2 call of its save callback then aborts further save processing.
3. An Acrocheck plug-in which under versions 1.4.3, and earlier, also needed to do pre and post save processing to manage how certain error conditions were displayed under the editor. The default implementation of this plug-in also did as you are suggesting and performed the actual save during the op=2 call of its save callback then aborts further save processing.

Of course, as soon as one callback routine aborts further save processing, any other callbacks are left out in the cold. Therefore, we had to modify the save callback processing for these plug-ins to turn off their respective default callback implemenations and replace them with one callback routine which then on its op=2 callback call, called each of the pre save functions that need to be performed, did the save, called each of the post save functions that need to be performed, then tell the editor to abort further save processing.

So, the gotcha that I can caution you about is that of running into plug-in wars if your editor environment might include competing plug-ins as our does.

The best solution for this concern would seem to be for the editor to support both pre and post save callbacks. To my knowledge that's not in the works yet.