why can't to_xml read my mind?

rubyonrails-talk
1

Railsters:

I suspect the answer is "because they invented it before inventing eager loading".

The first minor issue with to_xml's refusal to read my mind is it's not DRY (like my mind!):

   Model.all(:include =>{ :this => :that }).      to_xml(:include =>{ :this => :that })

With eager loading, every Model instance has its internal @this member populated, and each This has its @that populated. So, instead of repeating the :include argument, to_xml could just find every populated @this and @that instance variable, and recursively call to_xml on it.

Do I misunderstand to_xml here? Or is it indeed refusing to read my mind?

Another, more minor issue: to_xml( :except =>[ :secret, :password ] )

Is there, instead, a :pass argument, to positively declare what we _do_ want? Negatively declaring the complete list of variables we _don't_ want (being most of them) is not just a waste of time, it's fragile if we migrate more secret fields into our model!

Please advise if I need to RFTM, grab a plugin, or else just live with to_xml's disturbing refusal to read my mind!

2

Railsters:

I suspect the answer is "because they invented it before inventing eager loading".

The first minor issue with to_xml's refusal to read my mind is it's not DRY (like my mind!):

Model.all(:include =>{ :this => :that }). to_xml(:include =>{ :this => :that })

With eager loading, every Model instance has its internal @this member populated, and each This has its @that populated. So, instead of repeating the :include argument, to_xml could just find every populated @this and @that instance variable, and recursively call to_xml on it.

I think it is hard for AR to distinguish between

m = Model.find ... m.do_something_that_causes_association_foo_to_be_loaded m.to_xml

m = Model.find ..., :include => :foo m.to_xml

In either case at the point that to_xml is called the association is loaded - if it just spat every loaded association into the xml it would be very easy to accidentally include stuff. Or you might include an association at the point of loaded to make calling a certain method (which you do want included in the xml) faster. While I can certainly see your point I like to think of passing :include to find as nothing more than an optimisation hint ( I will be accessing the associations soon - you would do well to load them) that we make do with until AR gets smarter.

Do I misunderstand to_xml here? Or is it indeed refusing to read my mind?

Another, more minor issue: to_xml( :except =>[ :secret, :password ] )

Is there, instead, a :pass argument, to positively declare what we _do_ want? Negatively declaring the complete list of variables we _don't_ want (being most of them) is not just a waste of time, it's fragile if we migrate more secret fields into our model!

That's :only

Fred

3

Railsters:

I suspect the answer is "because they invented it before inventing eager loading".

The first minor issue with to_xml's refusal to read my mind is it's not DRY (like my mind!):

    Model.all(:include =>{ :this => :that }).       to_xml(:include =>{ :this => :that })

With eager loading, every Model instance has its internal @this member populated, and each This has its @that populated. So, instead of repeating the :include argument, to_xml could just find every populated @this and @that instance variable, and recursively call to_xml on it.

Do I misunderstand to_xml here? Or is it indeed refusing to read my mind?

Another, more minor issue: to_xml( :except =>[ :secret, :password ] )

Is there, instead, a :pass argument, to positively declare what we _do_ want? Negatively declaring the complete list of variables we _don't_ want (being most of them) is not just a waste of time, it's fragile if we migrate more secret fields into our model!

Please advise if I need to RFTM, grab a plugin, or else just live with to_xml's disturbing refusal to read my mind!

4

Did my earlier reply not make it through ?

Railsters:

I suspect the answer is "because they invented it before inventing
eager loading".

(I don't think so. eager loading was there way back in rails 1.0/1.1
(possibly before, I just know it was there then because that's when I
hopped on board, to_xml only really appeared with the whole restful
drive (1.2 +))

Fred

5

Frederick Cheung wrote:

I think it is hard for AR to distinguish between

m = Model.find ... m.do_something_that_causes_association_foo_to_be_loaded m.to_xml

m = Model.find ..., :include => :foo m.to_xml

Then that's what I mean by reading my mind.

In a desktop app, where 'a' might live for a long time, and go thru many uses, to_xml should not guess that something_ was for some other purpose. In an event-driven app, then 'a' should be populated, used, and discarded.

Maybe we could compromise on a bit inside AR saying "I was loaded eagerly - mind-reading is now okay!"

Or I could just invent this:

   class ActiveRecord::Base      def find_to_xml(include, conditions = {}, xml_options = {})        find(:all, conditions.merge(:include => include).          to_xml(xml_option.merge(:include => include)      end    end

As an optimization hint, eager-loading might be more performant (yes it's a real word, now), hence the best way to use to_xml ought to be eagerly, hence we should get DRY about it.

While we have the subject open, where's an example of to_xml{}. The RDoc mentions it, of course, but does not illustrate it, of course.

In either case at the point that to_xml is called the association is loaded - if it just spat every loaded association into the xml it would be very easy to accidentally include stuff.

Our unit tests include checks that everything we don't want is not there!

Uh... really!!

Another, more minor issue: to_xml( :except =>[ :secret, :password ] )

Is there, instead, a :pass argument, to positively declare what we _do_ want? Negatively declaring the complete list of variables we _don't_ want (being most of them) is not just a waste of time, it's fragile if we migrate more secret fields into our model!

That's :only

Tx! Serves me right for reading RDoc output. I gotta cut down on that, huh?

6

Frederick Cheung wrote:

> In either case at the point that to_xml is called the association is > loaded - if it just spat every loaded association into the xml it > would be very easy to accidentally include stuff.

Our unit tests include checks that everything we don't want is not there!

Uh... really!!

Sure, but to me it would be very unobvious behaviour once you had got your failing unit test to see that the only code difference being that you called x.foo: calling an accessor (which feels like a read only / const thing) having a knock on effect on something unrelated would feel weird to me. Having the :include in find mark associations as being ok would be better.

Fred