PluggableFactories

(this document is adapted from the message posted by stefanomazzocchi on the cocoon development mailing list)

Cocoon needs a simple way to deal with complex HTTP usages, such as binary uploading, XML-RPC, WebDAV or SOAP.

After a lot of discussion with Sylvain and input from many other people, I propose the introduction of a new sitemap element named "map:adaptRequest" that works by adapting the Request object into a more specific object that will parse the request and provide API-level access to the request.

For example, in case of file upload,

{{{ <map:match src="/whatever/upload">

• <map:adaptRequest type="upload">

  • <map:call function="upload()"/>

  </map:adaptRequest>

• </map:match>}}}

the upload() function will be passed a UploadRequest object which extends Request and will be 'upcasted' by the script that uses it.

The same thing can happen for WebDAV or SOAP, where specific protocol-specific Request handlers will be passed and will be used by the script.

Note that upcasting requires a contract between the request object user and the sitemap writer. We believe this to be reasonable.

NOTE: the above removes the need for the pipeline extractor *and* removes the need for pipe-aware selectors. In fact, pipe-aware selection is not required if the proper information is extracted from the pipeline and made available to the environment. Instead of using extraction, the request is adapted by a specific request factory.

The factories are made part of the sitemap components

{{{<map:components>

• ..

  <map:request-factories>

  • <map:request-factory name="upload" src="...">

    • <save-on-disk>true</save-on-disk> <map-upload>1000000</max-upload>

    • ..

    </map:request-factory>

  </map:request-factories>

• ..

</map:components>}}}

this also solves the issue with

• uploading granularity
• mailet request handling (that can be made a special request factory and evolve independently from our environment)

Comments

NicolaKen noted how "request-factories" might not be enough, since "response-factories" might also be needed (expecially for header-intensive contexts such as WebDAV). Should we introduce two factories, or have a ObjectModelFactory? -- stefanomazzocchi

Later on, Gianugo and I came to the conclusion that we needed an object model adapter, but that it could be better named "adapt-environment" than "adapt-object-model" which is less understandable. -- SylvainWallez