Hi Darek,
darek p wrote:
We are a software development company, part of what we do is supply our
customers with webapps they need, and that inclues CMSes. Some time ago we
have chosen Hippo to be the basis for our CMS. Hippo's approach is quite
different from what we had before. That's why we need some advice or
suggestions of how you intended things to be used, so we wont reinvent stuff
or repeat any problems you ran into in the past.
Good idea :)
Suppose we want to build portal which has a lot of pages and each page
should have places (slots) that can hold data (banners, list of documents
and so on). Suppose that for most document slots can be filled with default
data, but we need to have the ability to pick something specific (lets say
for this page we need that banner, or a collection of other documents).
Now - based on our previous solution we came up with something like this (in
the repository):
- we defined two branches in main tree - documents, web
- "documents" hold data like news, clients - anything that contain
information, just raw documents maintained through the CMS
- "web" hold resources called pages (a few types of predefined page
templates) - the portals menu will be based on this structure
A typical page contains fields (slots) like: title, right-content,
center-content, left-content.
Contents of those slots can be: a lists of documents, a regular hippo
document (html), uri to a folder in the 'documents' branch. If content is
empty, we have defined some default values.
Now in the portal webapp (based on cocoon) we navigate through the
repository 'web' tree and construct the portals menu out of it.
A simple repository structure:
root
|
|---documents
| |
| |---news
| |--news1.xml
| |--news2.xml
| |---clients
| |--client1.xml
| |--client2.xml
|
|---web
|---page1.xml
|---page2.xml
|---folder1
|--page3.xml
And menu on the portal would look like this:
|-title of page1
|-title of page2
|-folder
|--title of page3
This approach is different than what you presented in the sample site, where
the structure is build solely in the sitemenu xml.
The problem with our solution is that it can contain a lot of reduntant data
(document and page which presents that document). Problem with the sitemenu
is that it can't offer that flexibility (i.e. for this particular document
we need this particular banner), additionally if the site is big then the
sitemenu is hard to maintain. Or maybe we have missed something about the
sitemenu approach that deals with those two problems?
Note that the "sitemenu" concept is not at all required or necessary to
build a site (or portal) with Hippo CMS. It is part of a pattern
commonly used in Hippo project, but you are free to choose any other
approach.
Actually as far as I understand your idea, it is not that different from
the sitemenu. Instead of describing the navigational structure (and URI
space) in one single document you do it through a separate tree in the
repository. It sounds like a reasonable approach in your case. I know of
at least one other Hippo CMS based project which uses a similar approach.
And advice that we need:
1. How do you structure the repository information for complex sites, and do
you use the same approach for simple sites (ie. does it scale down as well
as up) or do you have two approaches: for simple sites the sitemenu and for
complex sites some other approach?
Actually for simple sites, a direct 1-1 repository based navigation is
the most straightforward approach. For middle size sites, the sitemenu
would be a good choice. For large complex sites, your solution could be
a good option, as I said I know of one other project which uses a
similar approach and this is also a very large site.
2. Basing on your experience with HippoCMS, what do you think about the
approach we presented? Do you see any other flaws other than the redundancy?
Do you have an opinion of how to overcome that problem, or maybe this whole
approach we took is plain stupid because of something we don't see there
yet?
As far as I understand your explanation correctly, I don't think it is
stupid :) From my experience I think in defining navigational structures
for web sites there is always a trade-off between flexibility and
redundancy.
3. Maybe you know other approaches that are both flexible (allow the things
we mentioned) and do not duplicate information and are simpler than what we
came up with? Maybe we just missed something in HippoCMS or are biased by
our previous experiences and don't understand it?
I know that some project based on Hippo Portal use a slightly different
approach than the "sitemenu". I don't know the details though. Maybe one
of our portal gurus can comment on this (Ate? Dennis?).
Hope this helps!
Cheers
Niels
********************************************
Hippocms-dev: Hippo CMS development public mailinglist
