Return-Path: Delivered-To: apmail-forrest-dev-archive@www.apache.org Received: (qmail 62501 invoked from network); 2 Jun 2005 10:00:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Jun 2005 10:00:18 -0000 Received: (qmail 41288 invoked by uid 500); 2 Jun 2005 10:00:17 -0000 Delivered-To: apmail-forrest-dev-archive@forrest.apache.org Received: (qmail 41249 invoked by uid 500); 2 Jun 2005 10:00:16 -0000 Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@forrest.apache.org List-Id: Delivered-To: mailing list dev@forrest.apache.org Received: (qmail 41214 invoked by uid 99); 2 Jun 2005 10:00:16 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=NORMAL_HTTP_TO_IP X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from ns3.wkwyw.net (HELO ns3.wkwyw.net) (217.199.181.91) by apache.org (qpsmtpd/0.28) with SMTP; Thu, 02 Jun 2005 03:00:11 -0700 Received: (qmail 27042 invoked from network); 2 Jun 2005 09:53:15 -0000 Received: from 82-69-78-226.dsl.in-addr.zen.co.uk (HELO ?192.168.0.4?) (82.69.78.226) by ns3.wkwyw.net with SMTP; 2 Jun 2005 09:53:15 -0000 Message-ID: <429ED6FF.1000207@apache.org> Date: Thu, 02 Jun 2005 10:53:03 +0100 From: Ross Gardler User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@forrest.apache.org Subject: Re: Slide Integration References: <4998884405051804394ad8a1d7@mail.gmail.com> <428B340D.6060209@apache.org> <4998884405060111091035e419@mail.gmail.com> In-Reply-To: <4998884405060111091035e419@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Tim Williams wrote: > Sent to dev as suggested. > > On 5/18/05, Ross Gardler 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: 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