You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@forrest.apache.org by Tim Williams <wi...@gmail.com> on 2005/05/18 13:39:36 UTC
Slide Integration
Has anyone already documented how to use Slide as a backend to
Forrest? If not maybe some high-level pointers of where to start?
Thanks,
--tim
Re: Slide Integration
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> On 6/2/05, Ross Gardler <rg...@apache.org> wrote:
>
>>Tim Williams wrote:
>>
>>>Sent to dev as suggested.
>>>
>>>On 5/18/05, Ross Gardler <rg...@apache.org> 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
Re: Slide Integration
Posted by Tim Williams <wi...@gmail.com>.
On 6/2/05, Ross Gardler <rg...@apache.org> wrote:
> Tim Williams wrote:
> > Sent to dev as suggested.
> >
> > On 5/18/05, Ross Gardler <rg...@apache.org> 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.
> For more information see http://issues.cocoondev.org/browse/FOR-200
>
> 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. What does "generation stage" mean though, does what I'm talking
about fall into that particular stage?
> I prefer the locationmap method to the forrest.properties method because
> it means that we can integrate content from multiple repository
> locations and multiple repository types within the same site.
Right, clearly seems like a better approach. I get the effect I want
by essentially matching everything I suppose.
> > 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. I guess before I get there I need to have a closer look at Lenya
to see if a client-side authoring environment could somehow be used
with it. I also don't yet know if Slide can be used behind Lenya
either. They have a WebDav page but it's not very helpful to me --
may very well be ignorance on my part. Then it'd basically be letting
each component do what it does best:
Epic/Spy - Authoring
Lenya - Workflow/Site Management
Forrest - Publishing
Slide - Content Repository
I haven't see Daisy yet but I'll take a look at that too.
Thanks,
--tim
Re: Slide Integration
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Fri, 2005-06-03 at 08:43 +0200, Nicola Ken Barozzi wrote:
>
>>Ross Gardler wrote:
>>...
>>
>>>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).
>>
>>Why don't you make a branch to work on it?
>
>
> +1
OK, will do it today.
Ross
Re: Slide Integration
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2005-06-03 at 08:43 +0200, Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
> ...
> > 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).
>
> Why don't you make a branch to work on it?
+1
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Slide Integration
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
...
> 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).
Why don't you make a branch to work on it?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Slide Integration
Posted by Ross Gardler <rg...@apache.org>.
Tim Williams wrote:
> Sent to dev as suggested.
>
> On 5/18/05, Ross Gardler <rg...@apache.org> 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>
For more information see http://issues.cocoondev.org/browse/FOR-200
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 prefer the locationmap method to the forrest.properties method because
it means that we can integrate content from multiple repository
locations and multiple repository types within the same site.
> In this way, I could use Epic or Spy to author documents using the
> versioning (among other) features of Slide and publish them using
> Forrest.
Cool.
> 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.
> The long term part still has much to be figured out such as the
> impacts on navigation for document creations/deletions but I hope all
> ultimately workable. For now, if I could get some tips for where to
> start on the short term of pointing xdocs at a webdav location.
Again, with Lenya and Daisy integration they also provide navigation
editing. The Daisy plugin does not currently use the navigation from the
Daisy repository but it is a simple case to make that happen.
Ross
Re: Slide Integration
Posted by Tim Williams <wi...@gmail.com>.
Sent to dev as suggested.
On 5/18/05, Ross Gardler <rg...@apache.org> 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
In this way, I could use Epic or Spy to author documents using the
versioning (among other) features of Slide and publish them using
Forrest.
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.
The long term part still has much to be figured out such as the
impacts on navigation for document creations/deletions but I hope all
ultimately workable. For now, if I could get some tips for where to
start on the short term of pointing xdocs at a webdav location.
Thanks,
--tim
Re: Slide Integration
Posted by Ross Gardler <rg...@apache.org>.
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