forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [RT] plugin infrastructure
Date Wed, 10 Nov 2004 17:41:37 GMT


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:
>>
>> <map:match pattern="**.html">
>>   <map:redirect src="cocoon://{1}-javadocs.html"/>
>> </map:match>
>>
>> (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):
> 
>  <map:match pattern="**.html || **/*-javadocs.html">
>    <map:select if it can generate>
>      <generate the stuff>

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:
> 
> <skinconf/>
>  <metadata>
>    <item .../>
>    <item .../>
>  </metadata>
>  <tabs/>
>  <site/>
>  <nuggets>
>    <nugget/>
>    <nugget/>
>  </nuggets>
>  <content/>
> 
> We make this:
> 
>  <skinconf/>
>  <metadata-item .../>
>  <tabs/>
>  <metadata-item .../>
>  <nugget/>
>  <site/>
>  <nugget/>
>  <content/>
>  <nugget/>
> 
> 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:

       <map:match pattern="**/openOfficeEmbeddedImage/zip-**/file-**.*">
         <map:read src="jar:file://{project:content.xdocs}{2}!/{3}.{4}" 
mime-type="image/{4}" />
       </map:match>

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

Mime
View raw message