Re: Dojo paths problem
On 6 Feb 2007, at 13:06, Grzegorz Kossakowski wrote: Jeremy Quinn napisał(a): 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 : snip/ 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 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] 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 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. 2.2 and 2.1 may serve dojo.js from different paths, but all other resources must be /relative/ to those paths. 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. 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. My latest patches remove this assumption but obviously breaks C2.1. Jemery, could you take a look at it and give your opinion if that changes could be incorporated into forms/ajax blocks and would not break 2.1 somehow? Thanks. PS. Latest changes to servlet-service-fw break my patches (they will not work anymore) but it could be easily fixed. I'm going to do it as soon as my Subclipse stops hanging on synchronization :( I am sorry, but I have not had the time to review your patches. That sitemap snippet I sent you hopefully gives you an idea about what paths need to be matched. We should avoid changing the matched paths. 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. Good Luck :) regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Dojo paths problem
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: www.yourserver.com/some/long/path/forms www.yourserver.com/ajax Then path to dojo resources become: www.yourserver.com/ajax/resources/js/dojo/** But forms extension to dojo (forms namespace) is avaiable on: www.yourserver.com/some/long/path/forms/resources/js/forms/** (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 later. 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
Re: Dojo paths problem
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:/blocks-test/cocoon-ajax-impl/resources/forms/
manifest.js
http://localhost:/blocks-test/cocoon-ajax-impl/resources/forms.js
http://localhost:/blocks-test/cocoon-ajax-impl/resources/dojo/
__package__.js
Whereby manifest.js is stored under:
http://localhost:/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
smime.p7s
Description: S/MIME cryptographic signature
Re: Dojo paths problem
Jeremy Quinn napisał(a): 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 : snip/ The point is, while using servlet-service-fw there is *no* root sitemap handling all request. Request are handled by dispatcher servlet, instead. Given that, resources of forms should be absolutely separated from ajax's ones. We should not assume there is some root context path and we can calculate all relative paths against it. My latest patches remove this assumption but obviously breaks C2.1. Jemery, could you take a look at it and give your opinion if that changes could be incorporated into forms/ajax blocks and would not break 2.1 somehow? Thanks. PS. Latest changes to servlet-service-fw break my patches (they will not work anymore) but it could be easily fixed. I'm going to do it as soon as my Subclipse stops hanging on synchronization :( -- Grzegorz Kossakowski
Re: Dojo paths problem
Grzegorz Kossakowski napisał(a): 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:/blocks-test/cocoon-ajax-impl/resources/forms/manifest.js http://localhost:/blocks-test/cocoon-ajax-impl/resources/forms.js http://localhost:/blocks-test/cocoon-ajax-impl/resources/dojo/__package__.js Whereby manifest.js is stored under: http://localhost:/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? Ok, never mind. I've figured out all these things myself. My current patches make all path independent from each other. -- Grzegorz Kossakowski
Dojo paths problem
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:/blocks-test/cocoon-ajax-impl/resources/forms/manifest.js http://localhost:/blocks-test/cocoon-ajax-impl/resources/forms.js http://localhost:/blocks-test/cocoon-ajax-impl/resources/dojo/__package__.js Whereby manifest.js is stored under: http://localhost:/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
