forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [RT] plugin infrastructure
Date Tue, 09 Nov 2004 23:07:37 GMT
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>


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

>> ...
>>
>>>>> My Proposal
>>>>> ===========
>>>>>
>>>>> Each plugin should be able to provide three sitemaps rather than 
>>>>> the current 1.
>>>>> - 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?
What if these jars are of different versions?

...

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.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message