Return-Path: Delivered-To: apmail-forrest-dev-archive@www.apache.org Received: (qmail 74001 invoked from network); 10 Nov 2004 17:41:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 10 Nov 2004 17:41:53 -0000 Received: (qmail 94906 invoked by uid 500); 10 Nov 2004 17:41:52 -0000 Delivered-To: apmail-forrest-dev-archive@forrest.apache.org Received: (qmail 94847 invoked by uid 500); 10 Nov 2004 17:41:51 -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 Delivered-To: mailing list dev@forrest.apache.org Received: (qmail 94833 invoked by uid 99); 10 Nov 2004 17:41:51 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from [212.23.3.140] (HELO pythagoras.zen.co.uk) (212.23.3.140) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 10 Nov 2004 09:41:49 -0800 Received: from [82.69.78.226] (helo=[192.168.0.2]) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1CRwTY-0006We-T6 for dev@forrest.apache.org; Wed, 10 Nov 2004 17:41:45 +0000 Message-ID: <419252D1.4010103@apache.org> Date: Wed, 10 Nov 2004 17:41:37 +0000 From: Ross Gardler User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@forrest.apache.org Subject: Re: [RT] plugin infrastructure References: <4188E497.4080803@apache.org> <418BB394.3090909@apache.org> <418F92EC.2050205@apache.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-Pythagoras-IP: [82.69.78.226] X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Nicola Ken Barozzi wrote: > Ross Gardler wrote: > >> Nicola Ken Barozzi wrote: >> >>> Ross Gardler wrote: > > ... > >>> Problem: How do we define the "default" view, which is >>> MyClass.html? >> >> >> Here's a partial solution, but it doesn't quite work, maybe it will >> fire an idea: >> >> Each plugin that wants to do so defines a default behaviour: >> >> >> >> >> >> (yeah, I know the above rewrtie rule doesn't work, we need a "not >> **-*.html" in the first part, but I can't think about regexps this >> morning, not my strongpoint, and I'm sure you get the point) >> >> The user then has control over which one takes precedence because they >> can control the order in which sitemaps are processed through the >> project.required.plugins property (see below). >> >> Problem: the above will match all requests for an HTML document and >> redirect it, even ones that are not Java related. > > > I think I understand the suggestion. > > Probably the best thing is to do something like this (again like your > suggestion it's just metacode): > > > > Yes, that is what I was thinking. >>> 3 - extra data to be put on a page >>> >>> Since we have to aggregate, we need to specify a new section >>> for information nuggets. This is to make all skins able to render >>> them. >>> >>> The question is: how to add things to the nugget section? >>> Seems like the last point of this mail is getting more >>> important :-) >> >> >> This is more a problem of for skins than plugins. If we can solve the >> matching problem above, and the skins can give us a way to hook into >> them we have this solution. >> >> I think this last one is probably going a step too far at this stage. >> Maybe we should put it on the back-burner for now - the solution may >> turn out to be creating a portal plugin from the Cocoon Portal >> Framework. (now it's time for someone to stop me!) > > > Stop! :-) > > I thought about this today, and I think that we can start solving the > problem by making it possible for the aggregate to have multiple > metadata and nugget sections. > > Instead of: > > > > > > > > > > > > > > > We make this: > > > > > > > > > > > > that can be easily (if ever needed) be transformed back to the nested > format above, but is easy to create with multiple aggregates. > > Question: how do we make it possible for *multiple* plugins to add > content? Make every page the result of an xinclude of all plugin > responses to the page request... isn't this too heavy? See Thorstens recent RT: http://marc.theaimsgroup.com/?l=forrest-dev&m=109959086204887&w=2 Does it work here? > >>> ... >>> >>>>>> My Proposal >>>>>> =========== >>>>>> >>>>>> Each plugin should be able to provide three sitemaps rather than >>>>>> the current 1. I have another use case that doesn't fit into the existing 3 sitemap idea. The OpenOffice.org plugin has a technique for allowing images embedded in the OpenOffice document to be rendered in the page. The XSLT rewrites the img references in the sx* file so that they can be matched by the plugin sitemap here: Since the OpenOffice.org plugin is an input plugin this gets mounted in forrest.xmap within the **.xml match. However, an image is no a *.xml file. So the embedded images no longer work. We could hack a solution where the URL is rewritten to something ending in .xml - but this is not nice My proposal would be to allow an input plugin to provide an input.xmap and a resources.xmap. WDYT? >>>>>> - sitemap.xmap - this provides the infrastructure matchers (i.e. >>>>>> site.xml, faq.xml, issues.xml), as such it will be mounted before >>>>>> *any* of the Forrest matches. This sitemap can override any >>>>>> behaviour within Forrest) >>>>>> >>>>>> - source.xmap - this provides the source matchers (i.e. **.xml), >>>>>> it is mounted in forrest.xmap before the default forrest **.xml >>>>>> behaviour and therefore can override that default behaviour but it >>>>>> will not interfere with any internal Forrest infrastructure >>>>>> matches, or any other plugins infrastructure matches. >> >> >> This should be named input.xmap as Clay points out in a later mail in >> this thread. > > > +1 > >>>>>> >>>>>> - output.xmap - this provides (surprise!) the output matchers >>>>>> (i.e. **.html, **.pdf, **.slides), it is mounted before any of the >>>>>> default matchers for Forrest and so can override this default >>>>>> behaviour >>>>>> >>>>>> Ideally, each plugin should only provide one of these three >>>>>> sitemaps. I believe this will help us to define a sensible >>>>>> granularity for the plugins. However, further exploration of use >>>>>> cases may show otherwise and therefore we should make it legal >>>>>> (but not encouraged) to implement more than one of them. >>>>> >>>>> >>>>> I tend to like the concept, even if it may not result to be >>>>> technically >>>>> needed. Just thinking out loud. >> >> >> >> As Nicola says in a later mail in this thread: >> >> "When Dave has asked to rename the last plugin to show that it's an >> output plugin, alarm bells started ringing in my head. I had not >> pondered it enough, and the separation that was hinted became clearly >> needed. >> >> IOW, I now understand what probably has been plain obvious to all >> others :-) : we *must* have each plugin use only one of the following >> sitemaps." >> >> I agree. Nicola went on to say: >> >> This gives us the problem of libraries and components in each plugin, >> as more plugins can need the same jars or cocoon xconf extensions. >> >> The RTF plugin demonstrates the jars problem. The first incarnation of >> this plugin requires the user to copy the files into the >> forrest/webapp/WEB-INF/lib directory. Of course, this needs to be >> automated. >> >> I see two possible solutions: > > > Let me snip the first one, it's really too dangerous ;-) > > ... > >> - We could make the forrest scripts handle this configuration, as it >> handles the configuration of the plugin sitemap.xmap now. That is, >> each time we run forrest we configure cocoon.xconf accordingly. This >> will require cocoon.xconf to be renamed something like >> "cocoon.xconf.default", this is then processed by XSLT when Forrest is >> run to create cocoon.xconf for that run (cocoon.xconf would then be >> added to svn:ignore). With respect to the jar files we could build the >> classpath to include the relevant plugin/WEB-INF/lib and >> plugin/WEB-INF/class folders. > > > Yes, this is what I had in mind, but the problem is another one. > > If two plugins have the same jar, will the user download two jars? Yes :-( > What if these jars are of different versions? Assuming that projects maintain backward compatibility between releases we could use a version management system to control which jar is kept. To do this plugins would maintain a list of required libs, but would not actually contain the libs in their zip file. libs would then be downloaded by the plugin system to common plugins/lib, but only when necessary. (the problem arises again where there is no backward compatibility, but unless we have hundreds of plugins I think we can safely ignore this for now) This would stop us building the classpath on a per execution basis, but the performance hit shouldn't be that bad. So, is there a versioning system we could use? (krysalis-version?) > > ... > > Another point that has come to mind: locationmap. > > A locationmap is a file that specifies which source file Forrest will be > pointed to in response to the requested URL. > > For example, if I ask for index.html, I might get > > c:\path\src\1documentation\content\xdocs\index.xml > > All goes well until we include plugins. If a plugin is able to process > *.myformat files, it will never get a chance to process them, as the > locationmap will return to Forrest saying it has not found a suitable > source file. > > This means that we should stop using resource-exists, and instead get > metadata about the directory and ask for a list of all page.* files in > there, so that we always have a file to deal with. > > Not sure how to code it though, but I know that Cocoon has a > TraversableSource that we can use for this purpose. > I'm a little lost with that one. Since locationmap is your baby can I trust you'll solve the problem, or at least work on it (or me) till I understand ;-) Ross