Stefano Mazzocchi wrote:
Paul Duffin wrote:
A problem that I ran into was that Serializers do not have access to the environment (Request / Response). This means that it is very hard to write sophisticated Serializers.
For example? (I think FOP and batik are both pretty sofisticated serializers)
Well... not that much actually: they are both ~200 lines of Java code and all they do is delegate to the underlying framework the XML events grabbing an OutputStream to write to. Agreed, SLOC are a sloppy metric but then again...
The real keyword, however, is not "sophisticated" in an algotithmic sense but "context aware": if a Serializer is not a SitemapModelComponent than there is no way it can decide based on context, be it a Request or any other information. We've been through this many times, and I wander from one side to the other so I have no clear decision in mind...
We worked around this by using it in conjunction with a Transformer that was given the environment and simply passed it on to the Serializer.
The problem with having an environment-dependent serializer is that the cache needs access to it because it might change its behavior depending on environment parameters.
Can't parse this. Care to explain?
The problem I'm having with Serializers having access to the environment is that they stop becoming non-ergodic.
Right now, serializers don't depend on run-time parameters. this means that if I save the exit of the serializer, I can avoid saving (in cache) the previous stage because they will be co-ergodic (if one changes, the other changes).
If you start adding the environment, this is not true anymore and we must cache *BOTH* the pipeline output (as xml) and the serializer output (as binary) because their ergodicity can be different.
This is the only concern I'm having.
If enough people believe this is a small price to pay, well, I'll turn my -1 into a -0 for giving Environment access to the Serializers.
Thoughts?
