Hmmm. It does indeed open a temp copy of the file, but it's?a temp copy of a copy of the resource within the repository; it's incapable of checking out the resource from the repository so that users can actually make changes. Am I missing something?
----- Original Message ---- > From: Hussein Shafie <hussein at xmlmind.com> > To: Jeff Hooker <jeff at itwriting.ca> > Cc: "xmleditor-support at xmlmind.com" <xmleditor-support at xmlmind.com> > Sent: Saturday, June 20, 2009 2:31:19 AM > Subject: Re: [XXE] Using Helper applications when using a Virtual Drive plugin > > Jeff Hooker wrote: > > > > Having spoken with Bluestream, I have some more questions. > > > > Jim Tivy (Bluesteam) says that the basic problem is that XXE knows only of > > the > virtual path, and not of the actual filename of the resource that I'm trying > to > use a helper app to open. He has suggested that an intermediary Java app to > call > the Bluestream API and establish the name of the actual file in the cache > would > be the first step to successfully handing it off to a helper app. Currently, > he > says, when XXE asks for a resource, XDocs simply streams the resource down to > XXE and the Virtual Drive plugin handles the relationship between the file > displayed in XXE and the file in the repository. What's needed for making > helper > apps work is a more direct relationship where the virtual drive checks out > the > resource and then hands the name of the actual file in the cache off to the > helper app. > > > > Any ideas on where to go next with this? Does XXE have any built in ways of > accessing an external API? Could this be a custom command? > > > > What Jim Tivy (Bluestream) describes is specific to the way the XDocs > virtual drive plug-in has been implemented. The virtual drive plug-ins > implemented, and thus supported by XMLmind, do not work like this. > > What he suggests, passing to the helper application the filename of the > file cached by the plug-in, this filename being obtained using an XDocs > API, cannot work for any other virtual drive plug-in. > > We prefer to explain the simple, generic, solution to what is in fact a > generic problem. > > Let's suppose I want to open an SVG illustration in Inkscape. The URL of > this SVG illustration is "foo://bar/gee/wiz.svg" (where the support of > "foo:" URLs is implemented by the means of the "Foo" virtual drive plug-in). > > Needless to say that Inkscape knows nothing at all about "foo:" URLs! > > The trick is to specify that the helper application does not support > URLs at all, just filenames. > > To do that, simply use "%F" in the command template of the helper > application. See > http://www.xmlmind.com/xmleditor/_distrib/doc/help/com.xmlmind.helperapps.HelperApplicationEditor.html > > By doing this, XXE will make a temporary copy (on the local file system) > of the file to be opened. Then XXE will invoke the helper application > passing the filename of the temporary copy to it. > > Same? behavior if you want to edit the SVG illustration. XXE will first > make a temporary copy of the file to be edited. Then XXE will invoke the > helper application passing the filename of the temporary copy to it. > After this temporary copy has been edited in Inkscape, XXE will *upload* > the edited temporary copy in order to replace the original file. > > I've tested all this with Inkscape and an SVG file having an "sftp:" URL > and it works really fine. There is no reason why it wouldn't work with > an "xdocs:" URL.
