Why can't to_xml read my mind?

Rails
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!

–
Phlip

2

On Feb 21, 6:48 pm, Phlip [email protected] wrote:

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!

–
Phlip

4

Did my earlier reply not make it through ?

On 22 Feb 2009, at 15:46, Phlip wrote:

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 C. 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?

–
Phlip

6

On Feb 22, 5:23 pm, Phlip [email protected] wrote:

Frederick C. 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