Hi,
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.
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?
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?
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?
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?
Thanks,
Darek Paszkowski
********************************************
Hippocms-dev: Hippo CMS development public mailinglist
