Hi Greg, Just today I have been looking at an issue I posted on jira (http://jira.magnolia.info/browse/MAGNOLIA-2281) about the paragraph collections and started on working on the concept. However, during thinking through it I found several obstacle and at the end discovered that "something" was missing. Your post gave me a reason more to expand the "something" that is missing. (Just to be clear, I find it useful to discuss this theme now, before any major "things" are under taken, and I am not trying to "kidnap" your question :) )
The "something" missing was a SITE definition in magnolia (or a project as you referred before). So, the answer to your question would be that the third option is (by far) the best solution for the problem, at least for me. However, I would like to "expand" the question. For example, this could be useful for defining global (per site) paragraph collections as well (perhaps have an inherited paragraph collection ;) ) from different modules (for more please read http://jira.magnolia.info/browse/MAGNOLIA-2281).Then, there is the question of internationalization, or to be more precise, define a default (fallback) language per site. And so on.... (do not want to take it further because it not the main theme of the question, but if you accept to discuss it here, will be glad to take it further). So, just to be back on your question, what I think as a concept (regarding the reasons I putted before) the third option is the best. We have been using it for ALL of our sites. Perhaps not in the form as site (or project), but more as a language differentiator. For example, we have en (English) and mk (Macedonian) languages on our websites. So for each language we define a main (parent) node /en and /mk for each language. In those pages we define the banner, footer, global (site) labels and paragraph that we want to be inherited downwards. It has worked for us just fine. Hope this helps.. Regards, Vasko On Fri, Sep 26, 2008 at 6:48 PM, Grégory Joseph <[email protected]> wrote: > Hi all, > > I'd like to gather some feedback about how you structure your sites and page > hierarchies. I currently see 3 approaches to structuring a site's pages > hierarchy, and I tried to quickly describe them below. > > What I'd like to know is which one you're using (one of these 3 or something > else), why, and if there's any other advantage or disadvantage that you see > which I didn't list. I'd also like to know if and how you inherit content, > typically for footer paragraphs, for instance, which are likely to be the > same all over a website, or sections of it. > > One of the reasons I'm asking is to try and see how we could provide > "simple" solutions for content inheritance. (Because there are too many ways > to inherit content, and providing a solution for every single case would > just make it too complicated). > > Thanks in advance ! > > -greg > > ======== Single root page > The hierarchy looks like: > /home > /aboutus > /products > /aproduct > /anotherone > /etc. > > Advantages: > * Permissions are very simple to manage, especially if you add other roots > (for instance to handle different sites in a single instance) > * Make inheritance of static paragraphs (footer, ..) easy. > Disadvantages: > * URLs don't look nice unless some virtualUriMapping hackery is involved > (/home/products/aproduct.html instead of the more legible and elegant > /products/aproduct.html) > * It personally bothers me to have to open the home node everytime I > access the authoring environment, but then again, maybe I'm just too lazy. > > ======== No root page > The hierarchy looks like: > /home > /aboutus > /products > /aproduct > /anotherone > /etc. > > Advantages: > * The hierarchy reflects the URLs without any virtualUriMapping (except > one to forward / to /home) > Disadvantages: > * Inheriting "static" paragraphs is only possible by explicitely telling > templates where to get them from (i.e /product/aproduct can not guess it > should render the footer from /home > > ======== The middle-ground approach > The hierarchy looks like: > /myProject > /home > /aboutus > /products > /aproduct > /anotherone > /etc. > > Advantages: > * Permissions are easy to handle if we want to host another project in the > same Magnolia instance. > * URLs can look nice with a simple virtualUriMapping which will "hide" the > /myProject/ path. > * Inheritance of "static" paragraphs is as simple as with the "single root > page" approach. > Disadvantages: > * Lazy people will have to open an extra node when they want to edit pages > (unless we re-configure the menu and trees for them) > * Inheritance of "static" paragraphs is maybe not very intuitive for > editors, as they would have to edit the /myProject page (which is virtually > non-existant) to modify these. > > ---------------------------------------------------------------- > for list details see > http://documentation.magnolia.info/ > ---------------------------------------------------------------- > ---------------------------------------------------------------- for list details see http://documentation.magnolia.info/ ----------------------------------------------------------------
