Eric van der Vlist wrote:
> Where can I get and/or see it?
Actually the CVS and nightly build are moving so I'll let Dan answer this question once dust has settled down.
This said I haven't added anything that hasn't been mentioned on this thread.
>From what I see, the thing would be: > > * Derive a processor from ProcessorImpl.
Yes.
> * The actions (since there will be outputs) will be triggered > through the createOutput() method that expects a ProcessorOutput > object.
Yes.
> * This return object can be derived from > ProcessorImpl.ProcessorOutputImpl and the only abstract method > which is abstract and requires to be overloaded (if you have no > dynamic outputs) is readImpl that sends the output as a stream > of SAX events --the delegation processor doesn't overload any > other methods.
Yes.
> * The other methods to overload in > ProcessorImpl.ProcessorOutputImpl seem to deal with dynamic > outputs, cache and validation and I don't find it obvious to > guess their roles from the code. Could you briefly explain what > they are used for?
Ouch. I don't think I want to venture into the methods that deal with caching just now, except to say that the basic is just that a processor may return a combination of key / validity to tell processors downstream whether a result can be cached. Now how this key and validity is generated is the tricky part. Two classes, CacheableTransformerOutputImpl and DigestTransformerOutputImpl simplify this task a lot for two common cases:
1. Cases of transformers, i.e. the output only depends on the inputs (in the functional sense)). Examples: XSLT processor (be careful if you use non-functional extensions like calls to Java code), Validation processor.
2. Case where the output depends on the inputs and some third-party object like a JavaBean, etc. that can be represented as a digest. Examples: Request and Scope generators.
Note that we now have a nice test suite that tests quite a bit of the caching behavior (see tests-cache.xml).
For caching and inputs, it's easier, as you can call the readCacheInputAsXxx(), typically readCacheInputAsObject() if reading an input generates a configuration object.
> BTW, is the SimpleProcessor class deprecated or just reserved for simple > cases with only static outputs?
No, it's just reserved for simple cases, and is typically very useful with the Java processor.
> Eric (sorry to ask so many questions, but the doc is outdated and > the comments are sparse!)
Well not ALL the doc is outdated ;-) Some more documentation would be welcome about writing custom processors, agreeed. But that may have to go with a little bit of cleanup of the API here or there.
Still, the basics are pretty simple, i.e. you can write a simple processor in 30 seconds, but if you plan to add dynamic outputs, caching, etc. things become slightly more complex.
-Erik
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ orbeon-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/orbeon-user
