I have no strong opposition to your proposal, but I feel it can only
ever address a subset of the common problems faced. Let me explain my
position here;
Like many other's i decided to override the .to_xml method because as
the vanilla xml generation is too inflexible. It's a rails app with
many similar (data-oriented) model classes for a (quite large) xml
api. Each class will need the same kind of xml generation.
These are the xml generation issues i've needed to solve:
1) The ordering of xml elements from rails serialization class is
alphabetical only. The xml i need to generate requires a specific
sequence and structure.
2) Nest multi level nodes / "has_many associations - wheras the
default rails xml serializer produces flat (single level) xml.
3) Supression of not-nil attributes. The rails output produces <tag
nil="true"></tag> basically this isn't conforming to the api and will
cause an error.
4) The xml builder isnt particularly effecient, as it doesn't use libxml.
The way i solved all of these problems was to create an "acts_as_"
plugin, and override the .to_xml method in that. I can then just
include a single "acts_as_" line in a model class which will use the
overriden method. This approach isn't particularly inelegant, i feel.
It also allows me to use libxml, and well, libxml - you can't really
beat it can you?
...I guess what i'm driving at here is that with this Proc patch -
just seems it wouldn't solve all of the most common xml generation
problems.
I guess your patch is particularly relevant in the context of generating
subtly different flavours of xml ? Like pass in one procA for one purpose, and
procB for something else?
As a rails contributor myself, don't get me wrong - I've no opposition
to this patch as it may turn
out to be of good use for other. It would just also be nice to see some
broader discussion about the xml generation topic. Indeed if anything
it would be nice to see more patches on the xml code.
dreamcat4
drea...@gmail.com