Conductor API and to_xml

Petr Blaho pblaho at redhat.com
Mon Jul 23 14:00:41 UTC 2012


On Friday, July 20, 2012 11:43:12 AM Jason Guiditta wrote:
> On 20/07/12 11:32 -0400, Hugh O. Brock wrote:
> >On Fri, Jul 20, 2012 at 03:57:55PM +0100, Martyn Taylor wrote:
> >> Hi gents,
> >>
> >> There has been a few people raising similar questions around why are
> >> we not using the default rails renders and instead are using
> >> templates to render such things as xml.  I've put together my
> >> reasoning on choosing this approach below:
> >>
> >> I assume most people are aware that render :xml simply using a
> >> models to_xml method to parse the model.
> >>
> >> There are a few issues with to_xml.
> >>
> >> 1) to_xml uses elements for everything.  In our API we use
> >> attributes for special fields on our resources.  These special
> >> fields are used to identify the resource and give its location. i.e.
> >> href and id.
> >>
> >> We could extend to_xml to handle this for us.  But there are some
> >> other issues.
> >>
> >> 2) When returning lists and nested resources.  For example:
> >>
> >> <provider>
> >>   <provider_account />
> >> </provider>
> >>
> >> or
> >>
> >> <providers>
> >>   <provider id='1' href='' />
> >>   <provider id='2' href='' />
> >> </providers>
> >>
> >> We do not want to return the full resource just a reference to it.
> >> This is to reduce the size of response body.  to_xml will simply
> >> call to_xml on nested resources resulting in full resource
> >> representation.
> >>
> >> 3)  When rendering resources we only want to list its direct
> >> children, not grandchildren.  This is again to avoid sending whole
> >> object graphs in response bodies.  Using to_xml will result in every
> >> resource in the graph being rendered.
> >>
> >> 4) Templates are much more flexible.
> >>
> >> All of the issues I described above could be implemented by
> >> overriding the to_xml method.  Though it would get a little
> >> complicated.
> >>
> >> Templates are much easier to maintain and update.  In addition,
> >> using templates gives us more control on what we return on a
> >> individual model basis.  For example we could have logic in our
> >> templates that say things like.
> >>
> >> If STATUS == "Complete" then #don't return progress.  etc....
> >>
> >> To summarize.  Yes you can use to_xml which is the standard way to
> >> render things like xml, json in rails.  But there is a significant
> >> amount of work in implementing bespoke methods to make it work the
> >> way we need it to.  Templates are much more flexible and are easier
> >> to implement.  The downside of templates is that we have more files
> >> to maintain.  But there is nothing complicated about templates they
> >> are extremely trivial.
> >
> >An additional point in support of not using to_xml -- if you override
> >it in the model, now you have a bunch of effectively presentation code
> >in your model. Yuck.
> >
> >(you can use a decorator class to avoid this, but frankly I like the
> >template approach used here better.)
> >
> Funny, I just started this same debate in irc, though I favor the
> decorator approach, I think it is a cleaner separation of concerns,
> and addresses your point about view logic in the model.  That said, I
> personally think there should be as little logic in the views as
> possible.  Some of that logic may well belong in the model, some in a
> presenter/decorator type pattern.  Also, I put forward the idea that
> perhaps templates  could be used _in conjuction_ with decorator objects.
> 
> -j

+1 for decorator / presenter object encapsulating model object for views... 

-- 

With regards
Petr Blaho



More information about the aeolus-devel mailing list