Vadim Gritsenko wrote:
Daniel Fagerstrom wrote:
AFAIK the new sources can cover all use cases for the mentioned components (as well as doing plenty of new things):
Please add to your list FragmentExtractorGenerator and FragmentExtractorTransformer
Hm. Correction: this pair actually can not be replaced by the new sources, especially since it uses Store as a fragments storage...
I became curious so I took a look at the FragmentExtractor[Generator|Transformer].
The generator could probably be replaced if we extend the xmodule source so that it try to interpret a byte array as an XMLByteStream, and create a new input module that reads from a store. Another question is of course if it really would be a good idea to make the store available for users, isn't it more intended for internal use?
For the transformer we need to extend the xmodule source so that it can write to XMLByteStream, in this case we also need a sub-protocol e.g. xmodule:bytestrm to indicate that the output should be a XMLByteStream and not a DOM tree. A StoreOutputModule is needed and we still, AFAIU, need something like the FragmentExtractorTransformer that writes XML fragment within a certain name space to the xmodule source and replace the fragment with a URL to the stored object.
The latest version of Joost http://joost.sourceforge.net/, the STX implementation used in the STX-block have mechanisms for writing to multiple XML destinations and for using external SAX filters, (I have not checked in this version yet as I not have tested it). Using this, the FragmentExtractorTransformer could be replaced by using an STX script together with the xmodule source and e.g. a StoreOutputModule.
Anyway, while the above described components would give more flexibility in handling fragments, I have no use cases for the above described things, so maybe they just would be FS, do you have any use cases?
WDYT?
/Daniel
