This section in the root sitemap (same mechanism in 2.1.n) is designed to handle dojo resources, allow you to register and serve your own namespaces and override built-in libraries :
<!--+
| Cocoon-provided client-side resources.
| Some block's jar files (e.g. Ajax & Forms) include client-
side resources
| such as JavaScript, CSS and images. The system-level
pattern below
| fetches these resources, while allowing them to be
overridden if needed
| in the webapp's "resources" directory.
|
| Defining this pattern in the root sitemap avoids
duplicating it in subsitemaps,
| which reduces copy/pasting in application code and allows
better client-side
| caching by giving each resource a single URL.
|
| Furthermore, some Cocoon code such as the Forms-provided
XSLs assume that
| resources are available at that URL.
|
| The absolute path for these resources is
"{request:contextPath}/_cocoon/resources"
+-->
<map:match pattern="_cocoon/resources/*/**">
<map:select type="resource-exists">
<map:when test="resources/{1}/{2}">
<map:read src="resources/{1}/{2}"/>
</map:when>
<!-- For Cocoon development, read directly from source
directories
<map:when test="../../src/blocks/{1}/resources/org/apache/
cocoon/{1}/resources/{2}">
<map:read src="../../src/blocks/{1}/resources/org/
apache/cocoon/{1}/resources/{2}"/>
</map:when>
-->
<map:otherwise>
<map:read src="resource://org/apache/cocoon/{1}/resources/
{2}"/>
</map:otherwise>
</map:select>
</map:match>
<!-- mount Cocoon system pipelines (you may apply similar
overides to those above) -->
<map:match pattern="_cocoon/system/*/**">
<map:select type="resource-exists">
<map:when test="system/{1}/sitemap.xmap">
<map:mount src="system/{1}/sitemap.xmap" uri-
prefix="_cocoon/system/"/>
</map:when>
<!-- For Cocoon development, read directly from source
directories
<map:when test="../../src/blocks/{1}/resources/org/apache/
cocoon/{1}/system/sitemap.xmap">
<map:mount src="../../src/blocks/{1}/resources/org/
apache/cocoon/{1}/system/sitemap.xmap" uri-prefix="_cocoon/system/
{1}/"/>
</map:when>
-->
<map:otherwise>
<map:mount src="resource://org/apache/cocoon/{1}/system/
sitemap.xmap" uri-prefix="_cocoon/system/{1}/"/>
</map:otherwise>
</map:select>
</map:match>
On 1 Feb 2007, at 23:04, Grzegorz Kossakowski wrote:
Hello, I'm still fighting with Dojo to get it working in refactored forms. My main problem is that I want to split stuff into separate parts but it seems that introduction of Dojo assumed that all js will be on similar urls and relative paths would just work fine. While that was true with old ("_cocoon/*") way of loading resources it's not in refactored environment. We have our own namespace for our widgets and manifest.js registeringit. Dojo does not know about it, but is clever enough to guess where isit and load where required. However, in new way of loading block resources of one block are completely separated from other block's resource. While it's desired and one of my main aims it breaks dojo guessing badly. Take a look:http://localhost:8888/blocks-test/cocoon-ajax-impl/resources/forms/ manifest.jshttp://localhost:8888/blocks-test/cocoon-ajax-impl/resources/forms.jshttp://localhost:8888/blocks-test/cocoon-ajax-impl/resources/dojo/ __package__.jsWhereby manifest.js is stored under:http://localhost:8888/blocks-test/cocoon-forms-impl/resources/forms/ manifest.jsQuick work-around was to tell dojo the path where manifest.js is stored:dojo.registerModulePath("forms","servlet:forms:/resources/forms"); <!-- tell dojohow to find manifest registering our forms namespace --> This fixes problem described above but I'm sure it's dirty hack and moreover another issues (path errors) arise really quickly.What's best way to solve this kind of problems? Am I good guessing thatassumption of relative paths has been made while introducing dojo? Could some of those who has done this work actually speak on issues described above? Jeremy? Bruno? -- Grzegorz Kossakowski
smime.p7s
Description: S/MIME cryptographic signature
