On Thu, 2004-09-16 at 21:45, Eric van der Vlist wrote:
> Hi,
> 
> I am looking into XLSGenerator.java to see how file uploads may be
> implemented and I am confused by the definitions of the inputs and
> outputs that I find in the source (taken from CVS on SF):
> 
>     public XLSGenerator() {
>         addInputInfo(new ProcessorInputOutputInfo(INPUT_REQUEST));
>         addOutputInfo(new ProcessorInputOutputInfo(OUTPUT_DATA));
>     }
> 
> and this paragraph in the documentation:
> 
> The XLS Generator works in a similar way. It typically takes a file
> uploaded by a user, finds the special markup cells and reconstructs an
> XML document. The generator has no inputs, and a data output containing
> the generated XML document.
> 
> (http://www.orbeon.com/ois/doc/processors-charts-spreadsheets#d188907e886)
> 
> Is that a mismatch between different versions? or is it possible that
> "request" inputs are by default connected to a serialization of the
> request? or what?
> 
> Also, from the code, it looks like the first parameter of the request is
> either a URL to the uploaded document or the base 64 encoded value of
> this document.
> 
> Is that the case and is that documented somewhere?

Hmmm... I have found some explanations in the code of
RequestGenerator.java:

/**
 * The request generator works like this:
 *
 * o Read config DOM (or obtain it from state cache)
 * o Obtain request DOM
 *   o Read whole request as DOM (or obtain it from context cache)
 *     o If content-type is multipart/form-data, special handling takes
place.
 *       o File items are read with commons upload, either in memory if
small or on disk if large
 *       o Only references to the file items are stored in the DOM
 *   o Filter the DOM request based on config
 *   o Serialize the DOM into SAX
 *     o References to file items are treated specially during the
serialization process
 *       o Small files are serialized, and the xs:base64Binary type is
set
 *       o Large files are referenced, and the xs:anyURI type is set
 *
 *   o FIXME: Request body processing is badly implemented!!!
 *   o FIXME: The upload code checks that the total request body is not
larger than the maximum
 *     upload size specified. But If many small files are uploaded, can
we potentially use a lot
 *     of memory?
 *
 *   o NOTE: In theory, it should be possible to stream without going
through
 *     the disk, but it would be harder to implement (especially dealing
with XPath
 *     expressions parameter selection, if any).
 */

Sorry for the noise!

Eric

> Thanks,
> 
> Eric
-- 
Read me on Advogato.
                                         http://advogato.org/person/vdv/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
orbeon-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/orbeon-user

Reply via email to