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. > 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
