[Hippo-cms7-user] relative path to contents

Mansour Al Akeel mansour.alakeel at gmail.com
Tue Feb 9 15:25:12 CET 2010

Hello Ard
Thank you for providing these creative idea. I think as hippo grows we
will see more users contributing creative tips like this one. I am still
looking into the mutiple sites, nothing easy. But I loved the idea of
creating multiple sites with virtualhosts. Works great for an
organization with changing departments.

I have started working on muliple sites before I read your post. In
other words, I read your post after I created my own mess :)

I am wondering now about the reasons for designing the repo more like a
relational data. I mean, why not putting all the config/contents related
to a project under one tree in the repo, instead of using hipposys:softdocument ? 
I think this will be easier for tools to building projects, and will
open the doors for utilities to even migrate from other CMS's. 
It looks to me, that Hippo CMS can be customized to adopt this
structuring of data hierarchy easily, but I am wondering why not doing
it like this in the first place. What difficulties I may run into if I
try to change the way it's organized, provided I can get it to work :).

Here's a demo of what I mean:

    -> contents
    -> namespaces
    -> hst:configuration
        -> sitemap
        -> sitemenus
        -> pages
        -> components
        -> templates
    -> hst:contetns

May be the way it's now helps in the reusability of the components. So
components written for other projects can be used in the current one,
but the tree like structure doesn't limit the re-usability.

So the question is, what difficulties I may run into by changing the structure?
Thank you.

On Tue Feb 09,2010 08:15 am, Ard Schrijvers wrote:
> On Mon, Feb 8, 2010 at 11:41 PM, Mansour Al Akeel
> <mansour.alakeel at gmail.com> wrote:
> > Hello Ard,
> > No I am not subscribed to the HST dev list. I was under the impression
> > this is more related to the CMS, and looked here. I will subscribe to
> > the HST.
> >
> > I saw the post related to this issue, and went quickly over it. I will
> > give it a try soon. And yes, that's exactely what I am trying to do,
> > running multiple sites on the same instance. Thanks for the flexible
> > design of Hippo CMS, for allowing this, just like cocoon. I don't think I will have to
> > work again with mod_rewrite ;)
> Our goal indeed was to have runtime adding of subsites where no
> changing of httpd rules or what soever is involved. For example this
> website, http://nu.pvda.nl/, has about 600 to 700 subsites already
> (all municipalities in the Netherlands, for example
> http://amsterdam.pvda.nl/). Obviously, for adding a subsite, they do
> not want to need us, or have another rule to httpd conf for the 701
> subsite. They have one httpd rule:
>  <VirtualHost *:80>
>   ProxyPreserveHost On
>   ProxyPass / http://localhost:8080/site/
>   ProxyPassReverse / http://localhost:8080/site/
>   ProxyPassReverseCookiePath /site /
> </VirtualHost>
> For your info, I'll repeat some explanation of mine on the hst dev
> list some time ago here (it is for how to work locally with a context
> path in your urls, but on production behind httpd, do not have this
> context path in the urls that the HST2 creates for you):
> ////////////////////////////////////////////////////////////////////////////////////////////////
> Virtualhosts and context path info
> the 'show context path' is not only for 'external' links: it is for
> all absolute links (so everything that uses hst:link for example). So,
> Wim, I'll try to explain now:
> When you have your application running in a context, for example as
> site.war in tomcat, your context is /site. Right? A call for /home
> will and can never hit the site application. We can not perform magic
> with the HST2 :-)
> Now, what is this 'hst:showcontextpath' then. It holds the following:
> when you set it to false, all urls won't start with /site. So instead
> of /site/home, you'll get /home. And, as explained already, /home
> directly on tomcat, we cannot do any magic.
> So why then did we add this 'hst:showcontextpath'? It is meant, when,
> and this is quite a normal usecase, your application is behind some
> proxy, like httpd. We *want* to run apps with a context in tomcat to
> be able to have more apps in tomcat (not only ROOT.war), but, we do
> not want to show the contextpath in the url.
> Therefor, normally, httpd or something can be used, to add the
> contextpath! But if you would do so only in httpd, and we would do
> nothing in the HST2, then all links would contain a context, namely
> /site for example. But, httpd is handling this context. Therefor, if
> you configured httpd to include the contextpath, but the contextpath
> should not be in the url, you set:
> hst:showcontextpath = false.
> Your httpd could look something like:
>  <VirtualHost *:80>
>   ProxyPreserveHost On
>   ProxyPass / http://localhost:8080/site/
>   ProxyPassReverse / http://localhost:8080/site/
>   ProxyPassReverseCookiePath /site /
> </VirtualHost>
> This is quite nice actually: all requests on port 80, we forward to
> the application with ProxyPreserveHost On. This way, you have one
> single httpd rule, but can add runtime hosts and subsites in your
> hst:virtualhosts.
> Hope this all clarifies things a little. I think this is really one of
> the nice parts of HST2. For local development, for example on
> hst:virtualhosts you most likely use hst:showcontextpath =
> true, but for your production host www.mysite.com, which is behind
> httpd, you add hst:showcontextpath = false
> >
> > Virtual hosts and Jetspeed profilers are really good ideas.
> >
> > I will let you know in all cases.
> >
> >
> > On Mon Feb 08,2010 08:09 pm, Ard Schrijvers wrote:
> >> Your virtualhosts filter defines which 'subsites' there are, and then
> >> below /preview and /live, there all the possible sites are. I though
> >> think, the cms interface for the hst :configuration is still based on
> >> 'single' sites, and is not yet aware of multiple subsites. We still
> >> need to add this. Though, in the console (/cms/console by default) you
> >> can configure this in direct jcr nodes.
> >>
> >> Sry about the inconvenience, hope this helps you out. If you need more
> >> help, let me know (ps are you subscribed to the hst dev list? Over
> >> there I explained today how to configure multiple domains and
> >> subsites)
> >>
> >> Regards Ard
> >>
> >> On Mon, Feb 8, 2010 at 7:54 PM, Mansour Al Akeel
> >> <mansour.alakeel at gmail.com> wrote:
> >> > Hello All,
> >> > I am wondering about how to change the docBase in the CMS for the contents
> >> > to be served. For example in the URL designer, when setting the "Content
> >> > Path" it always points to the first project.
> >> > Where can I change this behaviour in the console to point to different "hst:content" ?
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Hippo-cms7-user mailing list and forums
> >> > http://www.onehippo.org/cms7/support/community.html
> >> >
> >> _______________________________________________
> >> Hippo-cms7-user mailing list and forums
> >> http://www.onehippo.org/cms7/support/community.html
> > _______________________________________________
> > Hippo-cms7-user mailing list and forums
> > http://www.onehippo.org/cms7/support/community.html
> >
> _______________________________________________
> Hippo-cms7-user mailing list and forums
> http://www.onehippo.org/cms7/support/community.html

More information about the Hippo-cms7-user mailing list