[xwiki-devs] [GSOC]get control of the conversion target temp file path
Hi Vincent, Sorry for not send the mail to the dev list. I just reply the mail. On Sun, Aug 24, 2008 at 4:15 PM, Vincent Massol <vincent@massol.net> wrote:
On Aug 24, 2008, at 6:40 AM, Wang Ning wrote:
Hi,
Yes, I think it's necessary, if the client want to control the output directory.
Ok I've thought a bit about this and here's what I propose:
1) Introduce a new ConverterOutput interface with the following methods: - saveImage(String imageName, InputStream imageData); - saveDocument(InputStream documentData);
2) Modify Converter interface to be:
void convert(InputStream sourceData, OfficeDocumentType sourceType, ConverterOutput outputData, OfficeDocumentType outputType);
3) Provide 1 implementation of ConverterOutput for the moment (+ a mock one for the unit tests of the Converter): XWikiDocumentConverterOutput. This implementation stores the result of the conversion in a XWiki Document (it's name/location is passed in the constructor). In the future if we need other implementations we could add them (like a FileConverterOutput, etc) but they're not needed for now.
Note 1: 3) is much cleaner and allows to move some of the code in the plugin to the XWikiDocumentConverterOutput class. Note 2: We can fully read the sourceData internally to save the input data to a file in a XWiki temporary directory (and thus control the output of the image files by jodconverter)
If want to get the xwiki temp directory to handle the output dir of conversion in OfficeConverter, I need use context.getWiki().getTempDirectory(context) to get the xwiki temp dir. But I don't think I can get the xwiki temp without a xwik context. Maybe the interface should change to void convert(InputStream sourceData, OfficeDocumentType sourceType, ConverterOutput outputData, OfficeDocumentType outputType, XWikiContext context) throws OfficeConverterException; WDYT? -- Thanks Wang Ning
Hi Wang, On Aug 24, 2008, at 7:17 PM, Wang Ning wrote:
Hi Vincent,
Sorry for not send the mail to the dev list. I just reply the mail.
On Sun, Aug 24, 2008 at 4:15 PM, Vincent Massol <vincent@massol.net> wrote:
On Aug 24, 2008, at 6:40 AM, Wang Ning wrote:
Hi,
Yes, I think it's necessary, if the client want to control the output directory.
Ok I've thought a bit about this and here's what I propose:
1) Introduce a new ConverterOutput interface with the following methods: - saveImage(String imageName, InputStream imageData); - saveDocument(InputStream documentData);
2) Modify Converter interface to be:
void convert(InputStream sourceData, OfficeDocumentType sourceType, ConverterOutput outputData, OfficeDocumentType outputType);
3) Provide 1 implementation of ConverterOutput for the moment (+ a mock one for the unit tests of the Converter): XWikiDocumentConverterOutput. This implementation stores the result of the conversion in a XWiki Document (it's name/location is passed in the constructor). In the future if we need other implementations we could add them (like a FileConverterOutput, etc) but they're not needed for now.
Note 1: 3) is much cleaner and allows to move some of the code in the plugin to the XWikiDocumentConverterOutput class. Note 2: We can fully read the sourceData internally to save the input data to a file in a XWiki temporary directory (and thus control the output of the image files by jodconverter)
If want to get the xwiki temp directory to handle the output dir of conversion in OfficeConverter, I need use context.getWiki().getTempDirectory(context) to get the xwiki temp dir. But I don't think I can get the xwiki temp without a xwik context. Maybe the interface should change to void convert(InputStream sourceData, OfficeDocumentType sourceType, ConverterOutput outputData, OfficeDocumentType outputType, XWikiContext context) throws OfficeConverterException;
I'd like that we keep the office converter (I'm not talking about the plugin) separate from xwiki core. The XWiki.getTemporaryDiredctory() method should be moved elsewhere but since this is not done for now I'd suggest you compute your own temporary directory for now and we'll replace the code with the right one later on. Thanks -Vincent
Hi Vincent,
I'd like that we keep the office converter (I'm not talking about the plugin) separate from xwiki core.
Do you mean that I should not use anything related to the xwiki context? But when I implement saveDocument(String inputName, InputStream documentData), I want to save the content(actually the text content) in documentData to a xwiki document. I need convert InputStream to the String. So I need the encoding for the conversion. I prefer the encoding configuration by context.getWiki().getEncoding(), but I can't get it if I can't access the xwiki context. Or we need a new input for the encoding. The XWiki.getTemporaryDiredctory()
method should be moved elsewhere but since this is not done for now I'd suggest you compute your own temporary directory for now and we'll replace the code with the right one later on.
Thanks -Vincent _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thanks Wang Ning
On Aug 25, 2008, at 3:07 PM, Wang Ning wrote:
Hi Vincent,
I'd like that we keep the office converter (I'm not talking about the plugin) separate from xwiki core.
Do you mean that I should not use anything related to the xwiki context? But when I implement saveDocument(String inputName, InputStream documentData), I want to save the content(actually the text content) in documentData to a xwiki document. I need convert InputStream to the String. So I need the encoding for the conversion. I prefer the encoding configuration by context.getWiki().getEncoding(), but I can't get it if I can't access the xwiki context. Or we need a new input for the encoding.
There are 2 parts in the office converter: * a generic part independent of xwiki core * the plugin (dependent on xwiki core) I'd like to keep the generic part independent of xwiki core as much as possible. Thanks -Vincent
The XWiki.getTemporaryDiredctory()
method should be moved elsewhere but since this is not done for now I'd suggest you compute your own temporary directory for now and we'll replace the code with the right one later on.
Thanks -Vincent
participants (2)
-
Vincent Massol -
Wang Ning