Stefano Mazzocchi wrote, On 18/03/2003 10.37:
Nicola Ken Barozzi wrote:...
Serializers, in the real world I mean, not in theoretical abstrations, are efectively fisrt class components, not just adapters. IMO they should be treated as such, because there is no real concrete reason IMHO why this lack of configurability continues till now, given that we have real needs for it that are not effectively solvable by other means.
Everytime I real need emerges, the architecture must change to reflect the need.
of course
I'm against changes that *DO* *NOT* reflect real needs but just lack of symmetry.
Again this symmetry thing...
If you think this has changed, write a proposal.
When my personal need comes, I surely will, although now I have other things to do. If others want to write a more detailed proposal (Luca for example) please do.
The *real* fact is that if I do:
xml data -> chart transformer -> batik -> png
It's 10x SLOWER than
xml data -> chart serializer -> png
This is not peanuts, this is a real need. And the serializer should be configurable as the chart transformer (same functionality).
Of course, we could make a transformer that creates a png image, puts it in the context, and then a serializer serializes it, but it seems to really stink.
So, how would you tackle the above real-world problem?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------