On Sep 28, 2008, at 9:20 AM, Will Scheidegger wrote:
We use approach 3.
The biggest downside to it for us: The "top level" pages are on
level 3 actually (level 1 = context path, level 2 = site root
folder). This of course is not optimal for google + friends. But
then again one could add url rewrites for the most important pages...
You don't need to add anything for "the most important pages", you
just have to deploy in the root context of tomcat (and/or use
mod_rewrite if you front it with apache), and write one single
virtualUriMapping for the top level (or you could also hide it with
mod_rewrite)
-will
On 26.09.2008, at 18:48, 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/
----------------------------------------------------------------
----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/
----------------------------------------------------------------
