On Thu, Jul 8, 2010 at 2:34 PM, Gaetano Giunta <[email protected]> wrote: > Kévin Surrault wrote: >> Hello everyone ! >> >> I have read the doc for all three types of relations (parent/children, >> common relations and attribute object_relation), and I need to know >> more about them : when to use a type of relation instead of another ? >> >> Any explaination or example would be very welcome. >> >> Kévin > > It is a wide-ranging topic, I fear. Hard to give (or even dream of) all the > details in a context-free discussion. > > Parent-child is the most simple relation - always think about it first. > > Of course whether you can use it or not depends on how you lay out content in > your site - that is in turn often dictated by either the urls that are > generated > (ie. "i don't' want no sticking 'footer' in my 'http://my.site/footer/contact > us' url) or by how fast it is for editors to add new content where they need > it. > > attribute_based object relations are imho superior to common relations - the > main difference being > - you can have many attribute-based relations in a single object, while you > have only a single 'common relations set' > - the editing interface for the two > > example of details that are hard to ascertain without context: expiry of > cache-blocks can only be set up via a 'subtree expiry' rule, not via 'node > expiry' or > 'class expiry' > > common use case: pages that are linked to from the footer. editors can > add/remove/edit them at will > common solution: in the pagelayout template, fetch those objects to show > links to them (this means grouping those pages somehow) > cache-related detail: how to make sure that the query to fetch the footer > items is executed as seldom as possible, while making the footer refresh as > soon as > needed? > possible solution: > 1. create pages that are to be shown linked from footer as direct children of > homepage - that will get you good-looking urls > 2. create a footer object as child of homepage (use a specific class or > section so it is invisible in the main-menu fetch) > 3. add for every object to appear in the footer a 2ndary location as child of > $footer > 4. put a cache-block around the code that fetches the children of $footer > node to display links to them, with a subtree_expiry key of $footer_node_id > > Point 3 is basically the best solution to the caching problem: with > subtree_expiry enabled, whenever an object that is a child of footer is > edited/added/removed, the cache-block will be expired - and it will never > expire otherwise. Using a subtree_expiry with a root node of 2 is otoh a bad > idea, > while using a purely time-based expiry means you loose freshness of > information. > > You might solve the same problem by putting an object-relation between the > footer object and footer-related pages, but I am not sure it would work with > automatic cache-block invalidation. > > The downside is that you will get a perfectly valid url > 'http://my.site/footer/contact us' which is never used on your site, as > 'http://my.site/contact us' is > used instead (use the main location of objects to get it), but google might, > by its sheer magic, find it out and index it someday - seo gurus will tell > you that > having the same page with 2 urls will lower your score... You might counter > that by having customized templates that redirect to the main obj location, > but that > will take you more dev time.
Don't fear the possibility of lower search ranking when the same content can be found on different URLs, this is easy to solve by letting the search engine know about the preferred URL. For more information, see http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html Best regards Kristof -- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
