On Fri, Jul 10, 2009 at 8:07 PM, John Maxwell<[email protected]> wrote: > https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/2373-record-sensitive-procs-for-to_xml > You need to return an array of Widget models via xml. The xml generated by > array_of_widgets.to_xml has all the attributes you would normally need, but > you also want to add the URL to view each widget individually in the event > that consumer of this feed want to access that record again without having > to query the whole string. Without this patch, you would have to either: > build an xml template (a chore just to get one extra attr) or break MVC by > hacking a URL generation method into the Widget model and referencing it via > to_xml's :method option. (There are also other, even less ideal options.)
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 [email protected] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
