cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Dojo paths problem
Date Wed, 07 Feb 2007 12:12:33 GMT
Jeremy Quinn napisał(a):
> On 6 Feb 2007, at 13:06, Grzegorz Kossakowski wrote:
>> Jeremy Quinn napisał(a):
>> The point is, while using servlet-service-fw there is *no* root sitemap
>> handling all request. Request are handled by dispatcher servlet,
>> instead.
> This is all news to me as I am not in a position ATM to even run 2.2
It's really easy. I would even hazard a guess that it's easier to play 
with Cocoon in 2.2 version...
>> Given that, resources of forms should be absolutely separated
>> from ajax's ones.
> They are separated ATM.
> However the Forms block depends on the Ajax Block in terms of 
> client-side resources.
> There are two types of resource path :
> Actual files (js, gif, css etc) that are served by a reader :
>     _cocoon/resources/[namespace]/[file path]
> And system resources that run a sitemap, accessing flowscript etc. :
>     _cocoon/system/[namespace]/[url path]
I wasn't really clear here. I meant that resources of two blocks are 
*completely* separated in terms of paths they are available from. I'll 
give you an example, in 2.2 it's completely valid to have following root 
path (mount paths) for forms and ajax blocks:
Then path to dojo resources become:**
But forms extension to dojo (forms namespace) is avaiable on:** (or sth 
like this)
As you see, dojo's "haunting" mechanism will fail as long as we don't 
provide it base-paths for *each block*. In terms of one block, all 
resources path will follow conventions so Dojo will find all js files 
without any problems.
>> We should not assume there is some root context path
>> and we can calculate all relative paths against it.
> Dojo makes that assumption for you.
> All paths in Dojo and 3rd party namespaces are relative to the 
> location of dojo.js
That will not work in 2.2. As explained above, paths cannot be 
calculated as relative to dojo.js for resources from other blocks.
> This is going to be pretty complicated to work around, I suggest that 
> you do not try as it will break at least 2.1.
If I'm not doing something entirely stupid it wasn't that hard. We just 
have to call dojo.registerModulePath several times (each one for each 
block). For example, manifest.js from Forms block will become:

dojo.registerModulePath("cocoon.ajax", "servlet:ajax:/resources/ajax/js"); // cocoon.forms
has a dependency on the cocoon.ajax module libraries
dojo.registerModulePath("cocoon.forms", "servlet:forms/resources/forms/js");

Instead of:
dojo.registerModulePath("cocoon.ajax", "../ajax/js"); // cocoon.forms has a dependency on
the cocoon.ajax module libraries
dojo.registerModulePath("cocoon.forms", "../forms/js");

I personally don't think it's complicated change, of course if it's valid from design point
of view.

> 2.2 and 2.1 may serve dojo.js from different paths, but all other 
> resources must be /relative/ to those paths.
No way to do it in 2.2.... (of course we all the time speaking about 
situation when servlet-service-fw is used)
> As you probably know, the client-side code for Forms and Ajax are 
> shared between 2.1 and 2.2. Messing about with how Dojo generates 
> paths for 2.2 will definitely break the client-side code for 2.1.
Yes, I'm aware of this problem. That was also a reason that I started to 
ask to stop sharing forms/ajax between 2.1 and 2.2. It will happen 
sooner, or later. My biased opinion is that it should happen sooner than 
> If you run FireBug while browsing the samples, you can easily see what 
> paths are being requested.
> If Dojo cannot find a resource the first time, it will start 'hunting' 
> for it using some basic rules (documented at their site). We ALWAYS 
> want to supply a resource at the first location Dojo will look.
Yes, I saw this a little confusing feature and I agree we should supply 
resource at first location. If it wasn't a case, it would lead to 
debugging nightmare...
> I am sorry, but I have not had the time to review your patches.
Ok, I'll continue my work. Almost all changes in code are done now and I 
going to focus on writing documentation that will give others a chance 
to get my patches fitted in bigger picture.
> We should also provide the same mechanism for allowing local overrides 
> of dojo, forms and ajax libs, as this is important during both 
> development, testing and deployment.
Thanks for reminder. It's possible but I'll take care of documenting this.
> Good Luck :)
Thanks! :)

Grzegorz Kossakowski

View raw message