forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <william...@gmail.com>
Subject Re: Slide Integration
Date Thu, 02 Jun 2005 19:30:38 GMT
On 6/2/05, Ross Gardler <rgardler@apache.org> wrote:
> Tim Williams wrote:
> > Sent to dev as suggested.
> >
> > On 5/18/05, Ross Gardler <rgardler@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

Mime
View raw message