Re: Locationmap and sitemap.selector.exists
Ross Gardler wrote: ... Another use case for what you suggest is the resources.xmap file. Imagine how much easier to follow it would be if we didn't have so may alternative locations for the image files. Nicola Ken hinted that this would be the case when I recently said I don't want to think that far forward yet. I wonder if this is what he meant? Yes. As Thorsten has seen, Having the information early can make the sitemaps much cleaner. But instead of exists, we should use another selector. Let me explain. Cocoon has the notion of Source, and there is also a TraversableSource. This means that I can go further than asking a source if a file exists, I can ask to give me all the files that have a given name except the extension. This would make it all much faster and cleaner. For example, if the TraversableSource is the file system, my action would ask all the filenames in a certain directory, and with a for loop get all the ones with the same name in the requested URI, sorting the extensions as I tell him to. In this way, the result of the processing is *one* *source* *file*! Imagine, from the very beginning we know what the source is without lengthy and tedious requests, and we can start processing by knowing what the source is from the beginning. Separation of Concerns: location resolving and processing fully separate, also inside Cocoon. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [VOTE] RC3 as final release candidate for apache-forrest-0.7
Ross Gardler wrote: Testing and voting finishes on Wednesday 2005-06-22 at 22:00 UTC http://www.timeanddate.com/worldclock/fixedtime.html?month=6day=20year=2005hour=22min=0sec=0p1=0 The proper URL is: http://www.timeanddate.com/worldclock/fixedtime.html?month=6day=22year=2005hour=22min=0sec=0p1=0 -David
Re: Locationmap and sitemap.selector.exists
On Tue, 2005-06-21 at 08:20 +0200, Nicola Ken Barozzi wrote:
Ross Gardler wrote:
...
Another use case for what you suggest is the resources.xmap file.
Imagine how much easier to follow it would be if we didn't have so may
alternative locations for the image files. Nicola Ken hinted that this
would be the case when I recently said I don't want to think that far
forward yet. I wonder if this is what he meant?
Yes. As Thorsten has seen, Having the information early can make the
sitemaps much cleaner.
But instead of exists, we should use another selector. Let me explain.
Cocoon has the notion of Source, and there is also a
TraversableSource. This means that I can go further than asking a
source if a file exists, I can ask to give me all the files that have a
given name except the extension. This would make it all much faster and
cleaner.
For example, if the TraversableSource is the file system, my action
would ask all the filenames in a certain directory, and with a for loop
get all the ones with the same name in the requested URI, sorting the
extensions as I tell him to. In this way, the result of the processing
is *one* *source* *file*!
That is why you always have been talking about:
about.xml
about.meta.xml
...
right?
The question that raises is whether that is working as well for
subdirectories. Let me explain:
I have a contract not only in {project:resources}/templates/ but in e.g.
{project:resources}/templates/xhtml/{1}.ft
{project:resources}/templates/fo/{1}.ft
Now would the TraversableSource respond me when looking for {1} the fo/
and the xhtml/ dir location or only in one dir (without subdir)?
What do you exactly mean with *one* *source* *file*?
Do you mean eg. index.xml and index.fv can be treated as *one* file
because their have only the extension different?
Imagine, from the very beginning we know what the source is without
lengthy and tedious requests, and we can start processing by knowing
what the source is from the beginning.
Separation of Concerns: location resolving and processing fully
separate, also inside Cocoon.
Requesting index.html would give me index.xml and index.fv through the
TraversableSource (in locationmap). This resolving would then be used
later on in the processing which will not care about resolving but
concentrate on processing. That makes the sitemap really clean and
readable. :)
¡¡¡wow!!!
Now I am starting to understand better what you wrote in old mails. ;-)
Good on ya, mate.
salu2
--
thorsten
Together we stand, divided we fall!
Hey you (Pink Floyd)
testing rc3
I tested rc3 on Mac OS X. Java 1.4.2_05 The usual things worked well and i also did the DocBook/XSL test and the Download DTD example. I have not yet tried the forrestbot. However i had some trouble with deploying a webapp under a full Jetty. The default seed site my-project.war was okay, but the war from site-author was broken with a Cocoon error ... request-uri: /forrest/index.html cause: /private/tmp/Jetty__36366__forrest/webapp/project/skinconf.xml (No such file or directory) I wonder if some configuration is not being handled, because our skinconf.xml is at a non-standard location. Another issue: The core DTDs are fine, but additional DTDs are not being handled via a webapp, e.g. the Download DTD example or DTDs from plugins. -David
[jira] Commented: (FOR-548) project DTD catalogs are not included when running as a servlet WAR
[ http://issues.apache.org/jira/browse/FOR-548?page=comments#action_12314189 ] David Crossley commented on FOR-548: One workaround is to add an additional path to the project CatalogManager.properties Change the default from this ... catalogs=../resources/schema/catalog.xcat to this ... catalogs=../resources/schema/catalog.xcat;../../project/src/documentation/resources/schema/catalog.xcat project DTD catalogs are not included when running as a servlet WAR --- Key: FOR-548 URL: http://issues.apache.org/jira/browse/FOR-548 Project: Forrest Type: Bug Components: Launch servlet WAR Versions: 0.7-dev Reporter: David Crossley When using a WAR file under a full Jetty, the project catalog.xcat is not being included. The webapp has different paths (webapp/project/*) for the project resources. The src/documentation/classes/CatalogManager.properties file defines the relative path to the project catalog.xcat, which is then broken in a war. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FOR-548) project DTD catalogs are not included when running as a servlet WAR
project DTD catalogs are not included when running as a servlet WAR --- Key: FOR-548 URL: http://issues.apache.org/jira/browse/FOR-548 Project: Forrest Type: Bug Components: Launch servlet WAR Versions: 0.7-dev Reporter: David Crossley When using a WAR file under a full Jetty, the project catalog.xcat is not being included. The webapp has different paths (webapp/project/*) for the project resources. The src/documentation/classes/CatalogManager.properties file defines the relative path to the project catalog.xcat, which is then broken in a war. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FOR-547) Plugins are not installed when calling forrest via Ant (forrest.build.xml:site)
[
http://issues.apache.org/jira/browse/FOR-547?page=comments#action_12314194 ]
David Crossley commented on FOR-547:
That link is broken, so here ...
http://marc.theaimsgroup.com/?t=11189653824
Plugins are not installed when calling forrest via Ant
(forrest.build.xml:site)
---
Key: FOR-547
URL: http://issues.apache.org/jira/browse/FOR-547
Project: Forrest
Type: Bug
Components: Core operations
Versions: 0.7-dev
Environment: Windows XP, SP2
Ant 1.6.5
Forrest 0.7rc1
Reporter: Ron Blaschke
Priority: Minor
I have an Ant script, which imports forrest.build.xml. When calling the site
target with a missing plugin, the install fails. But forrest init-plugins
works fine. Also, using versioned plugins works, using the Ant script and
forrest init-plugins..
Here's the relevant conversation from forrest-dev.
Ron Blaschke wrote:
Friday, June 17, 2005, 11:54:47 AM, Ross Gardler wrote:
Ron Blaschke wrote:
Unable to retrieve the ${plugin.name} plugin.
Two noteworthy things: Calling forrest init-plugins installs the
plugin sucessfully. And the error message says ${plugin.name},
instead of the real name of the plugin.
The two things are related. It looks like that the {plugin.name} is not
being set for some reason (and I guess {versioned.name} is not set either.
These are set in the init-plugins target of targets/plugins.xml
I ran my build.xml with ant -d, and found the following:
Setting ro project property: plugin.name - ${plugin.name}
Setting ro project property: plugin.version - ${plugin.version}
Setting ro project property: versioned.name -
org.apache.forrest.plugin.input.projectInfo
Actually that is as expected. The {plugin.name} and {plugin.version}
values are set by a regexp looking for the the version number. Since
there is no version number in the plugin required the regexp fails and
so no value for the property. The rest of the script tries to get the
{versioned.name} plugin. If it fails it falls back to the unversioned
plugin.
This explains why the error message shows ${plugin.name}, I've changed
that to use the {versioned.name} so at least it will give a more
meaningful error.
forrest -d says:
Setting ro project property: plugin.name -
org.apache.forrest.plugin.input.projectInfo
Setting ro project property: plugin.version -
Setting ro project property: versioned.name -
org.apache.forrest.plugin.input.projectInfo
This I don't understand. The bechaviour should be the same as above. The
relevant portion of the ANT script is at line 337 of targets/plugins.xml
My forrest.properties says this:
project.required.plugins=org.apache.forrest.plugin.input.projectInfo,
org.apache.forrest.plugin.input.simplifiedDocbook
I assume you get the same behaviour with simplifiedDocbook?
Out of curiosity, I added the plugin version.
project.required.plugins=org.apache.forrest.plugin.input.projectInfo-0.1,
org.apache.forrest.plugin.input.simplifiedDocbook
The debug trace of my build.xml changes to the following, and the
plugin is successfully installed.
Setting ro project property: plugin.name -
org.apache.forrest.plugin.input.projectInfo
Setting ro project property: plugin.version - 0.1
Setting ro project property: versioned.name -
org.apache.forrest.plugin.input.projectInfo-0.1
This looks like the behaviour expected.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (FOR-549) plugin DTD catalogs are not included when running as a servlet WAR
plugin DTD catalogs are not included when running as a servlet WAR -- Key: FOR-549 URL: http://issues.apache.org/jira/browse/FOR-549 Project: Forrest Type: Bug Components: Launch servlet WAR Versions: 0.7-dev Reporter: David Crossley When using a WAR file under a full Jetty, the plugins catalog.xcat files are not being included. In the webapp, the path to build/plugins/ is different. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FOR-549) plugin DTD catalogs are not included when running as a servlet WAR
[ http://issues.apache.org/jira/browse/FOR-549?page=comments#action_12314198 ] David Crossley commented on FOR-549: The solution is to add an additional path to main/webapp/resources/schema/catalog.xcat like this ... nextCatalog catalog=../../build/plugins/catalog.xcat/ plugin DTD catalogs are not included when running as a servlet WAR -- Key: FOR-549 URL: http://issues.apache.org/jira/browse/FOR-549 Project: Forrest Type: Bug Components: Launch servlet WAR Versions: 0.7-dev Reporter: David Crossley When using a WAR file under a full Jetty, the plugins catalog.xcat files are not being included. In the webapp, the path to build/plugins/ is different. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
