Example would be something with comments that are displayed on the show page. Default would get just the parent object and not query for the children at the same time. When you go to reference each child, it does the query then since it needs that additional info. N children results in N + 1 queries. But, if you add the :include, it's just 1 query.
def show hobo_show :include => :comments end On Sep 30, 8:44 am, Owen Dall <[email protected]> wrote: > Thanks for that hint about the :include option. Do you have a real-world > example you could share? > > Yes, as far as SEO in concerned, you are right that Hobo provides the > human-friendly URLs that are a very big help. > > -owen > > > > On Thu, Sep 30, 2010 at 10:33 AM, Matt Jones <[email protected]> wrote: > > > On Sep 29, 2010, at 8:46 PM, Scorpio wrote: > > > > Hi. I'm beginning to understand now how Hobo works (at long last) and > > > its no longer a "just make it work" thing for me. I've begun thinking > > > about some optimization. The first thing that came to mind were > > > database queries. I've noticed that whenever I call a page with say a > > > lot of children i get a lot of queries. I've also noticed that there > > > are a lot of queries in general. Is that normal hobo behavior ? Can it > > > be optimized in some way ? (sorry for asking a seemingly dumb question > > > but I figure since Hobo has so much "magic" inside it might just have > > > a solution for it) > > > Depends - the :include option can certainly reduce the load, and the Rails > > query cache (active in production mode, AFAIK) will smooth out a lot of the > > 'show fields from x' stuff that turns up in the development log. It's also > > pretty easy to add an include if needed (for example, in an index action): > > > def index > > hobo_index :include => :some_association_name > > end > > > > The second issue are the generations of the un-customized pages that > > > Hobo makes. I've been wondering whats better. fixed show.dryml etc or > > > the generated ones (load- and performance-wise). > > > I think there's a *tiny* amount of additional overhead to the > > auto-generated pages, as the render hook has to see if the app/views/ page > > exists before it calls the corresponding tag - but we're talking about a > > line or two of extra code, so no real difference. > > > > Last but not least. How does the Hobo auto generation and a Hobo app > > > in general work with search engines when it comes to positioning the > > > website? are there any issues I need to know or any tedious tasks I > > > need to undertake to make it work? (I've made Hobo add metadata to a > > > page HTML-style) > > > Not an SEO expert by any means, but Hobo (out of the box) does some things > > that search engines typically like: > > > - the default to_param includes the name_attribute (so you get paths like > > /projects/80-some-project) which apparently helps... > > > - pages have real URLs, not query params like in some frameworks (no > > /index.cfm?foo=bar&baz=wtf stuff) > > > - elements that are boosted in search importance (h1-h3 tags, the page > > title) contain relevant content by default > > > --Matt Jones > > > -- > > You received this message because you are subscribed to the Google Groups > > "Hobo Users" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<hobousers%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/hobousers?hl=en. > > -- > Thanks, > > Owen > > Owen Dall, Chief Systems Architect > Barquin Internationalwww.barquin.com > Cell: 410-991-0811 -- You received this message because you are subscribed to the Google Groups "Hobo Users" 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/hobousers?hl=en.
