cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@apache.org>
Subject Re: Dojo paths problem
Date Tue, 06 Feb 2007 12:35:58 GMT
I think part of the problem is that I was unable to get the proper  
sitemap glue working for Cocoon 2.2 as I was unable to run the samples.

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 registering
> it. Dojo does not know about it, but is clever enough to guess  
> where is
> it 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.js
> http://localhost:8888/blocks-test/cocoon-ajax-impl/resources/forms.js
> http://localhost:8888/blocks-test/cocoon-ajax-impl/resources/dojo/ 
> __package__.js
>
> Whereby manifest.js is stored under:
> http://localhost:8888/blocks-test/cocoon-forms-impl/resources/forms/ 
> manifest.js
>
> Quick work-around was to tell dojo the path where manifest.js is  
> stored:
> dojo.registerModulePath("forms",
> "servlet:forms:/resources/forms");                        <!-- tell  
> dojo
> how 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  
> that
> assumption 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


Mime
View raw message