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. hope this helps Gaetano -- Sdk-public mailing list [email protected] http://lists.ez.no/mailman/listinfo/sdk-public
