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
|