You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by llamar burgess <ll...@kraftfeld.org> on 2007/08/19 16:33:50 UTC
multiple projects in single forrest instance
lo devs,
for a actual project i could really use a feature to serve multiple
'projects' in a single forrest instance.
These projects should have theire own sitemap, skinconf, tabs and site
while sharing the cocoon libs and jars.
Currently i am using Forrest 0.8 as a webapp in tomcat to serve dynamic
content.
This discussion moved over from the user list.
Any suggestion is welcome :)
best regards
llamar
Re: multiple projects in single forrest instance
Posted by David Crossley <cr...@apache.org>.
llamar burgess wrote:
> Ross Gardler wrote:
> >
> >Do you know what all that means? If not, start here at these docs [3]
> >if you do then work it through as far as you can and ask here for more
> >help.
>
> One thing i am not quite clear about is the line
> <map:transform type="xinclude"/>
> there are no xincludes in the site.xml.. is this just a precaution?
Some people might use xincludes in their site.xml files,
so this transformation handles that possibility.
-David
Re: multiple projects in single forrest instance
Posted by Ross Gardler <rg...@apache.org>.
llamar burgess wrote:
> Ross Gardler schrieb:
>>
>> For example, issue FOR-1044 [2] ("Navigation conversion is
>> incomplete") is a pretty important one. To start understanding what
>> the problem is here we need to understand the process by which
>> site.xml gets turned into the HTML.
>>
>> Searching in sitemap.xmap shows us this:
>>
>> <!-- The navigation and links file "site.xml" -->
>> <map:pipeline internal-only="true">
>> <map:match pattern="site.navigation.links.xml">
>> <map:select type="exists">
>> <map:when test="{lm:project.xml.site}">
>> <map:generate src="{lm:project.xml.site}"/>
>> </map:when>
>> <map:when test="{lm:site.xml}">
>> <map:generate src="{lm:site.xml}"/>
>> </map:when>
>> </map:select>
>> <map:transform type="xinclude"/>
>> <!-- FIXME: This is a workaround to Issue FOR-675 and
>> commons-jxpath-1.2 -->
>> <map:transform src="{lm:transform.xml.xml-namespace-stripped}"/>
>> <!-- end FIXME: FOR-675 -->
>> <map:serialize type="xml"/>
>> </map:match>
>> </map:pipeline>
>
> re,
>
> i guess the problem here is to determine if the site.xml of the master
> or a subsite (and if - then which) should be used. The snippet above
> will always return the site.xml of the master project.
Well, the above is the default match for the site.xml in the root
project for the current instance of Forrest. In the case of multiple
sites this will always be the master site.xml.
If you take a look at http://localhost:8888/index.html#Navigation (in
the whiteboard/multipleSites/master you will see:
--- start quoted text ---
Navigation is controlled by the main Forrest project. There are two
aspects to navigation site.xml and tab.xml.
site.xml
To include a site.xml file from a contained content object simply add
something like the following to your master site.xml:
<subsite1 label="First Subsite" tab="home" href="seed/">
<xi:include href="cocoon://seed/site.xml"/>
</subsite1>
<xi:include href="cocoon://seed/site.xml"/>
--- end quoted text ---
> One thing i am not quite clear about is the line
> <map:transform type="xinclude"/>
> there are no xincludes in the site.xml.. is this just a precaution?
As David said elsewhere, it is so that projects can use xinclude in
their site.xml files. As you can see in the above quoted text that is
exactly what we are doing in the master site.xml file. The result is
that the subsite site.xml files are imported into the master site.xml.
I hope that helps you understand the processing. Of course I appreciate
you are only just beginning to climb up the learning curve of how
Forrest works. You will find that once you understand how the basic
processed work, like this one, figuring out the rest is pretty easy.
Ross
Re: multiple projects in single forrest instance
Posted by llamar burgess <ll...@kraftfeld.org>.
Ross Gardler schrieb:
>
> For example, issue FOR-1044 [2] ("Navigation conversion is
> incomplete") is a pretty important one. To start understanding what
> the problem is here we need to understand the process by which
> site.xml gets turned into the HTML.
>
> Searching in sitemap.xmap shows us this:
>
> <!-- The navigation and links file "site.xml" -->
> <map:pipeline internal-only="true">
> <map:match pattern="site.navigation.links.xml">
> <map:select type="exists">
> <map:when test="{lm:project.xml.site}">
> <map:generate src="{lm:project.xml.site}"/>
> </map:when>
> <map:when test="{lm:site.xml}">
> <map:generate src="{lm:site.xml}"/>
> </map:when>
> </map:select>
> <map:transform type="xinclude"/>
> <!-- FIXME: This is a workaround to Issue FOR-675 and
> commons-jxpath-1.2 -->
> <map:transform src="{lm:transform.xml.xml-namespace-stripped}"/>
> <!-- end FIXME: FOR-675 -->
> <map:serialize type="xml"/>
> </map:match>
> </map:pipeline>
re,
i guess the problem here is to determine if the site.xml of the master
or a subsite (and if - then which) should be used. The snippet above
will always return the site.xml of the master project.
Maybe it is possible to get the requestAttribute selector to check it...
by the referer for example.
Am i on the right way?
>
> Do you know what all that means? If not, start here at these docs [3]
> if you do then work it through as far as you can and ask here for more
> help.
One thing i am not quite clear about is the line
<map:transform type="xinclude"/>
there are no xincludes in the site.xml.. is this just a precaution?
best regards
llamar
Re: multiple projects in single forrest instance
Posted by Ross Gardler <rg...@apache.org>.
llamar burgess wrote:
> The whiteboard master/subsite project works and gets content from the
> subsites into the master project.
> This also works for my testproject, when the locator in the masters
> locationmap and the property in forrest.properties.xml are set.
>
> The major things i guess, are theme, navigation, sitemap and locationmap
> for the subsites.
> It would be nice if there was kind of a 'taskmap', because i have no
> idea how these things can be integrated.
> It would be easier for me if i knew which tasks require which changes
> (and how complex they might get).
I don't really have the time to site down and think this through from
beginning to end, I'd rather just hack away at a solution to the most
urgent need and then refactor to make it into something truly usable.
To that end we should keep notes in the index.xml document and, where
appropriate, create issues in the issue tracker. I've created a master
issue at [1] and some sub tasks off of that.
It is highly likely that the number of issues will grow faster than I
can fix them right now. If you really want to pursue this and nail down
the tweaks you'll need to both add issues to the tracker and help close
some of them. Of course, you'll need help finding out how things work
and look at how to fix them. If you want to tackle any specific issue
just ask for pointers on this list, we'll do our best to guide you in
the right direction.
For example, issue FOR-1044 [2] ("Navigation conversion is incomplete")
is a pretty important one. To start understanding what the problem is
here we need to understand the process by which site.xml gets turned
into the HTML.
Searching in sitemap.xmap shows us this:
<!-- The navigation and links file "site.xml" -->
<map:pipeline internal-only="true">
<map:match pattern="site.navigation.links.xml">
<map:select type="exists">
<map:when test="{lm:project.xml.site}">
<map:generate src="{lm:project.xml.site}"/>
</map:when>
<map:when test="{lm:site.xml}">
<map:generate src="{lm:site.xml}"/>
</map:when>
</map:select>
<map:transform type="xinclude"/>
<!-- FIXME: This is a workaround to Issue FOR-675 and commons-jxpath-1.2 -->
<map:transform src="{lm:transform.xml.xml-namespace-stripped}"/>
<!-- end FIXME: FOR-675 -->
<map:serialize type="xml"/>
</map:match>
</map:pipeline>
Do you know what all that means? If not, start here at these docs [3] if
you do then work it through as far as you can and ask here for more help.
> By the way: sorry for the late reply, im off for a couple of days and
> will be back next monday.
Heh, no rush. We're all volunteers here, we're just glad you are helping
with testing this out for us when you can.
Ross
[1] https://issues.apache.org/jira/browse/FOR-1040
[2] https://issues.apache.org/jira/browse/FOR-1044
[3] http://forrest.apache.org/docs_0_80/sitemap-ref.html
Re: multiple projects in single forrest instance
Posted by llamar burgess <ll...@kraftfeld.org>.
Ross Gardler schrieb:
>
> I've built a simple test site that does the first stage of this. If
> you could follow along with your test site then we can be sure it
> works. As your understanding of the way Forrest works you'll be able
> to add functionality to the test site.
>
> In the meantime, please ask questions, add requirements to the list at
> the start of the index doc (see below) and do whatever else you think
> may help us move this forwards.
>
> STATUS
> ======
>
> All I've done so far is create a proof of concept, it is a very long
> way from complete. Do the following:
>
> cd FORREST_HOME
> svn up
> cd whiteboard/multipleSites/master
>
> Edit forrest.properties.xml by changing the value of the property
> below to reflect your filesystem:
>
> <!-- FIXME: we can't allow absolute locations like this -->
> <property name="subsite.xdocs.seed"
> value="C:\projects\forrest\whiteboard\multipleSites\subsite-seed\src\documentation\content\xdocs"/>
>
>
> Now do:
>
> forrest run
> http://localhost:8888
>
> The resulting page tells you a bit about what I have done in this
> "multipleSites" experiment in whiteboard. If you want quick motivation
> then request:
>
> http://localhost:8888/seed/index.html
>
> What you are now looking at is the index page from
> multipleSites/subsite-seed - but not you ran forrest in the
> multipleSites/master
>
> Now go back and read http://localhost:8888 properly, test it out on
> your test site and supply a patch including any
> clarifications/additions to the content of the instructions.
>
> Also add any requirements you would like to that page.
>
> Then tell me it works/does not work and identify what we need to work
> on next - there are lots of holes in this at present but since you
> have the real world use case I'd rather you pointed at which hole to
> fill first.
>
> Ross
>
>
The whiteboard master/subsite project works and gets content from the
subsites into the master project.
This also works for my testproject, when the locator in the masters
locationmap and the property in forrest.properties.xml are set.
The major things i guess, are theme, navigation, sitemap and locationmap
for the subsites.
It would be nice if there was kind of a 'taskmap', because i have no
idea how these things can be integrated.
It would be easier for me if i knew which tasks require which changes
(and how complex they might get).
That said, i dont know the internals of forrest enough to estimate what
makes sense to start out with.
If i had to choose i would go for theme or navigation first (because i
need that most :) ).
What do you think?
By the way: sorry for the late reply, im off for a couple of days and
will be back next monday.
so long
best regards
llamar
Re: multiple projects in single forrest instance
Posted by Ross Gardler <rg...@apache.org>.
llamar burgess wrote:
> Ross Gardler schrieb:
>> One question whilst you are working on this - how is your site
>> URLspace going to be structured? Will it be:
>>
>> http://foo.org/Site A/index.html
>> http://foo.org/Site B/index.html
>> http://foo.org/Site B/index.html
..
> Thats exactly how i wanted it to be.
> Whats next? :]
I've built a simple test site that does the first stage of this. If you
could follow along with your test site then we can be sure it works. As
your understanding of the way Forrest works you'll be able to add
functionality to the test site.
In the meantime, please ask questions, add requirements to the list at
the start of the index doc (see below) and do whatever else you think
may help us move this forwards.
STATUS
======
All I've done so far is create a proof of concept, it is a very long way
from complete. Do the following:
cd FORREST_HOME
svn up
cd whiteboard/multipleSites/master
Edit forrest.properties.xml by changing the value of the property below
to reflect your filesystem:
<!-- FIXME: we can't allow absolute locations like this -->
<property name="subsite.xdocs.seed"
value="C:\projects\forrest\whiteboard\multipleSites\subsite-seed\src\documentation\content\xdocs"/>
Now do:
forrest run
http://localhost:8888
The resulting page tells you a bit about what I have done in this
"multipleSites" experiment in whiteboard. If you want quick motivation
then request:
http://localhost:8888/seed/index.html
What you are now looking at is the index page from
multipleSites/subsite-seed - but not you ran forrest in the
multipleSites/master
Now go back and read http://localhost:8888 properly, test it out on your
test site and supply a patch including any clarifications/additions to
the content of the instructions.
Also add any requirements you would like to that page.
Then tell me it works/does not work and identify what we need to work on
next - there are lots of holes in this at present but since you have the
real world use case I'd rather you pointed at which hole to fill first.
Ross
Re: multiple projects in single forrest instance
Posted by llamar burgess <ll...@kraftfeld.org>.
Ross Gardler schrieb:
>
> I can certainly spare enough cycles to help guide you through the
> experimentation though. Hopefully, together, we can make it work.
I sure hope so, too :)
Thanks for your help, again.
>
> First thin first is to switch your site over to using the dispatcher.
> This is whiteboard code in the 0.8 release. It is pretty stable but we
> cannot guarantee that its usage will not change during the course of
> 0.9 development.
>
>
> The dispatcher replaces the skinning system. It is far more flexible,
> but has a steeper learning curve than skins as a result.
>
> I would recommend that the first thing you do is create an
> experimentation project for this. Keep your published sites in 0.8
> with multiple Cocoon instances (as discussed on the user list). Once
> we have it working you can decide what to do with respect to using
> whiteboard code in production (a few of the devs do use it, so it is
> reasonably dependable).
>
> You might also want to consider working with the SVN version of
> Forrest too. The downside is that you need to track things here, but
> since you are here...
>
> To create your experimentation project (in 0.8-dev or 0.8) copy the
> project you want to use as the "base site" and see
> http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/how/howto-dispatcher-quickstart.html
>
Got it up and running. My working project is built with the SVN trunk
version of Forrest and ready for action.
This is the first time i am dealing with the dispatcher (just to mention
it..). It looks awesome to me!
If it is capeable of what i think it is... then it will provide
functionality i always wanted to have in Forrest.
>
> One question whilst you are working on this - how is your site
> URLspace going to be structured? Will it be:
>
> http://foo.org/Site A/index.html
> http://foo.org/Site B/index.html
> http://foo.org/Site B/index.html
>
> Or some other set up?
Nope. Thats exactly how i wanted it to be.
Whats next? :]
best regards
llamar
Re: multiple projects in single forrest instance
Posted by Ross Gardler <rg...@apache.org>.
llamar burgess wrote:
> for a actual project i could really use a feature to serve multiple
> 'projects' in a single forrest instance.
> These projects should have theire own sitemap, skinconf, tabs and site
> while sharing the cocoon libs and jars.
Cool. This is something we've wanted to handle for some time. In fact it
is something that I, personally, would like to see happen soon. I have
an emerging need for this, but it is not urgent enough for me to put
significant resources into it right now.
I can certainly spare enough cycles to help guide you through the
experimentation though. Hopefully, together, we can make it work.
> Currently i am using Forrest 0.8 as a webapp in tomcat to serve dynamic
> content.
> This discussion moved over from the user list.
>
> Any suggestion is welcome :)
First thin first is to switch your site over to using the dispatcher.
This is whiteboard code in the 0.8 release. It is pretty stable but we
cannot guarantee that its usage will not change during the course of 0.9
development.
The dispatcher replaces the skinning system. It is far more flexible,
but has a steeper learning curve than skins as a result.
I would recommend that the first thing you do is create an
experimentation project for this. Keep your published sites in 0.8 with
multiple Cocoon instances (as discussed on the user list). Once we have
it working you can decide what to do with respect to using whiteboard
code in production (a few of the devs do use it, so it is reasonably
dependable).
You might also want to consider working with the SVN version of Forrest
too. The downside is that you need to track things here, but since you
are here...
To create your experimentation project (in 0.8-dev or 0.8) copy the
project you want to use as the "base site" and see
http://forrest.apache.org/pluginDocs/plugins_0_80/org.apache.forrest.plugin.internal.dispatcher/how/howto-dispatcher-quickstart.html
One question whilst you are working on this - how is your site URLspace
going to be structured? Will it be:
http://foo.org/Site A/index.html
http://foo.org/Site B/index.html
http://foo.org/Site B/index.html
Or some other set up?
Ross