Feature request: Export system
Moderators: Eyal Redler, redlers, Ori Redler
-
- Knows everything, can prove it
- Posts: 120
- Joined: Thu Aug 10, 2006 1:48 pm
- Location: Boskovice, Czech Republic
- Contact:
Feature request: Export system
Hello!
Now that we have the nice XML file format people started requesting various export filters. It would be nice to have an official export system in Mellel, so that I could write an XSL style, put it in a bundle with some descriptory text and images, save it in some Mellel support folder and have it appear in Mellel in the export menu. This way even inexperienced users could start taking advantage of the XML file format; applying XSL transformations is not very convenient right now.
First version of the export system could simply read all XSL styles from ~/Library/Application Support/Mellel/Export, create menu items in the File/Export menu, ask the user where to put the exported file and then run the XSLT processor.
Now that we have the nice XML file format people started requesting various export filters. It would be nice to have an official export system in Mellel, so that I could write an XSL style, put it in a bundle with some descriptory text and images, save it in some Mellel support folder and have it appear in Mellel in the export menu. This way even inexperienced users could start taking advantage of the XML file format; applying XSL transformations is not very convenient right now.
First version of the export system could simply read all XSL styles from ~/Library/Application Support/Mellel/Export, create menu items in the File/Export menu, ask the user where to put the exported file and then run the XSLT processor.
-
- Knows everything, can prove it
- Posts: 113
- Joined: Thu Oct 20, 2005 2:59 am
I agree.
I think the first cut could be a little more fully featured with minimal extra effort if it were to run a export script (which could then call the xslt/whatever) rather than the xslt directly — that way you could run pre- and post-processing scripts without any further complication on the part of the Mellel application.
Obviously there would need to be a defined way to feed the script the file to export (or equivalent, perhaps by dumping the xml into a predetermined place in /tmp) and the place in which it was meant to be saved.
I think the first cut could be a little more fully featured with minimal extra effort if it were to run a export script (which could then call the xslt/whatever) rather than the xslt directly — that way you could run pre- and post-processing scripts without any further complication on the part of the Mellel application.
Obviously there would need to be a defined way to feed the script the file to export (or equivalent, perhaps by dumping the xml into a predetermined place in /tmp) and the place in which it was meant to be saved.
-
- Knows everything, can prove it
- Posts: 120
- Joined: Thu Aug 10, 2006 1:48 pm
- Location: Boskovice, Czech Republic
- Contact:
Right; maybe the script could be called with the input file and the output file as parameters? This way it could also easily extract the images stored in the source document [needed for serious HTML export]. On the other hand shell scripting is a bit fragile and more than a bit unsafe. I would certainly be nervous if I knew that every export runs a shell script from a third person… I’ll try to think of a safer and more robust solution [but doubt there is any] and in the meantime I’d love to hear what do developers think of this.Stephen Still wrote:I think the first cut could be a little more fully featured with minimal extra effort if it were to run a export script (which could then call the xslt/whatever) rather than the xslt directly — that way you could run pre- and post-processing scripts without any further complication on the part of the Mellel application.
-
- Knows everything, can prove it
- Posts: 113
- Joined: Thu Oct 20, 2005 2:59 am
That was one scenario I envisaged. Post-processing is also probably needed to emulate Mellel's "secondary font" feature.Right; maybe the script could be called with the input file and the output file as parameters? This way it could also easily extract the images stored in the source document [needed for serious HTML export].
Define unsafe. Every time you run anything written by a third party for the first time, including Mellel, you're putting yourself at risk to some extent. If it really worries you, a system for peer review of plugins (so that obviously malicious, unstable, or just bad plugins can be caned) is probably the answer.On the other hand shell scripting is a bit fragile and more than a bit unsafe. I would certainly be nervous if I knew that every export runs a shell script from a third person…
I don't think there is any, and to be honest, I'm not convinced that the dangers you contemplate are quite as bad as you seem to think. Mac OS X is standard enough a platform that shell scripts shouldn't be all that fragile (or fragile at all, if well coded), and trust issues are… well, pervasive, and no more of a problem in this regard than any other.I’ll try to think of a safer and more robust solution [but doubt there is any] and in the meantime I’d love to hear what do developers think of this.
-
- Knows everything, can prove it
- Posts: 120
- Joined: Thu Aug 10, 2006 1:48 pm
- Location: Boskovice, Czech Republic
- Contact:
“Well coded”, that is the point. (I think that majority of the plugins is going to be written by users.) Consider the following trivial export plugin:Stephen Still wrote:Mac OS X is standard enough a platform that shell scripts shouldn't be all that fragile (or fragile at all, if well coded), and trust issues are… well, pervasive, and no more of a problem in this regard than any other.
Code: Select all
#!/bin/bash
OUTPUT_FILE=$1
echo "Hello, world!" > $OUTPUT_FILE
This is just to illustrate my previous point, I am not saying we cannot use shell scripts for the export – on the contrary, scripting is a must if the export system is to be truly usable. It’s just we have to be careful about it if we go that way :)
-
- Knows everything, can prove it
- Posts: 120
- Joined: Thu Aug 10, 2006 1:48 pm
- Location: Boskovice, Czech Republic
- Contact:
Just an update: The export system could also give access to other file formats Mellel can save, so that I could write an export script to save (for example) into Mellel and PDF at once. This would solve the issue with people wanting a save+export feature.
You sold me!zoul wrote:Just an update: The export system could also give access to other file formats Mellel can save, so that I could write an export script to save (for example) into Mellel and PDF at once. This would solve the issue with people wanting a save+export feature.
-
- Knows everything, can prove it
- Posts: 113
- Joined: Thu Oct 20, 2005 2:59 am
-
- Knows everything, can prove it
- Posts: 113
- Joined: Thu Oct 20, 2005 2:59 am
Re: Feature request: Export system
On another note, it really would need _at least_ post-processing support if it were to handle formats like Open Document and Office Open XML, because both are packaged multi-file formats.zoul wrote:First version of the export system could simply read all XSL styles from ~/Library/Application Support/Mellel/Export, create menu items in the File/Export menu, ask the user where to put the exported file and then run the XSLT processor.