Hi Gregory
I have spent some time figuring out a simple way to work out
inheritance. The idea used with the Sitedesigner is a little
cumbersome, especially if you have a large and deep hierarchy.
I am not quite satisfied with the solution, but for the time being I
am using the Data Module:
a) Add a property to the paragraph configuration, e.g. dataPath (in
association to "dialogPath".
b) Added a method to the "Paragraph" class: getDataPath(), which
returns the path to the data module node containing the content to be
inherited
In the Data Module I create a node type with the same name as the
paragraph. Then I copy the dialog tabs to the data dialog, extending
it. In the data dialog I add an radio button to select
1) "Inherit only if Paragraph has been selected by the author but has
no content"
2) Same as 1) but on field base
3) "Always inherit, even if Paragraph has not been selected by author"
So there are two ways I "inherit" from the Data Module:
a) Inherit only if the author has selected that paragraph but did NOT
ADD ANY content.
b) Inherit only if the author has selected that paragraph and add
content for fields which are empty (agreed, a little tricky,
especially if there are fields you want to be empty)
c) Inherit if the author has selected that paragraph, but with no
content or inherit if the paragraph does not exist at all (tricky to,
because you don't know where to put the paragraph)
An idea is to add a property "inheritContentPath" where a website node
path is the value and/or add "inheritContentRepository" (agrred, needs
a better name), so that e.g. also a node from the data module or even
an asset from the DMS could be "inherited".
Agreed, above is not the "simple way" I was looking for, but it works.
A good example is footer text. If the paragraph is empty (or does not
exist) it is taken from the data module. This way individual pages can
have their own footer text and new child pages can go back to the data
module entry.
Cheers
/giancarlo
On Sep 26, 2008, at 9:48 AM, Grégory Joseph 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/
----------------------------------------------------------------
