Tim Williams wrote:
On 6/2/05, Ross Gardler <[EMAIL PROTECTED]> wrote:
Tim Williams wrote:
Sent to dev as suggested.
On 5/18/05, Ross Gardler <[EMAIL PROTECTED]> wrote:
Tim Williams wrote:
Has anyone already documented how to use Slide as a backend to
Forrest? If not maybe some high-level pointers of where to start?
Nobody has documented this, or to my knowledge tried it.
You'd probably find more help on the dev list, where we will be glad to
help you. Please send your question there with a description of a use
case describing exactly how you would like the integration to work (may
seem like an obvious thing, but it gives us a common language to
communicate ides with).
Ross
I guess I could give long and short term goals/use-cases.
In the short term,
I'd like to simply be able to point "project.xdocs-dir" in
forrest.properties to a slide repository like:
project.xdocs-dir=http://127.0.0.1:8080/slide/xdocs
OK, I'm experimenting with this kind of integration right now. Not with
Slide but with Daisy. Take a look at the Daisy plugin in whiteboard.
Currently, the location of the repository is encoded in request
parameters. This is *not* good.
The problem with this approach is that a) it is difficult to write the
hrefs b) it is impossible to build a static site because the request
parameter '?' is converted to an '_' in the filename ('?' is not legal
in a filename)
The solution to this problem is the locationmap work. This allows you to
map request patterns to a location. For example:
<match pattern="docs/**">
<location href="http://127.0.0.1:8080/slide/xdocs/{1}"/>
</match>
So does input.xmap go from being a sitemap to a locationmap or does it
just add a few elements to the sitemap doctype? I guess I'm still not
understanding where the locationmap matchers actually go in terms of
the plugin.
The locationmap is not a sitemap in the same sense as a cocoon sitemap.
It uses the same syntax because it reuses much of the code.
For more information see http://issues.cocoondev.org/browse/FOR-200
From that URL you will find a link to the original discussion about
locationmaps that includes a description of the original commit and an
example of how to use it - see
http://marc.theaimsgroup.com/?t=106638785400004
Things have not progressed any from that original contribution except...
I'm currently experimenting with the locationmap code, I have it working
"to an extent". But have not yet managed to get it to work at the
generation stage (through lack of time rather than a problem with the
code, I think). I will attach a patch against the current SVN tree to
the above issue that will enable the location map if you would like to
experiment with it. It would be great to have someone working with me on
this, you with Slide, me with Daisy (and Thorsten is looking at Lenya
integration).
I'd like to see the location map patch. That sounds like the way to
go.
I should find the time tomorrow to put the patch together with a simplyu
little demo.
What does "generation stage" mean though, does what I'm talking
about fall into that particular stage?
I'll try and explain what I mean:
The original description of functionality (at
http://marc.theaimsgroup.com/?t=106638785400004 ) only described link
translation. Meaning that a page with an lm: psuedo protocol href was
converted by the locationmap input-module to be a link to a specified
location. This is similar to the site: or ext: psuedo protocols in
Forrest. This works fine in the transformation stage. In other words, if
you have content with:
<a href="lm:myslidedocs/file.html">...</a>
and a locationmap of:
<match pattern="myslidedocs/**">
<locator src="http://127.0.0.1:8080/slide/xdocs/{1}"/>
</match>
the resulting content will be translated to:
<a href="http://127.0.0.1:8080/slide/xdocs/file.html"/>
This isn't quite what I want (and I think what you want). The problem is
that the link is translated in the source, so the URL the client sees is
the trnalsated URL. This prevents Forrest from processing the request as
the client requests directly from the repository source.
I'd prefer to have:
<a href="myslidesdocs/file.html">...</a>
and a locationmap with:
<match patern="myslidedocs/**.xml">..</a>
<locator src="http://127.0.0.1:8080/slide/xdocs/{1}.xml"/>
</match>
(NOTE the .xml extension as opposed to .html)
In this case Forrest will request "myslidesdoc/file.html", this will
result in an internal request for "myslidesdoc/file.xml" through
existing Forrest processing. The locationmap then maps this request to
"http://127.0.0.1:8080/slide/xdocs/file.xml"; which then gets processed
by forrest and returned to the client as "myslidesdocs/file.html".
In other words, the href "myslidesdocs/file.html" remains that same URL
in the client but actually is generated internally to Forrest from
"http://127.0.0.1:8080/slide/xdocs/{1}.xml";
In the long term,
I'd like to do the same as above, but have some sort of workflow state
metadata understood by both the authoring environment (Epic/Spy) and
publishing engine (Forrest). I'm thinking some fairly simple states
like: New, Author, Edit, Publish and then Forrest would be able to
inspect that metadata and only publish those documents with the
"Publish" state.
With the Daisy integration (and I assume Lenya) this will be possible.
Those systems provide full workflow control. I would be concerned about
duplicating their effort here in Forrest. What would be good though is
for us all to agree on a standard repository plugin that could be
configured to work with various different repository tools.
No, I wasn't suggesting that part (workflow) actually be a part of
Forrest, I just described that to give an idea of where I'd like to
be.
OK, in that case we have the same vision.
Epic/Spy - Authoring
Lenya - Workflow/Site Management
I'm not sure if it is possible to separate the workflow/site management
functionality from Lenya in this way.
Thorsten is a Lenya committer as well as aForrest committer. He will be
able to discuss the Lenya aspects with you. I decided not to use Lenya
because I could find no simple way of separating the repository from the
editing system.
Forrest - Publishing
Slide - Content Repository
I haven't see Daisy yet but I'll take a look at that too.
The big advantage of Daisy is its clear separation of editing from
repository. The disadvantage is that it is not as mature as some other
editrs/workflow systems. Recently they have started to put effort into
expanding the develope community. I hope this will help make the
framework develop, in my opinion it is an excellent framework.
Whatever path we take individually (Lenya, Daisy and Slide integration)
we should endeavour to make a single plugin for Forrest that can work
with each of the various repositories. I'm not sure how realistic this
is, but lets see what we can do. The locationmap, I think, will be the
connecting point.
Ross
