On 08.01.2004 18:00, Daniel Fagerstrom wrote:I just committed two new sources to the scratchpad:
* ModuleSource - That reads from streams and strings found by using an input module. It can among other things replace the StreamGenerator and the PartSource.
* XModuleSource - Read and write XML data (DOM and XMLizable) from input and output modules. Can replace the [Read|Write]DOMSessionTransformers and should also be usfull in flowscripts together with processToStream.
Really interesting. As I see simplification and better separation of concerns through abstraction what about deprecating the to-be-replaced classes? Can these new sources cover all the use cases the old classes did? What are possible downsides?
AFAIK the new sources can cover all use cases for the mentioned components (as well as doing plenty of new things):
StreamGenerator
---------------
The StreamGenerator can generate xml from the request input stream or from xml in request parameters, these cases can be replaced by:
<map:generate type="file" src="module:request:inputStream"/>
and
<map:generate type="file" src="module:request-param:form-name"/>
respectively.
No downsides that I know of. On the upside reading is not limited to XML anymore, and the source can be used in [C|X]IncludeTransformer and flowscripts as well, and also read from other places than the request parameters and input stream.
PartSource ---------- For PartSource the URI:
upload://formField1
can be replaced by:
module:raw-request-param:formField1
the mime type and content length will not be given from the module source though. I don't know if there are use cases where this information is necessary.
[Read|Write]SessionTransformers
-------------------------------
For the [Read|Write]DOMSessionTransformers as well as the [Read|Write]DOMTransformers submitted in http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23921, I would guess that the read functionality can be replaced by using URIs like:
xmodule:session-attr:field
together with the [C|X]IncludeTransformer or the FileGenerator. The write functionality can probably be replaced by using URIs on the same form together with the SourceWritingTransformer or doing the writing by using processToStream within flowscripts.
Writing to the xmodule stream is less efficient than using the WriteDOMSessionTransformer, as a serialize/reparse step is needed. This would be quite easy to fix, what we need is a convention for what interface a source that one can write SAX to should implement. I think that it would be most convinient to implement the XMLConsumer interface. Then the SourceWritingTransformer can check if the source implements XMLConsumer and in that case redirect the input events to that instead. For use within flowscripts, processToSAX can be used.
I'm +1 to deprecate the mentioned components, but I'm rather biased I guess.
/Daniel
