Re: Very early 2.1.12-dojo1_1-dev committed
Hi Roy Many thanks for the continued updates. Sorry to say, still too busy earning at the moment regards Jeremy On 16 Feb 2009, at 04:40, lingerer huang wrote: Hi,Jeremy The new dojo 1.3 is on the way. When I tried using dojo 1.3 beta1,many widgets failed. According to the http://trac.dojotoolkit.org/ticket/7994 , the implement should modified too. Regards Roy Huang.
Re: Very early 2.1.12-dojo1_1-dev committed
Hi Roy Sorry, no progress, I am busy on a commercial project at the moment . Will get back to it soon I hope regards Jeremy On 22 Jan 2009, at 09:46, lingerer huang wrote: Hi,Jeremy Is there any progress?I know it is not appropriate to ask that,but I want to help to speed it up. Regards Roy Huang
Re: Very early 2.1.12-dojo1_1-dev committed
Hi Roy On 21 Oct 2008, at 03:22, lingerer huang wrote: As most user and developer ,I am using Microsoft's OS,I am using Windows' XP. But I do use many type of browsers like IE,firefox,google chrome. The last time I had to debug MSIE issues with CForms was while developing the Upload/Progress stuff, it was difficult, the dev tools in MSIE were not as good as FireBug etc. Also I had to do it via VNC to a 'donated' machine, which is a real PIA. So if there is anyone out there who could help work out what is going wrong with MSIE, it would be really appreciated !! I am just a dojo user not a developer, so debug dojo and apply some patch is beyond me by now. But I will try to find the problem. Your potential road to committership ?? ;-) Anyway, thanks your work and your reply, I think why you don't get feedback is you didn't provide the svn url in your mail. I must checked the old archive mail to find the url when you start the work. Doh !! https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X-dojo1_1 or http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X-dojo1_1 Thanks again regards Jeremy
Re: Very early 2.1.12-dojo1_1-dev committed
Hi Roy Many thanks for your feedback On 17 Oct 2008, at 10:42, lingerer huang wrote: Hi,Jeremy One of my project need to combine cocoon and dojo 1.2 together,so I checked your branch and tested it. You did a good job but I still found some problems: 1.Your custom dojo module can't be loaded under IE6/7,though it works under FF 3 and Google chrome 0.2. IE reports js Errors like: Line 293 Error: Cound not load 'cocoon.forms.common' ; last tried '/_cocoon/resources/forms/js/common.js' I am not in a position to test under MSIE, but would welcome any patches or bugfixes : ) BTW. In order to get the line numbers of the actual faults (rather than a line number of the dojo.js loader) you need to explicitly load the relevant JS files via script src=. . . tags rather than using dojo.require. 2.When I replace dojo src from 1.1.1 to 1.2.0,FF 3 and Google chrome won't work too. The debug message like : uncaught exception dojo.hitch: scope[_onkeyup] is null (scope=[Widget I try to remove the define in you design and rebuild it ,then the error dispear but also some feature disappear. This step is important to me caue I am using dojo 1.2 new datagrid.And you should modify some css and uncomment dojo js files refrence in you form style xsl. I tried it with a pre-release 1.2 a while ago and had similar problems. Now 1.2 is released, changing to use it is my next planned step. However it will be a couple of weeks before I can work on this. 3.Some style problem. The Calendar is much bigger font than in dojo test ,and it looks wear. SelectionList will show black as background in Google chrome. Again, without access to Windows, I cannot test under Chrome. Bugfixes most welcome. I don't know why you some some strange charcter like : button dojoType=dijit.form.Button onClick=previousCountry(); style=font-size:90%;#11014;/button button dojoType=dijit.form.Button onClick=nextCountry(); style=font-size:90%;#11015;/button it will show a squar on the button. These are Unicode left and right arrow characters. It is disappointing that they fail on your platform. What is your OS? Which browsers fail to show this properly? I hope these would help. Thanks, it is good to get some feedback (at last). regards Jeremy
Re: Help with Continuations
Hi Joerg Many thanks for your confirmation. Yes, the SuggestionListGenerator uses the sitemap path and the continuation id to lookup the continuation. I don't see any way of working around this. What a shame, I guess this rules out putting this functionality into a system-level sitemap. thanks again regards Jeremy On 22 Sep 2008, at 18:18, Joerg Heinicke wrote: On 22.09.2008 17:12, Jeremy Quinn wrote: However, it seems I am unable to retrieve a continuation made in one sitemap, from another sitemap. Can anyone confirm this? As far as I remember the continuations are managed per sitemap. You might have a look at ContinuationsManagerImpl.lookupWebContinuation(..), around line 240, where it checks the continuation against the stored interpreter ID. That's where you should run through if you access a continuation from another sitemap than the one it was created in if I'm not mistaken. Joerg
Help with Continuations
Hi All I am trying to fix some of the suggestion-list functionality in the 2_1_X-dojo1_1 branch. There are several legacy techniques for implementing suggestion lists. The one I am working on re-implementing is the one that has a JavaScript handler in the Widget model (see src/blocks/forms/samples/ forms/ajax_suggest_form.xml). A request is made, containing the Continuation-Id, the Widget Id and the filter value. Originally, a user had to have a specific pipeline handler in their own sitemap, which uses the SuggestionListGenerator to look up the Continuation, find the Widget, then call it's handler. What I was hoping to do was to have a generic pipeline handler in a new system-level sitemap, which would do this for you, without the user having to copy+paste the handler to their own sitemap. However, it seems I am unable to retrieve a continuation made in one sitemap, from another sitemap. Can anyone confirm this? Is there a way to do this, or will I have to return to the original scheme? Many thanks for any suggestions (ha ha). regards Jeremy
Re: Preparing the new dojo-rsrc build
Hi All Ironically, it turns out that after further testing, the current state of all of the CDNs for Dojo 1.1.1 are not suitable for Cocoon. Unfortunately, whoever did the build, neglected the extra step of making sure full L10N support was added. Dojo ends up with defaults that do not match the output of icu4j and breaks number validation on a very wide range of locales. Exasperating . I am talking to some guys at Dojo about it, to see if they can redeploy 1.1.1 or at least change their release policy to make sure this does not happen with 1.2. regards Jeremy On 11 Sep 2008, at 09:06, Robin Wyles wrote: By default I would prefer not to have to rely on an external service to run any part of my application, so with that in mind option 3 seems most sensible to me. Also, I imagine option 1 would make development without a network connection difficult. I hope that if you read my response to Hussayn earlier in this thread that you will understand my reasoning for going (initially at least) with the first scenario. Because in production, you would be unlikely to serve Dojo from a jar, your usecase of developing offline is IMHO the only case for distributing a full Dojo with Cocoon. I hope you will find that the build script I provide for making a Dojo Jar, makes the job so easy, you will not find it a barrier to offline development. I would be more inclined to put the whole app behind Apach Httpd, and use mod_cache to cache the static resources once they had been served from Cocoon - I've used this approach in the past and it has worked well. This of course means that all required dojo resources would need to be bundled into my webapp. As long as there is a fairly easy way to build my own dojo.jar I'll be satisfied I think! Robin
Re: Preparing the new dojo-rsrc build
Hi Grzegorz You are back early! Hope you had a good holiday. How was the sailing? On 11 Sep 2008, at 13:57, Grzegorz Kossakowski wrote: Jeremy Quinn pisze: So i guess, there will be huge demand to keep all content locally. Hence my favorite scenario would be szenario 3 plus a good documentation of howto make different configurations. Agreed. But as you mention below, in a production environment, no one in their right mind (whoops :) would serve static assets like Dojo from within a jar file, via Cocoon readers . much more sensible to serve it via Apache HTTPd. Jeremy, see Robin's suggestion about using Apache mod_proxy. Caching files served by Cocoon makes much more sense to me than putting them into some directory where httpd will serve them from. I agree in principle, but do be careful with mod_cache, we found it to be very unreliable at high volume. So IMHO, the primary use of the dojo-for-cocoon dist, is to be able to run the CForms Samples and do dev work. So we either have the mega-build (full locale support etc.) currently weighing in at 6.5Meg, making it by far the biggest jar in Cocoon! Or we go for my new nano-build (and a default to use Google CDN, which works extremely well BTW) weighing in at 12K ! I don't know CDN service but for such a crucial component like Dojo I wouldn't be happy that we rely on external, commercial entity that probably gives no guarantees on how reliable its going to be. Using CDNs is all the rage . when I first got CForms working with Google CDN, the first cocoon sample I tried, the page loaded almost instantly, some other site(s) I use must already have cached Dojo from CDN on my machine. This is one of the real advantages of using a popular CDN. BTW: Isn't it an option to use maven2 capabilities ? Please keep in mind that I am working on a solution which will be for both 2.1.x and 2.1. If the maintainers of the maven dist so wish, they could distribute dojo-for-cocoon as either the build for using a CDN /and/ as a build to serve everything yourself. But in the end, the only thing I think the mega-build is useful for is development offline. As making your own build is so easy (there will be an Ant build script in src/blocls/ajax/dojo) to me, it negates any need to add this extra 6.5Meg to Cocoon's distribution. It's good that you have mentioned working offline. I think it's important as there are many developers willing to work offline. At least for me it's crucial that Cocoon is fully functional without fast or any internet connection. Also keep in mind, that I hope it will become popular (and easy) to build a layer file specific to a single form or application (everything needed to support that form, packed into a single file). Again, this has the same production-deployment issues as serving Dojo itself. Different JS files for different Forms? Isn't it a bit of overkill? Clearly it depends on the site and on usage patterns. A single JS for a single form, or a group of forms, becomes cached, making re-access much faster. Also, keep in mind that in such case there is no chance for efficient caching when you have many different forms. You have to find the right balance between many hits to load separate small entities or fewer hits loading larger entities. But in the end, what makes the most difference in forms people will re- use regularly, is a far-future expires header on JS, CSS etc.. Just to sum up: For me relying on CDN should be optional way and not primary one. The problem 6.5mb added to distribution exhibits only weakness of 2.1 distribution system where you get all-in-one package and you have no way to dynamically choose what you want to download. As Hussayn already mentioned with Maven (and 2.2 obviously) this will be different because you state your dependencies in pom.xml file and its Maven that downloads dependencies on the demand so its possible that we'll have two different implementations of Dojo block. The use of CDN would be another solution but as I said I'm happy with relying on external entity's services. At least not by default. Well ATM unfortunately defaulting to use CDN is a mute point, as I mention in my last post, the Dojo on Google's CND is not high enough quality build for our needs. Hopefully that will change. regards Jeremy
Re: Preparing the new dojo-rsrc build
Hi Hussayn Many thanks for your feedback. On 10 Sep 2008, at 08:37, hussayn wrote: Jeremy Quinn wrote: 1) Loading Dojo from Google CDN is the default. dojo-rsrc.jar only contains a few static files required to support Dojo in XD mode (a few K). If a user wants to load Dojo locally, they dl their own copy and use the provided build scripts to make a replacement dojo- rsrc.jar 2) Loading Dojo from Google CDN is the default, but we provide the full dojo-rsrc.jar in the dist (4.7Meg). If a user wants to load Dojo locally, they add map:parameter name=dojo-use-cdn value=false/ to their sitemap 3) Loading Dojo locally is the default We provide the full dojo-rsrc.jar in the dist (4.7Meg). If a user wants Dojo to load from CDN, they add map:parameter name=dojo-use-cdn value=true/ to their sitemap I personally think that (1) has distinct advantages. Less code in our dist, very effective caching and serving of Dojo, etc. Hi; From a commercial system integrators point of view i would not at all like the idea to keep part of the application outside of my companie's firewall. Yes, I understand. So i guess, there will be huge demand to keep all content locally. Hence my favorite scenario would be szenario 3 plus a good documentation of howto make different configurations. But as you mention below, in a production environment, no one in their right mind (whoops :) would serve static assets like Dojo from within a jar file, via Cocoon readers . much more sensible to serve it via Apache HTTPd. So IMHO, the primary use of the dojo-for-cocoon dist, is to be able to run the CForms Samples and do dev work. So we either have the mega-build (full locale support etc.) currently weighing in at 6.5Meg, making it by far the biggest jar in Cocoon! Or we go for my new nano-build (and a default to use Google CDN, which works extremely well BTW) weighing in at 12K ! BTW: Isn't it an option to use maven2 capabilities ? Please keep in mind that I am working on a solution which will be for both 2.1.x and 2.1. If the maintainers of the maven dist so wish, they could distribute dojo-for-cocoon as either the build for using a CDN /and/ as a build to serve everything yourself. But in the end, the only thing I think the mega-build is useful for is development offline. As making your own build is so easy (there will be an Ant build script in src/blocls/ajax/dojo) to me, it negates any need to add this extra 6.5Meg to Cocoon's distribution. Also keep in mind, that I hope it will become popular (and easy) to build a layer file specific to a single form or application (everything needed to support that form, packed into a single file). Again, this has the same production-deployment issues as serving Dojo itself. You may be looking at this thread here: http://www.nabble.com/Howto-use-Dojo-%22standalone%22-with-cocoon---%28does-that-make-sense-at-all-%29-to19040317.html I experimented with this block and first i was quite satisfied. I just was asking myself, if maven could be used to grab dojo from an external repository via dependencies, instead of keeping a dojo-copy right within the block sources... Anyways, i realised at some time of my experiments, that we got some performance issues in our production environment. So we eventually abandonned the above mentioned dojo-block and placed the plain vanilla dojo-distribution directly on our apache-frontend, so that the dojo-files are now directly served from the web-server as static files (and we can simply upgrade to newer dojo-versions without modifying a cocoon-block...) A very normal approach. well, this scenario might not fit into what you are doing since the solution we tried above, was not just a simple give me the dojo-block. It sounds, you are making a full integration into cocoon-forms. YES :) So, are you interested in learning CForms yet? ;-) Just my 2 cents here. Many thanks for your feedback. Sorry I did not agree with everything you said, but I hope you understand my PoV now. I am obviously happy to discuss this further :) regards Jeremy
Re: Preparing the new dojo-rsrc build
Hi Robin, Many thanks for your feedback. On 10 Sep 2008, at 10:00, Robin Wyles wrote: Hi Jeremy, On 8 Sep 2008, at 13:39, Jeremy Quinn wrote: Hi All I am almost ready to start the commit of the new dojo 1.1.1 based cforms to the Branch Grzegorz kindly setup. Great! Can't wait to get my hands on this! Good :-) snip/ By default I would prefer not to have to rely on an external service to run any part of my application, so with that in mind option 3 seems most sensible to me. Also, I imagine option 1 would make development without a network connection difficult. I hope that if you read my response to Hussayn earlier in this thread that you will understand my reasoning for going (initially at least) with the first scenario. Because in production, you would be unlikely to serve Dojo from a jar, your usecase of developing offline is IMHO the only case for distributing a full Dojo with Cocoon. I hope you will find that the build script I provide for making a Dojo Jar, makes the job so easy, you will not find it a barrier to offline development. Thanks again, and please get back to me if you have any further doubts. regards Jeremy
Preparing the new dojo-rsrc build
Hi All I am almost ready to start the commit of the new dojo 1.1.1 based cforms to the Branch Grzegorz kindly setup. The last issue I am trying to sort out is getting XDomain loading working. i.e. having forms and ajax modules served by the local Cocoon instance, while all dojo's js/css etc. is loaded from Google's Ajax CDN : http://ajax.googleapis.com/ajax/libs/dojo/1.1.1/** If I can get XDomain loading to work, we have several different possible scenarios available to us, I am interested in getting feedback from you guys as to which ones are actually useful. 1) Loading Dojo from Google CDN is the default. dojo-rsrc.jar only contains a few static files required to support Dojo in XD mode (a few K). If a user wants to load Dojo locally, they dl their own copy and use the provided build scripts to make a replacement dojo- rsrc.jar 2) Loading Dojo from Google CDN is the default, but we provide the full dojo-rsrc.jar in the dist (4.7Meg). If a user wants to load Dojo locally, they add map:parameter name=dojo-use-cdn value=false/ to their sitemap 3) Loading Dojo locally is the default We provide the full dojo-rsrc.jar in the dist (4.7Meg). If a user wants Dojo to load from CDN, they add map:parameter name=dojo-use-cdn value=true/ to their sitemap I personally think that (1) has distinct advantages. Less code in our dist, very effective caching and serving of Dojo, etc. NB. This is still a bit theoretical, as I do not have XDomain loading working quite yet :( n) The user wants a single JS file that contains everything needed for one form: ... not sure yet, but they'd probably use the build scripts to make a 'layer' file having made a 'profile' to drive the build, which contains references to all of the Widgets required in the form (a handy list appears at the end of every cforms page) The User puts a script src=myForm.js . . . in their Template Please let me know what you think. regards Jeremy
Re: CForms and Dojo
On 23 Aug 2008, at 15:12, Grzegorz Kossakowski wrote: Jeremy Quinn pisze: Should I upgrade to 1.5 before accessing the new Branch? Yes, please. This new merge support requires both client and server of 1.5 version. I am glad I asked (!) Fine by me, enjoy September, I hope the weather is better than August has been !! I'm going to Greece to sail a little bit; the weather simply must be good there. :-) Lucky you! Have a brilliant time :) regards Jeremy
Re: CForms and Dojo
Thanks Vadim, Point taken :) regards Jeremy On 22 Aug 2008, at 00:46, Vadim Gritsenko wrote: On Aug 21, 2008, at 10:59 AM, Jeremy Quinn wrote: But in the short term, what do people prefer? My fully expanded Dojo as a block (every file in SVN), or as a Jar (a single file in SVN)? Personally, jar file is just fine. Most or all IDEs can peek inside jar file and show any file you want to see. And it is faster to pull then 4k files (is this number for Dojo files only or Dojo and all files added by the Subversion?) Vadim
Re: CForms and Dojo
Hi Guys Thanks for the interest On 21 Aug 2008, at 10:47, Grzegorz Kossakowski wrote: Robin Wyles pisze: Hi, Can anyone tell me if this work in progress is available anywhere? I can't seem to find it in trunk.. I am coming up against some bugs when using certain dojo within a repeater - would love to see if dojo 1.1 resolves these. Hi Robin, From my experience it looks like there are many people asking about Dojo 1.1 integration, few that seem to work on this stuff for their own but almost nobody that is willing to work on trunk. The problem with working in trunk (as I saw it) was the sheer amount of time in which cforms would have been unreleasable. Moving from 0.4 to 1.1.1 just broke absolutely everything. Actually, Jeremy Quinn has probably the best progress but he still keeps everything on his local computer to our misfortune. Sorry, it just seemed easier :( Jeremy, I was thinking about this branch yesterday and I think you should branch whole 2.1 and commit your work to your branch. With your help, I'd be happy to do this. Also, even if I could assist with this process (which is very easy btw.) but I think it should be you who establishes the branch because I have no free cycles to support branch of 2.1 at the moment. Fortunately enough, at Apache we have Subversion 1.5 installed so you will be able to take advantage of improved branch/ merge support in 1.5. Lets do it !! I am getting really close to having all widgets re-written to Dojo 1.1.1 APIs, still not quite there yet. But as it looks like I have some work coming up that will delay me further, this could be a good time to get it out. Apart from my dwindling list or re-writes, there will obviously be a big list of niggles and bugs to fix, specially as none of this is tested on MSIE. Cleaning up samples Devising a good scheme for packaging code and i18n Waiting for a slew of bug fixes that will come in Dojo 1.2 Implementing client-side validation based on cforms validators, not just datatypes (as I have now) etc. etc. There is still a lot to do, but once these last few widgets are written and all legacy samples work again, people will be able to run and use it, criticise, tweak, fix, meaning the slope should be downhill :) Robin, back to your question: I hope that once Jeremy publishes his work we can all join our forces to push things forward. When it comes to me, I can help with porting Jeremy's work from 2.1 to trunk. That would be great!! best regards Jeremy
Re: AW: CForms and Dojo
On 21 Aug 2008, at 11:42, Robin Wyles wrote: Many thanks for all your replies... seems there is some enthusiasm for this after all! Once Jeremy's work is accessible somewhere I'd be happy to help with any further work that needs to be done. Chris: I would love to see your xslt, just so I can see if my widget in a repeater woes are solved by dojo 1.1. The Repeater Widget in the new CForms has been completely re-written. Widgets in Repeaters work well (of course :) As a taster, here is some of the new functionality : Repeaters gracefully upgrade from their simplest 'static' form (controlled via action buttons) up to full-blown drag and drop solely via configuration in the Model and Template. Lazy-loading of code ensures that only the Libs required for what you need are loaded. Some of the features of DnD : Easy to control behaviour, enforced by the Model Select row(s) optionally without a visible select control Optional Select/Drag handles DnD single or multiple rows at a time Avatars of rows being dragged plus lots of visual feedback No longer any need for custom handlers in your form for DnD Control over allowing/enforcing copy or move within a Repeater or between Repeaters Control over what is allowed to be dragged from one Repeater to another Control copy/move, multi-select/deselect using typical meta-keys Extensive visual customisation via CSS etc. etc. NB. You should only need to edit the templates of existing projects' Repeaters if : a) you were using the old DnD Widgets (where you specified the Dojo Widget in your Template, nasty) b) you want to use the new behaviour I hope you will find the new Repeater to be a really powerful addition to your webapps and I hope it was worth the wait ;) regards Jeremy
Re: CForms and Dojo
Hi Grzegorz On 21 Aug 2008, at 13:36, Grzegorz Kossakowski wrote: Hi Jeremy, Jeremy, I was thinking about this branch yesterday and I think you should branch whole 2.1 and commit your work to your branch. With your help, I'd be happy to do this. I've created a branch called BRANCH_2_1_X-dojo1_1 based on latest version of 2.1 branch. It's your sandbox now and you can safely play around there without any risk of buildings someone's work or block any releases. The URL for branch is: http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X-dojo1_1/ Brilliant!! Many thanks for this. So, I am running client SVN version 1.4.4 (r25188). Should I upgrade to 1.5 before accessing the new Branch? Lets do it !! I am getting really close to having all widgets re-written to Dojo 1.1.1 APIs, still not quite there yet. But as it looks like I have some work coming up that will delay me further, this could be a good time to get it out. Actually, now it's very easy, just switch your checkout of Cocoon's source code to the branch and commit your stuff there. Don't know which client for svn you are using, but from cmd line it would be: svn switch https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X-dojo1_1/ (https is important here, of course) Yes, thanks for the advice. I only have one ask to you: Could you try to commit as small changesets as possible (of course, not to small)? The best situation would be if one commit reflects one logical change (like migration of one widget to new API or something like that). Rule would be that one commit is big enough to not introduce intermediate states where state of branch is completely broken. So half-baked commits are bad idea. On the other hand, single commit should not contain anything more than is necessary to fulfill requirement outlined above. I ask you to split your work into smaller chunks because then it's easier to merge things in the future and it's much easier to follow your work and port it to trunk. However, I'm aware that when one is doing heavy refactorings following this rules is not always possible. I'll do my best. I'll start to perform the commit, very carefully, over the next couple of days, and report back when I think it is ready for trying out. Last thing: descriptive commit messages. Even if that may sound obvious, but they are really, really needed. ;-) This is especially a case when someone else must keep trunk in sync with your work. Of course Apart from my dwindling list or re-writes, there will obviously be a big list of niggles and bugs to fix, specially as none of this is tested on MSIE. Here I hope that we can count on help of our community. Me too :) Cleaning up samples Devising a good scheme for packaging code and i18n Waiting for a slew of bug fixes that will come in Dojo 1.2 Implementing client-side validation based on cforms validators, not just datatypes (as I have now) Is the last item absolutely necessary for initial release? No it is not. And of course, a major item I left off the list, is updating the documentation etc. etc. There is still a lot to do, but once these last few widgets are written and all legacy samples work again, people will be able to run and use it, criticise, tweak, fix, meaning the slope should be downhill :) :) Robin, back to your question: I hope that once Jeremy publishes his work we can all join our forces to push things forward. When it comes to me, I can help with porting Jeremy's work from 2.1 to trunk. That would be great!! Even there is one caveat: for me September is going to be more or less free month and I plan to not touch computer too much so I could start with porting stuff to trunk in October. Fine by me, enjoy September, I hope the weather is better than August has been !! Now, looking forward to your commits! Many thanks for enabling this. Even though I have been scrupulously backing up, I'll feel a lot safer when this enormous amount of work is in SVN! best regards Jeremy
Re: CForms and Dojo
Hi All On 21 Aug 2008, at 13:36, Grzegorz Kossakowski wrote: Jeremy, I was thinking about this branch yesterday and I think you should branch whole 2.1 and commit your work to your branch. With your help, I'd be happy to do this. I've created a branch called BRANCH_2_1_X-dojo1_1 based on latest version of 2.1 branch. It's your sandbox now and you can safely play around there without any risk of buildings someone's work or block any releases. I have a question regarding how Dojo itself should be packaged. In 2.1.11 (and maybe 2.2) Dojo is compiled into a Jar and served via resource://. There is an Ant script in the Ajax block for building this. While I have been working on 2.1.12-dev, I just made Dojo a 2.1-style block (src/blocks/dojotoolkit), for convenience. I have scrupulously avoided patching the Dojo Release at all, but during development is was useful to have easy access to the source and sometimes add debug statements etc. What I did have to do was to rebuild Dojo's CLDR resources (equivalent to i18n messages) to get the widest L10N support for number formatting etc. (approx 187 variants). This fully-expanded dev-Dojo block (4126 files!!) is very convenient for anyone developing /CForms/ but maybe less convenient for people developing /with/ CForms and definitely no good for going into production. I am confidant that between us, we can come up with a sound solution for making a minified, packaged Dojo, Ajax and CForms release optimised for production . but we still need a more complete version for viewing the samples etc. But in the short term, what do people prefer? My fully expanded Dojo as a block (every file in SVN), or as a Jar (a single file in SVN)? Thanks for any suggestions regards Jeremy
Re: Differences between Cocoon 2.1 and 2.2 (was: Re: Renaming Corona to Cocoon 3.0 and infrastructure)
Hi Grzegorz, Many thanks for your response : ) On 19 Aug 2008, at 12:54, Grzegorz Kossakowski wrote: Hi Jeremy, Jeremy Quinn pisze: From the PoV of users, it should also be clear : If you want or have to use Ant, use 2.1 If you want or have to use Maven, use 2.2 If you just need the Pipeline API, use 3.0 I'm not sure if I get you here correctly so I'll ask: Do you express your own wish or your own perception of situation we have when it comes to differences between 2.1 and 2.2? I am trying to think about this from a 'marketing' perspective. It would be typical to assume (IMHO) that 3.0 is somehow better than 2.2 which is somehow better than 2.1, just because of the version numbers. Whereas from the point of view of a User, making projects (using SiteMaps, XML, XSLT, JXTemplate, FlowScript, etc. etc.) 2.1 and 2.2 are as much as possible, completely compatible and mostly just as capable as each other. The fact that once a User has a suitable build, it makes very little difference whether they use 2.1 or 2.2 (not sure about 3.0) is something that I think we should put across more clearly. It would be a shame to loose potential Users, because they perceived that the version that used their preferred build-technology, was in some way obsolete (which could now happen with both 2.1 and 2.2). Maybe a capability matrix of some sort, would help a User trying to decide which version to use, would provide more reassurance that the 3 versions (or at least 2.1 and 2.2) would provide a viable, stable, long-lasting platform, even though the version numbers may say otherwise. There should be no other difference in quality between the release versions, and none should be implied. I'm afraid that it's not a case for some time at least according to my understand of Cocoon 2.2. The build and distribution system for 2.2 is clearly more modern and sophisticated. It has a polymorphic block paradigm that suits the build technology, it has the powerful concept of virtual pipelines etc. etc. And this is all great ! But from the Users' PoV of making projects, I cannot imagine a project that could be made successfully with 2.2 that could not be made using 2.1 (don't know enough about 3.0). My assumption is that you personally find 2.2 more powerful because you prefer the build technology, not because 2.2 is intrinsically more powerful, or less buggy. This is why I propose that we should give a clear message that all release versions are valid choices, primarily dependant on the build- technology that you prefer, not on specific version numbers. AFAIU, TomCat is in a similar situation, where the different primary versions, represent not quality, but the version of the ServletAPI and JSP Spec they support. see: http://tomcat.apache.org/whichversion.html I hope this is clearer best regards Jeremy
Re: Differences between Cocoon 2.1 and 2.2 (was: Re: Renaming Corona to Cocoon 3.0 and infrastructure)
Just an added note On 19 Aug 2008, at 16:04, Jeremy Quinn wrote: It would be typical to assume (IMHO) that 3.0 is somehow better than 2.2 which is somehow better than 2.1, just because of the version numbers. This assumption is so easy to make, because for instance : 2.1 was better than 2.0 which was MUCH better than 1.0 etc. But now, we seem to use version numbers differently. regards Jeremy
Re: request encoding conundrum
Hi Grzegorz, Sorry for the delay, but I finally got to look at the Upload Sample in CForms. The simple one, without the progress bar does seem to work in my local copy of 2.1.12-dev that I am working on. I tried the sample string below and it came through correctly. Does switching ajax on or off make any difference on your setup? Sorry I could not reproduce your problem :-/ regards Jeremy On 27 Jul 2008, at 18:51, Grzegorz Kossakowski wrote: I've tested it (combined with fix from COCOON-1917) and on the server side everything looks correct now. Great !!! The only problem is that browser sometimes does not behave correctly. I noticed that sometimes when I enter non-latin characters to the text field they get escaped by a browser. So when I enter something like: światło the browser posts to the server such value: #347;wiat#322;o Yes, I see this a lot. I also see UTF-8 encoding like this : %E2%82%AC (which is the 3 byte encoding for the Euro symbol). I have not found this encoding to be a problem. I thought that browser should never escape characters if it's not absolutely necessary. If browser was submitting the data using UTF-8 then that wouldn't be necessary right? What problem does this cause you? Our samples are simply broken that's the problem :-) If you try to use this upload sample I've already pointed you to then you will see that result page produced after forms is submitted contains escaped characters. (additionally there is parameter: dojo.transport=xmlhttp) This is one of the standard parameters that CForms has to add to form submits. CForms uses 3 different transports, depending on context: 1) ajax-off : normal whole page submit 2) ajax-on : xmlhttp 3) ajax-on + form contains a 'file' field : iframe-transport Unfortunately, the response to each of these needs to be serialized differently, hence the need to a very complicated sitemap for cforms and this special parameter. I see. Still I don't understand why our samples are broken. Since I don't know how these things are handled on the client side I'm not sure how to fix it. Any ideas? I need more details of what problem it causes I hope you can reproduce it with upload sample we have in Cocoon.
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Dear Grzegorz I was just in the process of flaming the bejesus out of you for what you just said! Without a whole bunch of very smart 'old-timers' like Sylvain, there would be no Cocoon. The Ant versus Maven controversy has already caused too much disaffection in this project, IMHO. Thanks for retracting/apologising so quickly. regards Jeremy On 18 Aug 2008, at 11:05, Grzegorz Kossakowski wrote: Grzegorz Kossakowski pisze: Stated clearly, I have fears that just as Maven almost killed the developer community for 2.2, announcing a 3.0 now will kill the user community. Sylvain, pardon my ignorance but what kind of real problems with Maven we have _now_ in Cocoon's trunk? I can understand that people were fed up with Maven at the beginning of the transition because it was almost impossible to build Cocoon. But that was more than one year ago. When it comes to user community, I would say that it grows quite nicely. There are people contributing[1][2] some tutorials, sharing their experience and seem to have a real fun with 2.2. Could it be a good idea that old-timers just take an example of our user's community and overcome their own prejudices, finally? I realized that I little bit misunderstood Sylvain's e-mail and used inappropriate tone for my response. The last statement was not really needed. I'm sorry about that, Sylvain. -- Best regards, Grzegorz Kossakowski
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Dear All On 17 Aug 2008, at 18:41, Sylvain Wallez wrote: Also, I haven't voted for the renaming Corona to Cocoon 3.0 as I was on vacation, but I really think this is too early. Cocoon 2.2 is just out and we announce a 3.0. This will most probably lead people to consider 2.2 as a transition to 3.0 and just not use it, and thus just look elsewhere. Stated clearly, I have fears that just as Maven almost killed the developer community for 2.2, announcing a 3.0 now will kill the user community. Many thanks Sylvain for taking the time to voice your opinion. I too missed the vote for the same reason. I too worry about the message being sent here, as a community there are many still smarting from the difficult transition from 2.1 to 2.2 and whether that perception is right or wrong, without community support, this project is dogmeat. While I think a Pipeline etc. API is a brilliant idea, I have doubts that calling it Cocoon 3.0 is the right move, right now. I am too late obviously, the democratic process has taken place, but TBH, reading the C3 site and Reinhard's blog post (sorry Reinhard) left me feeling that we were throwing out the baby with the bathwater. Leaving the difficult and controversial issue of Ant versus Maven aside (Sylvain had good reasons to publicly repudiate Maven, when he did) IMHO all release versions of Cocoon still have relevance : Cocoon 2.1 for Ant fanciers Cocoon 2.2 for Maven mavens Cocoon 3.0 for integrators But I am wondering where 3.0 goes? How does it grow, what true innovations are being thrown away? I do not mean to be sending a negative message, it is important that Cocoon continues to innovate and attract new talent. But we should be very careful in the message we give. 2.2 is only 'better' than 2.1 (etc.) if you prefer Maven over Ant, we should not be putting out the message that somehow 2.1 (and now 2.2) is somehow obsolete. It is just a matter of taste and circumstance, IMHO. regards Jeremy
Re: Renaming Corona to Cocoon 3.0 and infrastructure
Hi Carsten On 18 Aug 2008, at 16:41, Carsten Ziegeler wrote: Please, let's not get into the usual maven bashing threads. I'm tired of reading all the love and hate about maven over and over again. If someone thinks that the current system sucks *and* has time to try out new things, great. If not, let's keep the working system. I agree 100% and apologise if I helped raise it again . What you stated, I think is the correct PoV for Cocoon developers. From the PoV of users, it should also be clear : If you want or have to use Ant, use 2.1 If you want or have to use Maven, use 2.2 If you just need the Pipeline API, use 3.0 There should be no other difference in quality between the release versions, and none should be implied. best regards Jeremy
Re: Proposal - JS Reader
Hi Guys IMHO the most likely scenario ATM will be that JS libs for eg. CForms would be minified and packaged as a production step, either manually or automatically. Then served as Mark says, via HTTPD using gzip compression. i.e. there is more than just compression involved But, I have not got this far yet . regards Jeremy On 13 Aug 2008, at 17:42, Mark Lundquist wrote: I guess a JS reader could be helpful for applications where all resources are served directly by raw Cocoon, i.e. if any compression is to be done then Cocoon has to do it. But don't most applications in a Web setting run Cocoon behind an Apache front- end? Then you can just have Apache gzip whatever you want, all outside of Cocoon, right? And wouldn't that take care of whatever one might want to gain from using a special compressing/minifying component for a specific resource type? I could be totally wrong about this, but that's just how it seemed to me... anyway, is the use case for this specifically the scenario where un-Apache-front-ended Cocoon is being used to serve resources directly? cheers, —ml—
Re: A new name for Corona (take 2)
Has anyone suggested PAPI (Pipeline API) ? sorry have not been following the thread regards Jeremy On 4 Aug 2008, at 07:24, Reinhard Pötz wrote: Any general comments? Any other suggestions?
Re: Procedure for submitting new (demo) documented blocks
Hi Ross I cannot suggest the right way to do it, but I congratulate you on your offering Cocoon 2.2 needs more samples and demos, ATM it looks like it's just a container for Spring Beans :-P (joke) best regards Jeremy On 4 Aug 2008, at 14:12, rossputin wrote: Hi guys, I have spent a while bashing together some database backed code, figuring out which versions of blocks work nicely together etc etc, and believe that I could put together something to help jump start newbies in terms of simple db applications. What is the procedure for submitting a sample block, or would I just link to somewhere I host it if you thought it was useful ? Thanks for your help, regards, Ross
Re: [vote] David Legg as new Cocoon committer
My +1 On 4 Aug 2008, at 12:46, Grzegorz Kossakowski wrote: I would like to propose David Legg as a new Cocoon committer and PMC Member. Thanks Grzegorz regards Jeremy
Re: RFC: Using icu4j for number formatting
Hi Joerg Yes, there are separate icu4jDateConvertor and FormattingDateConvertor (which uses the original java.text.DateFormat). The problem I see, replicating the same separation with Numbers, is having to make almost duplicates of the many Formatting[Number]Convertors, feels like a mess . unless someone can think of a better way of doing it . BTW. Changing to icu4j immediately fixed the majority of formatting problems between CForms and Dojo, the main category still not working are languages (eg. Arabic, Hindi etc.) that use different characters for number digits. Also there are unexpected problems converting the request params back to numbers again (hope to crack that today ... ). The problem icu4j is solving IMHO is more than Dojo compatibility. The java.text.NumberFormat classes seem to have really stale data, switching JVM (or OS) would probably change the formats it outputs. Number, currency and currency symbols are cultural artefacts, they change over time (countries change currency etc.), IBM seem to be more proactive in keeping their libraries up to date. Any suggestions about a clean way to have both Java and ICU NumberFormat ? Thanks regards Jeremy On 30 Jul 2008, at 16:35, Joerg Heinicke wrote: Jeremy Quinn jeremy at apache.org writes: Currently, o.a.c.forms.datatype.convertor.FormattingDecimalConvertor (the baseclass for all Number Formatting convertors), uses java.text.DecimalFormat internally, without exposing the class to the outside (except for one protected Method). If I were to re-implement FormattingDecimalConvertor using icu4j, should I leave the old one alone and create a new icu4jFormattingDecimalConvertor, or work with the original class? Please see [1]. If this solves the problem, this would be the only decimal convertor that would work properly with Dojo, so it would seem pointless to leave the old one around, leading to confusion . But Dojo is not the only option. And considering the differences between icu4j and java.text people might want to have the option to switch. I don't know if Sylvain ever did what he wanted to do (last mail in mentioned thread). Joerg [1] http://marc.info/?t=11096654551r=1w=4
RFC: Using icu4j for number formatting
Dear All Background: While working on validating number fields for CForms, I am finding that there is a huge number of discrepancies between Dojo's localised number formatting and the ones built-in to Java. These discrepancies are breaking Dojo's ability to perform client-side validation for many Locales. @see http://blog.fiveone.org/2008/07/number-format-hell.html I mention a few ideas for solutions in the comments, but I think I came up with a better one .. com.ibm.icu.* provides equivalents to java.text.DecimalFormat, java.util.Currency etc. that are built using the same CLDR (Common Locale Data Repository) dataset that Dojo is built from. @see http://www.unicode.org/cldr/ . Specifically, Dojo 1.1.1 (current release) uses CLDR 1.5.1 that comes in icu4j version 3.8.1 and Dojo 1.2 will use CLDR 1.6 which comes in icu4j 4.0 (clear upgrade path). If this works, the benefit would be that number formatting would be consistent regardless of the JVM you are using (above 1.4 the minimum icu needs to run). Question: Currently, o.a.c.forms.datatype.convertor.FormattingDecimalConvertor (the baseclass for all Number Formatting convertors), uses java.text.DecimalFormat internally, without exposing the class to the outside (except for one protected Method). If I were to re-implement FormattingDecimalConvertor using icu4j, should I leave the old one alone and create a new icu4jFormattingDecimalConvertor, or work with the original class? If this solves the problem, this would be the only decimal convertor that would work properly with Dojo, so it would seem pointless to leave the old one around, leading to confusion . I ask this because when it comes to Date Convertors, we do have separate ones for icu4j and the built-in date formatters. Many thanks for any suggestions regards Jeremy
Re: [vote] Steven Dolg as committer
On 28 Jul 2008, at 16:26, Reinhard Pötz wrote: it's a great honor for me to propose Steven Dolg as a committer My +1 regards Jeremy
Re: [vote] Luca Morandini as new Cocoon committer
On 29 Jul 2008, at 06:29, David Crossley wrote: I would like to propose Luca Morandini as a new Cocoon committer and PMC member. My +1 regards Jeremy
Re: [vote] Andreas Hartmann as new Cocoon committer
On 29 Jul 2008, at 07:27, David Crossley wrote: I propose Andreas Hartmann as a new Cocoon committer and PMC member. My +1 regards Jeremy
Re: [vote] Thorsten Scherler as new Cocoon committer
On 29 Jul 2008, at 07:27, David Crossley wrote: I propose Thorsten Scherler as a new Cocoon committer and PMC member. My +1 regards Jeremy
Re: [Vote] Jasha Joachimsthal as new Cocoon committer
On 29 Jul 2008, at 10:18, Andrew Savory wrote: It's my pleasure to propose Jasha Joachimsthal as a new committer on the Apache Cocoon project. My +1 Yeah! Lots of new blood :) regards Jeremy
Re: request encoding conundrum
Hi Grzegorz Gosh! A lot to respond to :) On 27 Jul 2008, at 18:51, Grzegorz Kossakowski wrote: Jeremy Quinn pisze: I still have all of the notes and the builds we did (thanks!). But I am still doing the work in 2.1, as (if I remember properly) we did not manage to make a build that would edit live at the level of the cforms block itself. Correct me if I am wrong, but it seems easier to setup 2.1 so that edits made to the built-in resources of the block are immediately live without re-building. Jeremy, yep, you are wrong here. ;-) Glad to hear it :) snip I hope that this is impressive enough way of convincing you that you are wrong. ;-) Thanks for your effort ! I'll work through that lot to see if I can adapt it to the scheme you helped me with to work without Eclipse . which as you know I only use if absolutely necessary ... but I am still bogged down with subtle differences in format interpretation between Java and Dojo, with validating number fields, it's a minefield .. blog entry half written ;) Eager to read. Still working out the details of what goes wrong I see only two small obstacles: 1. As I have already seen it at ApacheCon you have some nice work in your computer. The problem is that if you keep it on your computer then nobody can test it and eventually help you with this stuff. Any reason to not commit your work that you already have to some public place? There are a few problems that have stopped me doing this so far : 1) too lazy (so far) to set up and maintain some kind of branch/ sandbox ;) Weak excuse I must say, branching blocks (at least in 2.2) is a very easy task. Actually, we have maintenance branches for Forms and Template blocks here: http://svn.eu.apache.org/repos/asf/cocoon/branches/ I could setup branches for Dojo playings there if you wish. For sure 2) I cannot commit anything to head yet, because lots of stuff is still completely broken and/or still has to be re-written to the new APIs. The work has already taken me several months, and there are several more to go . it is unpredictable how much longer this will take, I'd mess up Cocoon's release cycles . Yes, that's why branching is the only option. Yup Otherwise any collaboration is rather difficult. Agreed. What would you propose? The work involves having two or three custom blocks, forms and ajax (atm, I have dojotoolkit as a block). If you are serious about getting involved, I'd be prepared to make the extra effort to collaborate. It's difficult to say if I'm serious because my plans are little bit changeable at the moment. The situation looks like this: The company I'm working at is seriously interested in migrating Forms to Dojo 1.x but now we are busy with migration to 2.2 that nobody knows how long will take. Actually, we have some estimations and provided everything goes well I'll be working on this migration *very* soon. OK On the other hand, we are making an open source here, right? I would much more prefer you commiting small changes that others can review than coming with big contribution that nobody can check or follow. It's catch 22 As soon as I replace dojo 0.4 with 1.1 EVERYTHING broke, so the changeset is huge. There is no way around this OK, so I am compounding that by adding new features as I go, but basically yes, there will be some massive commits Moreover, I've seen some users playing with Dojo 1.x and Cocoon 2.2 on our users mailing list so there are chances that you will get some supporters even if my plans change for some reason. Therefore, I would suggest to publish your work regardless of my own plans. For sure 2. I prefer to work with C2.2 (trunk) because it's simpler than 2.1 and it's much easier to develop/test anything here. Any chances that you will switch with your work to trunk? You find 2.2 simpler, I find 2.1 simpler :) If we could find the right way to collaborate, you can work on 2.2- specific issues, and I can work on 2.1. Jeremy, I hope that my video will convince you that things with 2.2 are simpler. Another fact is that more and more people interested in Cocoon switch to 2.2 so your work on it will get more wider audience. Also, take into the account that in 2.2 we can release blocks independently of the rest so it's much easier release cycles with real work that gets done. One of the major problems with 2.2 is the loss of the 'system pipelines' that in 2.1 provide a set of static URIs for loading cforms and dojo resources; coupled to the fact that /someone/ misunderstanding dojo APIs thought it necessary to introduce a resource-path for use by cforms widgets client-side. It's been me who removed 'system pipelines' in trunk as we have a superior mechanism for serving block resources: it's servlet: protocol and Servlet Service Framework in general. Yes, and it's OK, I understand why ... When
Re: request encoding conundrum
Hi Andrew, On 29 Jul 2008, at 14:46, Andrew Savory wrote: Hi, 2008/7/29 Jeremy Quinn [EMAIL PROTECTED]: I'll work through that lot to see if I can adapt it to the scheme you helped me with to work without Eclipse . which as you know I only use if absolutely necessary I have to grudgingly say, the new release (Ganymede) almost makes Eclipse worth the horrific overhead. You might want to try it out... Ha Ha Ha! Thanks for this :) Yeah Eclipse on MacOSX was always a dog ;-) I obviously miss the great features like auto-completion, but my main problem with Eclipse is that I am so used to all of the text-editing gestures of native Mac text editors, I find it really painful to use . but hey! even Apple get it wrong . Mail.app is also AWEFUL! :-p best regards Jeremy
RFC: Setting Currency on FormattingDecimalConvertor
Hi All Coming out of my work to add client-side datatype-validation to CForms Fields, I am proposing to add a new method and configuration option to o.a.c.forms.datatype.convertor.FormattingDecimalConvertor, to allow the setting of a specific currency, when the 'currency' variant is used. ATM, there is no option to set the currency, so the currency is automatically selected by the locale of the user. (Something that could loose eCommerce sites some money :) With this change, you'd have two different ways to setup the currency : In the CForms Model : fd:datatype base=decimal fd:convertor variant=currency currency=GBP/ /fd:datatype Or in Flow : var model = form.getModel(); model.dieselprice = new Packages.java.math.BigDecimal(100); form .getChild (dieselprice).getDatatype().getConvertor().setCurrency(GBP); The number then gets displayed using that currency, but in the locale of the user : eg. en_GB: £1,000,000.00 nl_NL: GBP 1.000.000,00 fr_FR: 1 000 000,00 GBP de_CH: GBP 1'000'000,00 hi_IN: GBP १,०००,०००.०० etc. (You wouldn't /believe/ how many ways there are of showing a number!!!) As an aside . in the near future (I hope!) when the new validating cocoon.forms.NumberField is working properly, the user will see the field populated with the full formatted string for their locale. When they click to edit, the content switches to an easier-to-edit format : eg. view: £1,000,000.00 edit: 100.00 The field validates as you type, giving you real-time feedback. When you have finished editing, the field reverts to it's full-format display mode. Your feedback would be welcome. regards Jeremy NB. Don't get confused by the term 'convertor' . this is converting between a Java Number Object and a locale formatted String, it is not converting from one currency to another (!!).
Re: request encoding conundrum
On 25 Jul 2008, at 13:54, Grzegorz Kossakowski wrote: Jeremy Quinn pisze: I am trying to solve a nasty request transcoding bug, that I found while working on CForms. Join the club! Discovered character encoding problems two days ago in a project based on Cocoon 2.1.x. Tried to fight it yesterday and gave up. You work with 2.1 ?? I am shocked :) Stay cool, it's only because this project is going to be migrated to 2.2. Actually Mavenization and migration to 2.2 is my main job here. :) What about you? Have you already become convinced to Cocoon 2.2? Have you got it running and can you develop on top of it? I still have all of the notes and the builds we did (thanks!). But I am still doing the work in 2.1, as (if I remember properly) we did not manage to make a build that would edit live at the level of the cforms block itself. Correct me if I am wrong, but it seems easier to setup 2.1 so that edits made to the built-in resources of the block are immediately live without re-building. A change like this while simplifying our codebase, could cause utter havoc to users . I don't know if unicode really is a practical superset of every other possible encoding. Sorry, I do not think I know enough about this either. Ok. Anyway just for record what wikipedia says[1] about UTF-8: UTF-8 (8-bit UCS/Unicode Transformation Format) is a variable-length character encoding for Unicode. It is able to represent any character in the Unicode standard, yet the initial encoding of byte codes and character assignments for UTF-8 is backwards compatible with ASCII. For these reasons, it is steadily becoming the preferred encoding for e-mail, web pages, and other places where characters are stored or streamed. So it can represent anything from Unicdoe, let's have a look at Unicode[2] itself: In computing, Unicode is an industry standard allowing computers to consistently represent and manipulate text expressed in most of the world's writing systems. Developed in tandem with the Universal Character Set standard and published in book form as The Unicode Standard, Unicode consists of a repertoire of more than 100,000 characters [...] If Unicode can handle 100 000 of characters then I guess anyone will have a hard times to find any character not correctly encoded by Unicode. Yes, I know that is the 'party line' about unicode :) But TBH, I don't know if it really covers every possible obscure case. Yes, I was expecting that. Upgrading CForms upload widget is on my long list . I guess you just bumped it forward a few places :) Nice. :) ... but I am still bogged down with subtle differences in format interpretation between Java and Dojo, with validating number fields, it's a minefield .. blog entry half written ;) Still I'm interested in your work on CForms especially when it comes to the /server/ side where I feel quite comfortable. Even I'm busy with my work here at my company and I have some other Cocoon stuff to do I would like to support you on your effort. Great ! I see only two small obstacles: 1. As I have already seen it at ApacheCon you have some nice work in your computer. The problem is that if you keep it on your computer then nobody can test it and eventually help you with this stuff. Any reason to not commit your work that you already have to some public place? There are a few problems that have stopped me doing this so far : 1) too lazy (so far) to set up and maintain some kind of branch/ sandbox ;) 2) I cannot commit anything to head yet, because lots of stuff is still completely broken and/or still has to be re-written to the new APIs. The work has already taken me several months, and there are several more to go . it is unpredictable how much longer this will take, I'd mess up Cocoon's release cycles . Otherwise any collaboration is rather difficult. Agreed. What would you propose? The work involves having two or three custom blocks, forms and ajax (atm, I have dojotoolkit as a block). If you are serious about getting involved, I'd be prepared to make the extra effort to collaborate. 2. I prefer to work with C2.2 (trunk) because it's simpler than 2.1 and it's much easier to develop/test anything here. Any chances that you will switch with your work to trunk? You find 2.2 simpler, I find 2.1 simpler :) If we could find the right way to collaborate, you can work on 2.2- specific issues, and I can work on 2.1. One of the major problems with 2.2 is the loss of the 'system pipelines' that in 2.1 provide a set of static URIs for loading cforms and dojo resources; coupled to the fact that /someone/ misunderstanding dojo APIs thought it necessary to introduce a resource-path for use by cforms widgets client-side. I can hopefully help you over-come these problems. This is the current JS Loader for 2.1.12-dev : script src=/_cocoon/resources/dojotoolkit/dojo/dojo.js
Re: request encoding conundrum
Hi Andreas,
Many thanks for your interest.
Here is the diff, I hope it helps. I am a little bit behind the latest
update, I hope that does not cause you any problems.
regards Jeremy
Index: src/java/org/apache/cocoon/environment/http/HttpEnvironment.java
===
--- src/java/org/apache/cocoon/environment/http/HttpEnvironment.java
(revision 637948)
+++ src/java/org/apache/cocoon/environment/http/HttpEnvironment.java
(working copy)
@@ -75,8 +75,14 @@
super(uri, null, root, null);
this.request = new HttpRequest(req, this);
-this.request.setCharacterEncoding(defaultFormEncoding);
-this.request.setContainerEncoding(containerEncoding);
+
+if (req.getCharacterEncoding() == null) { // use the value
from web.xml
+this.request.setContainerEncoding(containerEncoding !=
null ? containerEncoding : ISO-8859-1);
+} else { // use what we have been given
+
this.request.setContainerEncoding(req.getCharacterEncoding());
+}
+this.request.setCharacterEncoding(defaultFormEncoding !=
null ? defaultFormEncoding : UTF-8);
+
this.response = new HttpResponse(res);
this.webcontext = context;
Index: src/java/org/apache/cocoon/environment/http/HttpRequest.java
===
--- src/java/org/apache/cocoon/environment/http/HttpRequest.java
(revision 637948)
+++ src/java/org/apache/cocoon/environment/http/HttpRequest.java
(working copy)
@@ -316,23 +316,17 @@
public String getParameter(String name) {
String value = this.req.getParameter(name);
-if (this.form_encoding == null || this.container_encoding ==
null || value == null) {
-return value;
+if (!this.container_encoding.equals(this.form_encoding)) {
+value = decode(value);
}
-// Form and container encoding are equal, skip expensive
value decoding
-if (this.container_encoding.equals(this.form_encoding)) {
-return value;
-}
-return decode(value);
+return value;
}
private String decode(String str) {
if (str == null) return null;
try {
-if (this.container_encoding == null)
-this.container_encoding = ISO-8859-1;
byte[] bytes = str.getBytes(this.container_encoding);
-return new String(bytes, form_encoding);
+return new String(bytes, this.form_encoding);
} catch (UnsupportedEncodingException uee) {
throw new CascadingRuntimeException(Unsupported
Encoding Exception, uee);
}
@@ -345,7 +339,7 @@
public String[] getParameterValues(String name) {
String[] values = this.req.getParameterValues(name);
if (values == null) return null;
-if (this.form_encoding == null) {
+if (this.container_encoding.equals(this.form_encoding)) {
return values;
}
String[] decoded_values = new String[values.length];
On 23 Jul 2008, at 23:18, Andreas Hartmann wrote:
Hi Jeremy,
Jeremy Quinn schrieb:
[…]
But I have a solution I think :)
do you have the time to provide a patch with your changes for the
2.1.x branch? We're currently facing encoding problems [1] with Dojo
in Lenya, and I can imagine that your proposal might fix them.
Setting both container encoding and form encoding to utf-8 and
setting the Content-Type header in Dojo [2] seems to work with
Jetty, Firefox 3 and Safari, but I'm not sure about any side effects.
I'll be on vacation for the next two weeks, but maybe someone else
from the Lenya community is willing to do the testing.
Re: request encoding conundrum
On 24 Jul 2008, at 09:06, Grzegorz Kossakowski wrote:
Jeremy Quinn pisze:
Hi All
Hi Jeremy! :-)
Hi Grzegorz, nice to hear from you :)
I am trying to solve a nasty request transcoding bug, that I found
while working on CForms.
Join the club! Discovered character encoding problems two days ago
in a project based on Cocoon 2.1.x. Tried to fight it yesterday and
gave up.
You work with 2.1 ?? I am shocked :)
AFAICS this bug effects older versions as well . accented
characters not roundtripping due to bad transcoding in Cocoon,
under certain circumstances.
CForms works in one of two modes: ajax-on and ajax-off.
When ajax is on, CForms submits the form via an XMLHttp Request
(XHR), when it is off it submits the form normally.
Servlet Requests are expected by default to be encoded using
ISO-8859-1 (appalling choice!!!), but of course to get any real
work done on the international web, you should use UTF-8 (now
Cocoon's default, thanks to Vadim).
When I was looking at our code in HttpEnvironment, HttpRequest and
in MultipartParser I started to wonder if it would be an option to
forget about any other encodings apart from UTF-8. According to my
knowledge, there is no serious software that does not support Unicode.
This would help us to clean up and simplify the code in trunk
greatly so it would go into 2.3 release (don't be afraid, you won't
need to wait for it years, I promise).
The only problem is that I don't have any significant experience
with such issues so I would like to hear if my proposal makes sense.
Would it be possible to support Unicode only?
A change like this while simplifying our codebase, could cause utter
havoc to users . I don't know if unicode really is a practical
superset of every other possible encoding.
Sorry, I do not think I know enough about this either.
Browsers should post data in the encoding of the page containing
the form.
Dojo always posts forms as UTF-8 when it does XHR, seemingly
regardless of the page encoding. Furthermore, the post has a
Content-Type header : application/x-www-form-urlencoded;
charset=UTF-8. (Default in FireFox3, can be set in Safari, unknown
in MSIE).
Jetty responds properly to the Content-Type header, by
automatically using that charset for decoding Request Parameters
instead of the default ISO-8859-1. (behaviour of other
ServletEngines unknown). This leads to a transcoding bug because
Cocoon assumes ISO-8859-1.
I think that behaviour of Jetty is correct. Right?
It /seems/ right
When forms are submitted normally (i.e. non-XHR) they usually do
not contain the Content-Type header (tested with FireFox3 Safari)
and it does not seem possible to set one from JavaScript (XHR has
the api to do it).
So unless the user has set a different encoding for the
serialisation of their forms, CForms Requests will always be in
UTF-8, but the Content-Type header will not always specify this.
If the Content-Type header contains a charset, (at least in Jetty)
no further transcoding should happen. If it does not contain a
charset, the encoding will be default and parameters must be
transcoded.
So, if the header is correctly set, Cocoon's transcoding hack
(o.a.c.environment.http.HttpRequest.decode) breaks, because it
assumes standard ISO-8859-1.
Therefore we face the situation where it is impossible to get
correct decoding via settings in web.xml : container-encoding and
form-encoding
that work for both ajax-on and ajax-off forms from the same
instance of Cocoon.
But I have a solution I think :)
I propose that the default settings in Cocoon's web.xml for
container-encoding and form-encoding should be :
container-encoding : ISO-8859-1
- meaning: my servlet container uses this as it's default encoding
(unless some modern browser tells it different)
form-encoding : UTF-8
- meaning: this is Cocoon's default encoding for forms
Make this change to o.a.c.environment.http.HttpEnvironment's
constructor :
change :
this.request.setCharacterEncoding(defaultFormEncoding);
this.request.setContainerEncoding(containerEncoding);
to:
if (req.getCharacterEncoding() == null) { // use the value from
web.xml
this.request.setContainerEncoding(containerEncoding != null ?
containerEncoding : ISO-8859-1);
} else { // use what we have been given
this.request.setContainerEncoding(req.getCharacterEncoding());
}
this.request.setCharacterEncoding(defaultFormEncoding != null ?
defaultFormEncoding : UTF-8);
Then cleanup o.a.c.environment.http.HttpRequest methods :
public String getParameter(String name) {
String value = this.req.getParameter(name);
if (!this.container_encoding.equals(this.form_encoding)) {
value = decode(value);
}
return value;
}
private String decode(String str) {
if (str == null) return null;
try {
byte[] bytes = str.getBytes(this.container_encoding);
return new String(bytes, this.form_encoding
Re: AW: AW: AW: AW: Client-side validation in CForms
Hi Chris On 22 Jul 2008, at 21:17, Christofer Dutz wrote: Hi ... well I never really used the I18N Stuff, I have to admit. Every time I got in contact with it (currently using Cocoon 2.1.10) I thought they were text files and no Xml files. OK. IMHO i18n is well worth getting your head around . very powerful . I use it for most if not all static strings in my projects, regardless of whether I want to make it work in multiple languages. Regarding your Expression-Interpreter. I do have quite some experience with parsers and interpreters, so maybe this could be a part that I could help you with. That would be very cool ! If we think of all Form elements as dojo widgets, we could use the dojo query functions for finding elements, since it's a lot easier navigating in the widget hierarchy than in the html page (dojo.byId vs. dijit.byId). Sounds like an interesting approach. There is also the standard form elements Array and the dojo Widget registry to help find stuff. One problem will be that the CForms model is a hierarchy and is ID'd and traversed as one, while on the client it is effectively flat. Unfortunately I am currently struggling with some issues of my current cocoon project, but I think I will have them solved in the next few days. I would gladly help with these client side validators, but I would rather suggest adjusting the Server Side Sax-Generation to output the needed information first ... without this, all client side stuff is useless, since we can't get the validator rules to our cforms-xslt. I agree, the sax-generation of validation info needs to be done first. There is quite a lot that can be done, without an expression interpreter. Many thanks for your interest regards Jeremy
request encoding conundrum
Hi All
I am trying to solve a nasty request transcoding bug, that I found
while working on CForms.
AFAICS this bug effects older versions as well . accented
characters not roundtripping due to bad transcoding in Cocoon, under
certain circumstances.
CForms works in one of two modes: ajax-on and ajax-off.
When ajax is on, CForms submits the form via an XMLHttp Request (XHR),
when it is off it submits the form normally.
Servlet Requests are expected by default to be encoded using
ISO-8859-1 (appalling choice!!!), but of course to get any real work
done on the international web, you should use UTF-8 (now Cocoon's
default, thanks to Vadim).
Browsers should post data in the encoding of the page containing the
form.
Dojo always posts forms as UTF-8 when it does XHR, seemingly
regardless of the page encoding. Furthermore, the post has a Content-
Type header : application/x-www-form-urlencoded; charset=UTF-8.
(Default in FireFox3, can be set in Safari, unknown in MSIE).
Jetty responds properly to the Content-Type header, by automatically
using that charset for decoding Request Parameters instead of the
default ISO-8859-1. (behaviour of other ServletEngines unknown). This
leads to a transcoding bug because Cocoon assumes ISO-8859-1.
When forms are submitted normally (i.e. non-XHR) they usually do not
contain the Content-Type header (tested with FireFox3 Safari) and it
does not seem possible to set one from JavaScript (XHR has the api to
do it).
So unless the user has set a different encoding for the serialisation
of their forms, CForms Requests will always be in UTF-8, but the
Content-Type header will not always specify this.
If the Content-Type header contains a charset, (at least in Jetty) no
further transcoding should happen. If it does not contain a charset,
the encoding will be default and parameters must be transcoded.
So, if the header is correctly set, Cocoon's transcoding hack
(o.a.c.environment.http.HttpRequest.decode) breaks, because it assumes
standard ISO-8859-1.
Therefore we face the situation where it is impossible to get correct
decoding via settings in web.xml : container-encoding and form-
encoding
that work for both ajax-on and ajax-off forms from the same instance
of Cocoon.
But I have a solution I think :)
I propose that the default settings in Cocoon's web.xml for container-
encoding and form-encoding should be :
container-encoding : ISO-8859-1
- meaning: my servlet container uses this as it's default encoding
(unless some modern browser tells it different)
form-encoding : UTF-8
- meaning: this is Cocoon's default encoding for forms
Make this change to o.a.c.environment.http.HttpEnvironment's
constructor :
change :
this.request.setCharacterEncoding(defaultFormEncoding);
this.request.setContainerEncoding(containerEncoding);
to:
if (req.getCharacterEncoding() == null) { // use the value from web.xml
this.request.setContainerEncoding(containerEncoding != null ?
containerEncoding : ISO-8859-1);
} else { // use what we have been given
this.request.setContainerEncoding(req.getCharacterEncoding());
}
this.request.setCharacterEncoding(defaultFormEncoding != null ?
defaultFormEncoding : UTF-8);
Then cleanup o.a.c.environment.http.HttpRequest methods :
public String getParameter(String name) {
String value = this.req.getParameter(name);
if (!this.container_encoding.equals(this.form_encoding)) {
value = decode(value);
}
return value;
}
private String decode(String str) {
if (str == null) return null;
try {
byte[] bytes = str.getBytes(this.container_encoding);
return new String(bytes, this.form_encoding);
} catch (UnsupportedEncodingException uee) {
throw new CascadingRuntimeException(Unsupported Encoding
Exception, uee);
}
}
public String[] getParameterValues(String name) {
String[] values = this.req.getParameterValues(name);
if (values == null) return null;
if (this.container_encoding.equals(this.form_encoding)) {
return values;
}
String[] decoded_values = new String[values.length];
for (int i = 0; i values.length; ++i) {
decoded_values[i] = decode(values[i]);
}
return decoded_values;
}
So we only guess at the encoding, if we really don't know what it is.
My understanding is that TomCat also returns null for
getCharacterEncoding() if the default encoding is being used, but I do
not know if it responds properly to a Content-Type header with a
charset in it.
My guess is that either browsers sending proper Content-Type (with a
charset) and/or ServletEngines responding properly to it, must be a
relatively recent development.
This is not tested outside of :
MacOSX, FireFox3, Safari, Jetty
If you have got this far, and would be willing to test this in other
environments, it would be most helpful.
best regards
Jeremy
Re: AW: AW: AW: Client-side validation in CForms
Hi Chris
Sorry it took me so long to reply.
On 17 Jul 2008, at 16:48, Christofer Dutz wrote:
Hi Jeremy,
doesn't dojo load a i18n resource for the messages?
It does, but this may be perceived as a problem because CForms users
expect to supply all of their own i18n messages (and I personally find
some of dojo's language a bit un-natural).
I don’t think it should
be a problem taking over this or getting Dojo to load our i18n
resources ...
This is most likely possible, but I have not looked into it yet.
xml-i18n resources for cocoon would have been really nice for
this ... in
the worst case I think it should be possible (it even might already
exist)
to create a resource-file-generator, that simply converts these nasty
text-form resource files to neat xml and then translate this to Dojo
i18n
resources with a simple xslt.
Are you confusing java i18n properties-type bundles with Cocoon i18n
xml message files?
Transforming Cocoon's XML bundles to Dojo's json-based format should
not be too difficult.
With the other problems ... well I agree that they might be
tricky ... but
what would the challenge be, if everything was easy? ;-)
Well, we should start with the low hanging fruit :
regExp, min, max, email, mod10, value-count etc.
I was googling for a JavaScript implementation of the XReporter
expression language, but no luck yet ;)
I have never written an interpreter before :)
But I was thinking about a simple case like this :
fd:validation
fd:range min=number1 + 1
fd:failmessageThis number should be larger than the first
number./fd:failmessage
/fd:range
/fd:validation
client-side (off the top of my head) :
var min = 0;
try {
with (this.form) min = eval(number1 + 1)
} catch e {
// could not evaluate expression
}
so 'number1' gets evaluated in the scope of this.form.
but it quickly gets nasty ..
The languages comparison operator is a single '=' not a double one :(
References to fields can be relative (../fieldname) etc. etc.
I think the main difference in my approach and the old Cocoon
approach is
not to reinvent the wheel. I never quite understood all the
double-implemention of widgets. But I have to admit the old Dojo was
missing
quite some stuff and I even had to bugfix quite a lot in the Dojo0.4
Stuff.
At the moment simply using Dojo and providing some very basic
JavaScripts
should be sufficient.
Well one of the problems is that there is a big mismatch between the
assumptions behind Dojo and CForms.
eg. number fields
Cocoon expects no smarts on the client, so a user would typically have
a converter for a form value to send a locale-formatted string
representation of the number to edit to the client :
value: 1234567.89
sends: 1,234,567.89 (en_GB)
1 234 567,89 (fr_FR)
etc.
Cocoon then expects the formatted value in return.
Dojo however, expects to send and receive un-formatted numbers,
performing l10n client-side.
This is not impossible to resolve, but it indicates some of the less-
obvious complexities :)
Thanks for your feedback
regards Jeremy
Re: AW: AW: Client-side validation in CForms
Hi Chris
Thanks for this, it should speed me up a bit, I hope : )
Simple client-side validation based on datatype is working here.
Dojo's constraints and filters are working too, so as a proof of
concept it is working well.
One issue(?): when a field is invalid (while you are typing) you will
see one of Dojo's generic i18n error messages until you have submitted
the bad data to Cocoon, only then will you see the cform's error
messages. Not sure if there will ever be a workaround for this ...
So currently, the main problem is that you'd have to specify the same
validation twice ..
model :
fd:field id=name required=true
fd:hintPlease name your datasource/fd:hint
fd:helpdivThis is breally/b helpful advice!!/div/fd:help
fd:datatype base=string/
fd:validation
fd:regexp pattern=C.*
fd:failmessageSorry, the PMC really does insist the name
should begin with the letter 'C'./fd:failmessage
/fd:regexp
/fd:validation
/fd:field
template (eg. with filters applied on the client) :
ft:widget id=name
fi:styling propercase=true trim=true regExp=^C.*/
/ft:widget
Obviously it is ghastly to specify the same validation twice, so the
next sensible step IMHO is to get the validation info generated out to
the template in a form that can be processed by xslt into appropriate
constraints for dojo.
eg: {min: 10, max: 1, places: 0} etc.
The main problem is going to be handling expressions . specially
stuff that points to other objects :
fd:validation
fd:range min=number1 + 1
These are the constraints for Number types :
pattern: String?
override [formatting pattern] (http://www.unicode.org/reports/tr35/#Number_Format_Patterns
) with this string
type: String?
choose a format type based on the locale from the following:
decimal, scientific, percent, currency. decimal by default.
places: Number?
fixed number of decimal places to show. This overrides any
information in the provided pattern.
round: Number?
5 rounds to nearest .5; 0 rounds to nearest whole (default). -1
means don't round.
currency: String?
an [ISO4217](http://en.wikipedia.org/wiki/ISO_4217) currency code,
a three letter sequence like USD
symbol: String?
localized currency symbol
locale: String?
override the locale used to determine formatting rules
The constraints for Ranges :
min: Number?
the lowest value allowed
max: Number?
the highest number allowed
Hopefully we can pull out a usable subset of cforms validation and
present it to the client-side.
I'll let you guys mull it over for a while :)
Thanks again
regards Jeremy
On 14 Jul 2008, at 14:45, Christofer Dutz wrote:
snip/
I think generating the validation-output needed for client side-
validation
shouldn't be a big problem, since it’s the same for almost all
widgets the
class having to be patched should be the simple Widget base-classes.
I would
volunteer implementing it, but only if it is really wanted.
Chris
snip/
Re: AW: Client-side validation in CForms
Hi Christofer On 13 Jul 2008, at 13:13, Christofer Dutz wrote: When I was working on my first attempts to do exactly what you are trying to do (CForms using dojo 1.1 and client side validation), I ran into exactly the same problem as you did. I too think it would be easily possible to implement client and server-side validation using dojo. Even if it would not be possible to implement all. Unfortunately the fi-output is hard-coded into the widget class implementation and no validation information is sent. Making client- side validation work, it would make it necessary to patch every single Widget class to output this validation-data, but should be easy to accomplish. I stopped my work on this, since I had doubt's anyone would be interested in a feature like this and the thought of having to maintain patches for so many classes let me drop that idea. I had a look as well and did not fancy ploughing in to the code to add this right now, as I have so much else to do before I can release the client-side stuff (hence asking for volunteers ) What I am working on in the meantime is using the (existing) fi:datatype base=string|integer|long|double|float|decimal/ tags to perform basic datatype validation on the client. My hope is that adding support for this now, will make it easier to add fuller validation client-side in the future. BTW. Christofer, I attempted to contact you earlier about the private work you said you had been doing on Dojo 1.1, to see if I could roll it into my work. If you are interested in contributing, please contact me off-list. Many thanks regards Jeremy -Ursprüngliche Nachricht- Von: Jeremy Quinn [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 9. Juli 2008 17:17 An: dev@cocoon.apache.org Betreff: Client-side validation in CForms Hi All As you may know, I am working heavily on the revamp of Dojo on the client-side of CForms. In Dojo it is possible to perform quite a lot of validation on form fields. There is a partial match between the validation capabilities of CForms and those of Dojo. Several people have thought in the past that it would be good to have the same validation occur on both the server and the client. OTTOMH, the kind of validators we could probably make work in both places would be : email, length, mod10, range and regexp (plus maybe javascript, if we can sort out any context differences) ATM however, no validation information is output by the form generation process. Datatypes are there (which I can initially use) but no validation. So my question is, would someone volunteer to either add the definition's validation tags to the output or help work out the cleanest approach to adding it? Many thanks regards Jeremy
Re: Proposal - JS Reader
Hi Kamal One of the items on my (long) list of jobs to get done, in my re- working of CForms/Dojo is compression/minifying/packaging etc. There are a number of different scenarios that I can imagine people will want to for it, but TBH, I have not thought it all through yet 1) development : uncompressed/un-minified, each 'class' loads separately 2) production (a) : single compressed/minified js file containing just the dojo and cforms code to support one cform, application or site. 3) production (b) : single compressed/minified js file containing just the cforms code to support one cform, application or site, with dojo loaded from CDN. 4) production (c) : load everything from CDN (i.e. arrange to put versionned CForms JS in eg. http://code.google.com/apis/ajaxlibs/) no idea if they'd be up for it . As I said, I have not looked into this very closely yet, but I assumed the first level of support would be documentation on how to use Dojo's built-in compressor within Cocoon manually, with support in the XSLT to allow a developer to specify a specific js file to load instead of all of individual dojo/cforms. I think you need a config file to drive dojo's compressor. It would be interesting to see if this could be automated by a maven or ant build task. regards Jeremy On 12 Jul 2008, at 05:24, Kamal wrote: Hi, It occured to me that Cocoon could probably benefit from a Javascript Reader. This JS Reader would do what a normal resource reader would, unless the user specifies a compression-method parameter. If the compression method is supported, then the JS will be compressed. Right now, I think we can only use JSMin[1] or Package[4], as Dojo ShrinkSafe[2] and YUI compressor [3] rely on custom version of Rhino. Packer [4] is written in plain old javascript. JSMin and Packer are open source, but it is not distributed on any Maven repositories that I can see, so we would need to include them in source. This would be useful for the (very large) JS dependencies in CForms (though, it could be argued that we should be bundling the already compressed version of Dojo and the other Cocoon JS files). I, personally, would find something like this really useful as we have lots of code that we like to keep uncompressed for development, but compress at runtime. What does everyone think? I don't mind coding this up (using just JSMin). Apologies if something like this already exists. Cheers. [1] http://www.crockford.com/javascript/jsmin.html [2] http://dojotoolkit.org/docs/shrinksafe [3] http://developer.yahoo.com/yui/compressor/ [4] http://dean.edwards.name/packer/src/
Re: Client-side validation in CForms
On 11 Jul 2008, at 00:51, Kamal Bhatt wrote: Jeremy Quinn wrote: Dear Kamal Many thanks for your response. On 9 Jul 2008, at 23:18, Kamal Bhatt wrote: Jeremy Quinn wrote: Hi All As you may know, I am working heavily on the revamp of Dojo on the client-side of CForms. In Dojo it is possible to perform quite a lot of validation on form fields. There is a partial match between the validation capabilities of CForms and those of Dojo. Several people have thought in the past that it would be good to have the same validation occur on both the server and the client. OTTOMH, the kind of validators we could probably make work in both places would be : email, length, mod10, range and regexp (plus maybe javascript, if we can sort out any context differences) On re-examination, the list of validators that could have an equivalent client-side validator auto-generated is probably shorter . as I am not sure ATM how to implement the expressions possible in some of them . eg. assert, length, range etc. Maybe this is my ignorance speaking, but I don't see any (clean) way of making client side validation work. How a validation message is presentated is left up to forms-styling (or whatever you wish to call it), so you cannot make assumptions about how the validation is presented. Yes, this is an issue that needs addressing. However, there may be an answer . both Cocoon and Dojo are i18n capable, even though they both use different i18n catalogue formats, Cocoon i18n files could be provided to Dojo via a special transformation. Or maybe I am still being naive ; ) I don't know enough about i18n to say. The closest solution I can see is if you created a hook function for all validation and had the hook function propargate the errors that way. Could you expand on what you mean by a hook function? When you get a client side error, you pass information to a function that will indicate what the error is and the field it is associated with. This function will then manipulate the HTML to give you the effect you want (new class, change in the tabbing, etc...). Maybe this doesn't quite work with Dojo, I don't know. Yes, Dojo does work like this. Dojo-supplied fields that may either be required or have validation rules have built-in ways to display this status. Either via Dojo's built-in i18n, or via attributes : @promptMessage and @errorMessage. Both of which could be populated with i18n strings from Cocoon. That still sounds rather messy and sounds like a duplication of effort. Also (if the application is fast), it would lead to some bad UI if some of the validation is done client side some server side. Now, if validation were rewritten in such a way that the hook functions were called for even server side validation errors, it might provide a rather neat way of getting around some of the problems that Ajax CForms throw up as well as reducing duplication. I really wish I had a better understanding of Dojo so I could fix up some of the issues related to validation and Ajax. ATM however, no validation information is output by the form generation process. Datatypes are there (which I can initially use) but no validation. So my question is, would someone volunteer to either add the definition's validation tags to the output or help work out the cleanest approach to adding it? Thanks regards Jeremy
Re: Client-side validation in CForms
Dear Kamal Many thanks for your response. On 9 Jul 2008, at 23:18, Kamal Bhatt wrote: Jeremy Quinn wrote: Hi All As you may know, I am working heavily on the revamp of Dojo on the client-side of CForms. In Dojo it is possible to perform quite a lot of validation on form fields. There is a partial match between the validation capabilities of CForms and those of Dojo. Several people have thought in the past that it would be good to have the same validation occur on both the server and the client. OTTOMH, the kind of validators we could probably make work in both places would be : email, length, mod10, range and regexp (plus maybe javascript, if we can sort out any context differences) On re-examination, the list of validators that could have an equivalent client-side validator auto-generated is probably shorter . as I am not sure ATM how to implement the expressions possible in some of them . eg. assert, length, range etc. Maybe this is my ignorance speaking, but I don't see any (clean) way of making client side validation work. How a validation message is presentated is left up to forms-styling (or whatever you wish to call it), so you cannot make assumptions about how the validation is presented. Yes, this is an issue that needs addressing. However, there may be an answer . both Cocoon and Dojo are i18n capable, even though they both use different i18n catalogue formats, Cocoon i18n files could be provided to Dojo via a special transformation. Or maybe I am still being naive ; ) The closest solution I can see is if you created a hook function for all validation and had the hook function propargate the errors that way. Could you expand on what you mean by a hook function? That still sounds rather messy and sounds like a duplication of effort. Also (if the application is fast), it would lead to some bad UI if some of the validation is done client side some server side. Now, if validation were rewritten in such a way that the hook functions were called for even server side validation errors, it might provide a rather neat way of getting around some of the problems that Ajax CForms throw up as well as reducing duplication. I really wish I had a better understanding of Dojo so I could fix up some of the issues related to validation and Ajax. ATM however, no validation information is output by the form generation process. Datatypes are there (which I can initially use) but no validation. So my question is, would someone volunteer to either add the definition's validation tags to the output or help work out the cleanest approach to adding it? thanks regards Jeremy
Client-side validation in CForms
Hi All As you may know, I am working heavily on the revamp of Dojo on the client-side of CForms. In Dojo it is possible to perform quite a lot of validation on form fields. There is a partial match between the validation capabilities of CForms and those of Dojo. Several people have thought in the past that it would be good to have the same validation occur on both the server and the client. OTTOMH, the kind of validators we could probably make work in both places would be : email, length, mod10, range and regexp (plus maybe javascript, if we can sort out any context differences) ATM however, no validation information is output by the form generation process. Datatypes are there (which I can initially use) but no validation. So my question is, would someone volunteer to either add the definition's validation tags to the output or help work out the cleanest approach to adding it? Many thanks regards Jeremy
Re: reworking CForms Repeater
On 30 May 2008, at 07:19, Gabriel Gruber wrote: I'll try to give some feedback from my side. I am a heavy CForms user with 50+ forms mainly handling hibernate objects. Thanks Gabriel Jeremy Quinn wrote: The Dojo DnD libraries have more capabilities than are currently supported in CForms. I am trying to work out which are realistic to implement here. 1. move more than one row at the same time within a single Repeater 2. clone row(s) within a single Repeater 3. move row(s) from one Repeater to another 4. clone row(s) from one Repeater to another In general the cloning option would be really a nice feature where I can think of some usecases in our apps. good We are using repeaters quite often and it would indeed be nice to be able to clone an existing row. [Allthough I am pretty sure you can do it with a custom CForms Action on the serverside by creating a new Row and adding the content by hand.] Correct, the current dojo-repeaters sample using CFormsDragAndDropRepeater works like this. It requires you to supply your own clone function named in the 'dnd-action' parameter. Part of what I am trying to do is to remove this requirement, by providing generic clone handlers, much like the generic 'move' handler (used for moving a row within a single Repeater). I am adding 'copy', 'copy-to' and 'move-to', where the '*-to' handlers work between Repeaters. Jeremy Quinn wrote: The immediate problem I am facing is twofold : 1. We are adding rows, so the User's 'add-row' handler should probably get the opportunity to run. It currently does not, so in the example (based on: samples/blocks/forms/do-dojoRepeater.flow) the cloned row(s) do not get a new unique ID. How do I ensure User handlers get executed? 2. All of the samples of 'add-row' handlers I see make the assumption that the row that has just been added, has been added at the end of the Repeater, eg. repeater.getRow(repeater.getSize() - 1).getChild(ID).setValue(count); Now we are using DnD, this assumption is no longer true, there may be more than one new row and they may not be at the end. Should or do we have a way to find out what was added, from within a User handler? Will this type of cloning cause problems further down the line, when for instance it is used to edit a Repeater that represents a Collection of Beans persisted via ORM (etc.)? ... As you already stated it is absolutely necessary that in case of ORM binds being binded that new rows get a NULL identifier. That means that the widget which is declared in the on-bind section of the corresponging binding-xml file does not get the value of the repeater-row, from where it was copied. In hibernate for instance these rows (with null identifier-widgets) would be then saved as new objects to the database (if binding was done right). Yes, thanks for reminding me. These are the steps that take place : 1) On the client-side a row-clone operation is performed. 2) The client sends an Ajax Request with parameters that specify what is being cloned and to where, plus which handler should be run. 3) The generic handler calls Repeater.addRow which builds a new row from the Template and runs the binding (?). 4) The handler recursively copies the values from the source row to the target row. 5) The changed Repeater(s) are rendered and their html replaces the content in the client-side. So the problem is this, I think : Regardless of whether the binding runs in step (3) or not, the handler does not know which field is being used to hold the ORM identifier, so would copy it, if it were in the model. Is it realistic to have a CForm which usefully edits and creates Objects /without/ the CForm Model containing the ORM identifier? (AFAIK, there is no immutable widget). (I don't actually /know/ when or if the binding happens in this scenario) In general I would prefer a solution which supports the old behavior and events if possible. I am not planning on changing the existing Request parameters, except because I am supporting move/copy on several rows simultaneously, I am allowing the 'from' parameter to be a value-list instead of just a single value. I also plan to leave in support for 'dnd-action', so that the built-in handlers may be optionally replaced by custom a user-supplied handler in the model. Thanks for the feedback regards Jeremy BTW. The other big change that is happening to repeaters is that you would no longer specify the particular dojo widget to use in your Template (this was bad for lots of reasons IMHO). There will be a couple of extra optional parameters on the repeater in the model to control what is allowed to be dragged into it and a few new stylings in the template to control the styling and behaviour of dnd (it will be off by default). Form generation via JX Macros will output repeater tags, there will once again be built-in xslt to render repeaters.
Re: Meeting in Amsterdam
On 30 Mar 2008, at 13:06, Reinhard Poetz wrote: Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Is there anybody who is going to attend the ApacheCon in Amsterdam? I'll be there at the two Hackathon days (Mon full day, Tue till 3pm) and would love to have some discussions about Corona. What about a meeting on Monday 2pm at the official Hackathon room? (Though I don't know if this conflicts with other community events Sling/Jackrabbit/Wicket/... Could people involved with these communities clearify?) Standard question: Is there any chance to set up some audio/video recording? I would be very, very interested in hearing/watching such a record. Don't think of some formalized event. It will rather be some folks discussing Cocoon related issues in a relaxed environment. Anyway, I will report to this list, what we have been discussing. Hi All I'd love to discuss stuff about the re-working of CForms : ) But I don't get in until late afternoon on Monday. regards Jeremy
Re: [2.2] Forms dependency on Ajax block
On 18 Mar 2008, at 05:40, Joerg Heinicke wrote: On 13.03.2008 16:20, Luca Morandini wrote: This means that Forms must depend on Ajax (Dojo to be more precise) despite the fact you use Ajax or not. As Joerg said, we are currently re-working the client-side aspect of CForms to use Dojo 1.0 (or better 1.1). To try to answer a few of your issues : CForms has relied on Dojo for quite a while now. Don't confuse Dojo with Ajax. Dojo is used regardless of whether you want Ajax (XMLHTTPRequest) behaviour or not as we want consistency in our widgets. Parts of CForms would probably work with JavaScript turned off, though TBH, this has never been a high priority. IMHO it will be very difficult to make a version of CForms that works reliably without JavaScript. CForms is declarative. As the forms are rendered, the system has no knowledge of whether JavaScript is running on the client. CForms cannot stop you from using stuff that would not work. eg. onchange handlers etc. The dependency that the Forms block has on the Ajax block is currently very important. CForms uses the BrowserUpdate mechanism for updating forms on the fly. BrowserUpdate consists of client-side DOM insertion code, server-side Transformer and sitemaps. BrowserUpdate is the largest proportion of the Ajax Block. It is quite possible that BrowserUpdate is /only/ used by CForms. The other stuff in the Ajax Block is : 1) support (server-side code and sitemap) for File Upload Progress Bar 2) PartialLink and periodicalUpdate, two samples that are probably more proof-of-concept than actually useful. I hope this helps. best regards Jeremy PS. The Ajax Block and samples now work with Dojo 1.0. so we are moving on to tackle CForms itself.
Re: [GSoC_2008] Project ideas
Hi Reinhard On 13 Mar 2008, at 15:54, Reinhard Poetz wrote: Yesterday I was introduced to an Austrian student who would be interested in working on a GSoC for the Cocoon project this year. The best idea we've had so far was was an upgrade of cForms to Dojo 1.x (or replacing it with something else if that is what the community is interested in). Argh. I have been researching this for the past few weeks with the intention of starting work to make this upgrade myself. I guess I should have mentioned this earlier . I doubt I am eligible for GSoC :) What should we do? regards Jeremy
Re: [GSoC_2008] Project ideas
On 17 Mar 2008, at 13:53, Reinhard Poetz wrote: Jeremy Quinn wrote: Hi Reinhard On 13 Mar 2008, at 15:54, Reinhard Poetz wrote: Yesterday I was introduced to an Austrian student who would be interested in working on a GSoC for the Cocoon project this year. The best idea we've had so far was was an upgrade of cForms to Dojo 1.x (or replacing it with something else if that is what the community is interested in). Argh. I have been researching this for the past few weeks with the intention of starting work to make this upgrade myself. I guess I should have mentioned this earlier . I doubt I am eligible for GSoC :) What should we do? go ahead! I'm sure that we will find something else that is of interest to potential applicants that would want to work on the Dojo upgrade (broader support for widgets, making Javascript optional, etc.). Yes, there is a lot to do in CForms, even after changing it to use Dojo 1.n. IMHO all of the work CForms needs is dependant on the switch to the new Dojo. For instance it seems pointless working on Dojofying old widgets (etc.) if the API is changing. I suggest we put together a road-map for what we need to do. Here is a possible start (off the top of my head) : 1) Switch to Dojo 1.n, reworking current Widgets and infrastructure to use new Dojo APIs. 2) Re-write existing Widgets that still use 3rd-party libraries, as Dojo Widgets. 3) All CForms Widgets to be rendered as Dojo Widgets to get a consistent visual theme, theme modification, WAI behaviour etc. 4) Find a way to allow HTMLArea (etc.) to be a plugin replacement for Dojo Rich Text Editor (as I assume this would have been replaced in step 2). 5) Make use of Dojo Layout Widgets when rendering CForms. 6) Implement a nice solution for compiling minimised JavaScript to support a specific Form/Webapp/Project/Site. 7) Perform client-side validation (as defined in CForms Model) where possible eg. RegExp, Min/Max, Range, Required, etc. etc. 8) Melding Dojo's and Cocoon's I18n into a coherent whole. 9) Re-work BrowserUpdate mechanism to allow DOM/Widget Update as well as DOM Replacement, to overcome issues with broken round-tripping with certain Widgets in Repeaters (eg. populated fileupload). 10) Deprecate FormsTransformer in favour of the CForms JX Macros, cleanup support for obsolete schema. There are probably many more, let's discuss :) Apart from item (1), the order is not so important. Unless I suddenly get more work, I can work on item (1) now. If anyone wants to take up any of the other issues as a GSoC project, I would definitely consider offering myself as a mentor, if that would be useful. Ugh, so now I have to GOMA and actually deliver =:-0 (Thanks for the gentle kick, Reinhard :) best regards Jeremy
Re: C2.2 dojotoolkit
Hi Joerg On 6 Feb 2008, at 05:26, Joerg Heinicke wrote: On 04.02.2008 08:43, Dev at weitling wrote: if the migration to Dojo 1.0 tends to become a big piece of work what about migrating to Prototype/Scriptaculous (or similar)? The last Dojo update to 0.4.3 was not that long ago, was it? So it can't be too hard to update ... Of course I might be totally wrong :-) It is actually quite a lot of work, I have been looking into it .. I'd love to do it, but being self-employed, cannot spare the time/ expense right now .. unless someone is willing to offer some sponsorship ;-) There have been quite a few architectural changes going from 0.4.n to 1.0, including really core stuff that we use heavily like the auto package loading being removed. Another big aspect is re-writing the widgets that still use other third-party libraries, to custom dojo widgets, we really could be using one Ajax library, not several. I hope we find a solution, we have discussed the same issues for two years running now at CocoonGTs ! best regards Jeremy
Re: [ANN] Apache Cocoon 2.1.11 Released
On 9 Jan 2008, at 17:34, Carsten Ziegeler wrote: Apache Cocoon 2.1.11 Released Many thanks Carsten !! regards Jeremy
Re: [vote] Deprecated HTMLArea
On 14 Aug 2007, at 08:01, Felix Knecht wrote: I would like to deprecated HTMLArea as WYSIWYG HTML editor, because it's no longer developed and maintained [1]. +1 Thanks Felix
Re: 2.2 using cocoon-ajax-impl
On 24 May 2007, at 08:01, Marc Portier wrote: anyways trying to explain the issue: System.JSON.js quite clearly states that it only supports serialization of some basic types, and collections and maps so people that want to serialize out custom java beans to JSON have two options 1. add that functionality to the JSON stuff by overriding the _serializeValue function (or using dojo-binding-like -yes on the server side- aop advise on it 2. convert their java-objects first to maps and collections of the mentioned basic structures... Hi Guys Yes, the JSON serialization flowscript is really basic. I just did what was needed to solve a simple problem. JSON supports so few datatypes. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
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: Rewriting links in js files
HI If you are using Dojo, it can already do this on the client. for instance : templatePath: dojo.uri.dojoUri(../viewr/templates/HtmlStory.html), Gives you a url relative to where Dojo loaded from. HTH regards Jeremy On 1 Feb 2007, at 23:13, Grzegorz Kossakowski wrote: Hi, Yes, it's me n-th time ;) I would like to discuss link rewriting in js files and other text resources (css for example). Obviosuly, soon or later, there will be need (actually it already is, in Forms) to store some paths in JS files. That means that we have to take care of rewriting links in this kind of resources. My proposal is to introduce new reader for this task. It would scan whole content of file for valid URLs to rewrite, and do the job. I think, it could be easily achieved by use of some regexps. Of course, this new reader would implement caching because rewriting of some big files would be quite time-consuming. I haven't looked into the code of LinkRewritingTransformer so I'm not sure if it's code could be reused. Even if I had to write it from scratch I'm enough motivated but need to be sure that my work is not waste of time. Do you have any thoughts? Other options? -- Grzegorz Kossakowski smime.p7s Description: S/MIME cryptographic signature
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: cforms dojo updates: calendar, help and validation messages, multivalue editor
Hi Bruno Excellent work !! regards Jeremy On 21 Jan 2007, at 15:04, Bruno Dumon wrote: Hi, I've replaced the calendar, the help and validation message popups and the multi-value editor with dojo-based implementations. Thanks to Jeremy for upgrading to dojo 0.4, which made this possible and easier. For the first 3, these now use dojo's popup-things, which has the user-visible advantages of using a backing iframe in IE (so the popups are displayed on top of other input fields), correct positioning of the popups in IE, and at most one popup is open at the same time. Since validation messages are also displayed via these popups, any mixed content in them will now be preserved. For the calendar, it now supports date, time, and datetime selection, this is driven by the 'variant' attribute of the formatting date convertor. As before, the server-side date/time patterns are also also used on the client. The calendar is internationalized, for the precise supported languages see the dojo-languages parameter in form-field-styling.xsl. If anyone notices problems, feel free to fix or report them. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: Dojo jar into cocoon block?
On 17 Jan 2007, at 15:39, Antonio Gallardo wrote:
Hi Jeremy,
Thanks for you reply. You are right. However, I think it is simpler
to redeploy a new jar in the WEB-INF/lib directory.
Would you explain me why the jar is inside the cocoon-ajax.jar?
(Don't get the question wrong. I want to know the reason). :)
:)
I am not sure TBH.
We are talking cocoon 2.1.n right ?
For 2.1.n, Dojo should be in lib/optional/dojo-rsrc-20061224.jar,
copied to build/webapp/WEB-INF/lib during the build.
I do not know how it found it's way into the build of the Ajax Block
for 2.1.n.
For 2.2, the Dojo Zip at src/blocks/ajax/resources/org/apache/cocoon/
dojo/resources/dojo-0.4.1-ajax.zip is unpacked during the build to
provide the deployment.
This may be the cause of confusion . 2.1.n and 2.2 share the same
blocks . but the dojo zip should not be deployed during the build
of 2.1.n, only 2.2.
HTH
regards Jeremy
Best Regards,
Antonio Gallardo.
Jeremy Quinn escribió:
Hi Antonio
There should already be a simple way to override the built-in dojo
and all the resources used by CForms as well.
In the root sitemap, there is a section to load these 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
So if you add :
cocoon/build/webapp/resources/dojo/**
cocoon/build/webapp/resources/forms/**
cocoon/build/webapp/resources/ajax/**
etc. these will override the content of the built-in jars.
Is this what you are after ?
regards Jeremy
On 16 Jan 2007, at 17:21, Antonio Gallardo wrote:
hi:
I just noted the dojo.jar is now into the cocoon-ajax.jar.
Should not it better if the dojo.jar (or dojo.zip) is a different
file to make it easy to update in case the user needs to update
dojo without a cocoon rebuild?
WDYT? :)
Best Regards,
Antonio Gallardo.
smime.p7s
Description: S/MIME cryptographic signature
Re: Dojo jar into cocoon block?
Hi Antonio
There should already be a simple way to override the built-in dojo
and all the resources used by CForms as well.
In the root sitemap, there is a section to load these 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
So if you add :
cocoon/build/webapp/resources/dojo/**
cocoon/build/webapp/resources/forms/**
cocoon/build/webapp/resources/ajax/**
etc. these will override the content of the built-in jars.
Is this what you are after ?
regards Jeremy
On 16 Jan 2007, at 17:21, Antonio Gallardo wrote:
hi:
I just noted the dojo.jar is now into the cocoon-ajax.jar.
Should not it better if the dojo.jar (or dojo.zip) is a different
file to make it easy to update in case the user needs to update
dojo without a cocoon rebuild?
WDYT? :)
Best Regards,
Antonio Gallardo.
smime.p7s
Description: S/MIME cryptographic signature
Re: RFC: CForms Roadmap
Hi Bruno Thanks for the heads-up. On 9 Jan 2007, at 09:06, Bruno Dumon wrote: Hi Jeremy, On Sun, 2007-01-07 at 13:01 +, Jeremy Quinn wrote: Hi All Now that Cocoon 2.1.11-dev runs Dojo 0.4.1, I think we have a solid platform to complete the modernisation of CForms client-side code. snip/ Replacements : Date/Time widget : replace MattKruse stuff with Dojo's implementation. I'm going to need this in the next couple of weeks, so it's very likely I'll work on this. Excellent. I hacked one up recently . not well enough to commit . one possible issue could be problems with l10n of the dates output by the widget. It was outputting US-style dates, I was probably doing something wrong. Help validation popups: replace MattKruse stuff with a new Dojo implementation. I've got something like this in Daisy already, it seems to work quite well, so I could move it into CForms. Great ! I was thinking of using a Dialog class as this would let users turn on cool lightbox effects etc. MultiValue Editor: re-implement as a Dojo widget This is also one I'm motivated to work on, since I wrote it originally. Cool again ;) I still need to get up-to-date with dojo 0.4 and the current cforms, but if all goes well I hope to be able to do something about these 3. Great news! I went through all of the implementations of the Cocoon-supplied Dojo Widgets, trying to clean up their usage of the Widget API. So hopefully they provide a reasonably set of clean examples for you. Have fun ;) regards jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Current status of the new documentation
On 6 Jan 2007, at 20:22, hepabolu wrote: Jeremy Quinn said the following on 6/1/07 20:22: OK, I only have 'guest' under the role menu, so I assume someone has to enable me as a doc-editor? Fixed. Your default role is doc-editor, but I've also given you the doc-committer role (since you're a committer ;-) ) which is allowed to put documents live. Thanks Helma ( oh ! now I have to do something :-) ) regards Jeremy smime.p7s Description: S/MIME cryptographic signature
RFC: CForms Roadmap
Hi All Now that Cocoon 2.1.11-dev runs Dojo 0.4.1, I think we have a solid platform to complete the modernisation of CForms client-side code. I hope the main outcomes of this will be : Leaner: only the resources that are used will be loaded by cforms Richer: more interactive widgets with wider x-platform support Cleaner: eliminate most of the messy script tags scattered through our forms Simpler: use more html templates to simplify our xslt (and simpler to adapt the widgets) Here is a list of specific goals I would love us to achieve for the next release. I hope to be working on this stuff, you would be very welcome if you'd like to join in If you would like to take on something from this list (or something I missed out) please discuss it on the dev list so no-one is duplicating effort. Replacements : Date/Time widget : replace MattKruse stuff with Dojo's implementation. Help validation popups: replace MattKruse stuff with a new Dojo implementation. Tabs: replace with Dojo Tabs RichText: replace htmlarea with Dojo Editor, using a new fi:styling, so htmlarea can still be used MultiValue Editor: re-implement as a Dojo widget MultiList (OptionTransfer) Selector: replace with a new Dojo widget Maps: not even sure our current one is working, replace with Dojo (Yahoo and Google) Possible Additions : Easy graphically rich buttons, dialogs, menus etc. Charts to plot user data Colour picker Re-sizable textarea Sliders: graphical selector for number ranges etc. Spinner: adjust values up and down with ± buttons Validation: plug in client-side validation where common datatypes exist between CForms and Dojo, make new ones Issues: We need to do this work in such a way that has the absolute minimum impact on existing cforms projects. eg. adapting Dojo widgets to work the CForms way and not the other way around. We need to make it easier to customise the style, layout and behaviour of our supplied widgets. We are probably going to have issues with i18n and l10n. Dojo is only just starting to deal with this area, while CForms has always delt with it. Dojo, performs i18n on the client instead of on the server as cforms does. Very few of Dojo's widgets are i18n enabled yet. Dojo uses a different format of i18n message dictionary than we do (all of this is kind of obvious). Most of the work above will involve either extending existing dojo widgets or making new ones. We ought to be adding i18n/l10n as we go along. We need to decide whether we want to keep our message dictionary format (transforming it on the fly for dojo) or start using Dojo's format (for widget internals). What did I miss out ? I hope this whets your appetite ! Let's get on with the replacements first !! WDYT ? regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Current status of the new documentation
Excellent start Reinhard On 6 Jan 2007, at 14:14, Reinhard Poetz wrote: It would be very helpful if you can go through the three reports and verify if everything works as described. Proof-reading from native speakers would be helpful again. I found a few spelling mistakes and registered for an account to edit the document. Forgive me if I am being dumb, but where is the edit link? Do I need to be upgraded from role:guest ? thanks regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Current status of the new documentation
Hi Mark Thanks for the reply. On 6 Jan 2007, at 17:04, Mark Lundquist wrote: On Jan 6, 2007, at 8:53 AM, Jeremy Quinn wrote: I found a few spelling mistakes and registered for an account to edit the document. Forgive me if I am being dumb, but where is the edit link? Do I need to be upgraded from role:guest ? You have to use the Role: pulldown menu to manually change roles to doc-editors. Then the edit item will appear under the Page Actions pulldown menu. OK, I only have 'guest' under the role menu, so I assume someone has to enable me as a doc-editor? thanks regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Changes to CForms in 2.1.11-dev
Hi Ralph It depends on what you do in your application and how. If you do lots of custom rendering, have written your own CForms Widgets, stuff like that, then yes, it will probably have an impact. If your application uses the standard rendering pipelines, standard widgets etc. then the impact is likely to be nil, or small. The most likely effect it will have is on forms where the user has specified a specific dojo widget in their template, instead of having the rendering pipelines produce it for them. They'd have to add the correct namespace prefix. Some of the newer widgets like CFormsRepeater, CFormsDragAndDropRepeater etc. do not have XSLT that generates them from CForms stylings. eg. ft:repeater id=contacts div dojoType=CFormsRepeater orderable=true select=select . . . would become : ft:repeater id=contacts div dojoType=forms:CFormsRepeater orderable=true select=select . . . IMHO this is a small price to pay for the advantages the new codebase will bring. regards Jeremy On 3 Jan 2007, at 01:20, Ralph Goers wrote: Jeremy, Does this break binary compatibility? Some of the changes sound like users who upgrade from 2.1.10 to 2.1.11 may have to modify their application? If so, I see that as a problem. Ralph Jeremy Quinn wrote: Hi All A lot of work is being done on CForms for the 2.1.11 release. It may be a bit disruptive temporarily to users' projects, but IMHO it will be worth it. What if all you do is write a few simple forms and use the standard form-processing pipelines and xslt? There will be very little to do to move to cocoon 2.1.11 as most of the changes are handled by those built-in resources. smime.p7s Description: S/MIME cryptographic signature
Re: Changes to CForms in trunk
On 3 Jan 2007, at 06:08, Reinhard Poetz wrote: Jeremy Quinn wrote: Hi All As you may have seen from my previous message, I have ripped the bejebus out of CForms over the holidays and just committed the changes. I have the changes all tested and running in BRANCH_2.1.X, but have not/cannot test in trunk (umm, are samples working yet?). My understanding is that the forms block is shared between 2.1.X and 2.2, so no problem there (I hope). But 2.1.X uses the dojo in lib/optional/dojo-[date].jar and trunk uses blocks/cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/ apache/cocoon/dojo/resources/dojo-[version]-[profile].zip, which must have been expanded and built into the jar by building the package. Does this sound right? Or is there more to do to support this change in trunk ? IIRC that's all. After providing an initial documentation for 2.2, working on the release of some blocks will be the next item on my todo list. CForms and Ajax will definitly be part of this list of blocks. Expect some feedback from me then! Thanks Reinhard smime.p7s Description: S/MIME cryptographic signature
Re: Changes to CForms in 2.1.11-dev
Thanks for your support Carsten. On 3 Jan 2007, at 11:43, Carsten Ziegeler wrote: Ralph Goers wrote: Jeremy, Does this break binary compatibility? Some of the changes sound like users who upgrade from 2.1.10 to 2.1.11 may have to modify their application? If so, I see that as a problem. While I usually agree with these statements, I think/hope that the benefit of these changes is much higher than the inconvenience you get. For a long time we try to tell our users to recompile their applications when upgrading. With over 150 dependencies, upgrading a Cocoon application and hoping for binary compatibility is very very brave. The other point is that we did such changes (and noone complained in the past). If you upgrade from 2.1.8 to 2.1.9 you might now what a pain it is as mostly everything in cforms changed. Jeremy's lastes changes sound to me like minor changes and as they are well documented I see no real problem with. If we want to go the 100% compatiblity path, the only option is to do changes like these in 2.2... Which is not an option atm as they both share these effected blocks. If this project cannot innovate and move forward, it will become a retirement home ;) But honestly, I worked very hard to minimise the impact !! best regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Changes to CForms in 2.1.11-dev
Hi Steven I am extremely relieved at how relatively painless that looked !!! Many thanks for sending this. best regards Jeremy On 3 Jan 2007, at 21:57, Steven Noels wrote: On 03 Jan 2007, at 13:21, Jeremy Quinn wrote: But honestly, I worked very hard to minimise the impact !! To put things into perspective: this is the impact of the changes for Daisy: http://svn.cocoondev.org/viewsvn?rev=3594view=rev /Steven -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java XML stevenn at outerthought.orgstevenn at apache.org smime.p7s Description: S/MIME cryptographic signature
Changes to CForms in 2.1.11-dev
Hi All
A lot of work is being done on CForms for the 2.1.11 release.
It may be a bit disruptive temporarily to users' projects, but IMHO
it will be worth it.
What if all you do is write a few simple forms and use the standard
form-processing pipelines and xslt?
There will be very little to do to move to cocoon 2.1.11 as most of
the changes are handled by those built-in resources.
A list of the changes :
1. Update the Dojo Libraries to 0.4.1, the latest release (with a few
fixes).
Dojo 0.4.1 seems faster, more stable and more compatible across
browsers.
It brings many benefits, the main one IMHO was the ability to do item
(2).
2. Switch to using namespaces for Dojo Widgets.
The switch to Dojo 0.4.1 allows us to use namespaces for Widgets.
Although in the short-term it may feel that replacing stuff like
dojoType=CFormsSuggest with dojoType=forms:CFormsSuggest is a
PIA, it brings great advantages.
The client-side code now consists of 3 namespaces :
dojo : all of dojo, the default (no need for a prefix)
forms : widgets from the cocoon.forms module
ajax : widgets from the cocoon.ajax module
These namespace modules are registered with dojo and a manifest is
provided so their widgets can be auto-loaded.
What this means is that instead of for example, our XSLT adding
dojo.require(some.package) because something might possibly be wanted
from it, we can leave the dojo.require declarations out, libraries in
the modules load because their module path is registered, widgets
load automatically because they have a resolver in their manifest.
The hack of dojo.require in cocoon.js is no longer required, or used
(or compatible).
It now becomes far easier for you to develop dojo widgets in your own
namespace and have them auto-loaded as well.
If you have custom dojo-savvy js libraries to load you'd do something
like this :
dojo.registerModulePath(myorg.modulename, ../myorg/modulename/
js);
dojo.require(myorg.modulename.mybrilliantlibrary);
. . .
// do something with my library after everything has safely
loaded :
dojo.addOnLoad(function()
{ myorg.modulename.mybrilliantlibrary.doSomethingAstonishing(); });
Dojo would load : _cocoon/resources/myorg/modulename/js/
mybrilliantlibrary.js
This could be served from either :
build/webapp/resources/myorg/modulename/js/mybrilliantlibrary.js
or from a jar file in build/webapp/WEB-INF/libs/ with a package path
like :
org/apache/cocoon/myorg/resources/modulename/js/
mybrilliantlibrary.js
Your library must at least say :
dojo.provide(myorg.modulename.mybrilliantlibrary);
Say your project required you to extend some of CForm's or Dojo's
widgets, the cleanest and simplest thing to do will be to do that in
your own namespace.
Say you were writing Widgets in the same registered module as above,
you would provide a manifest file which dojo would try to load from
here :
_cocoon/resources/myorg/modulename/manifest.js (NB. it is in
modulename/ not modulename/js/).
Your manifest would typically register a namespace like this :
dojo.registerNamespace(mystuff, myorg.modulename,
resolverFunction);
Then it would provide a resolverFunction that maps between lowercase
widget names and a full packagename.
See the manifests in the forms and ajax blocks for an example.
You would use your widgets like this :
div dojoType=mystuff:FunkyMonkey/
and dojo would attempt to load : _cocoon/resources/myorg/modulename/
js/FunkyMonkey.js
As we move more of our CForms widget implementations to dojo, this
will lead to a dramatic reduction of unnecessary code being loaded by
the browser (a big problem in previous versions imho).
3. Cleanup of the client-side code.
Apart from a general push to convert all of cocoon's javascript
(clientside and serverside) into namespaced javascript as a general
best practise, I felt that the existing implementation of the
clientside code was more complex/opaque than it needed to be.
forms_lib.js and cocoon.forms.common have been refactored.
forms_* functions in forms_lib.js have been deprecated and are
replaced by nearly equivalent functions in cocoon.forms.* the old
functions can still be called (temporarily) they do their best to
pass the calls on to the new implementation.
One issue dealt with by this update, is removing barriers to having
multiple cforms per page. This required changing some of the
parameters passed to functions like adding onSubmit handlers, we now
need a reference to the form as well as the handler. Another side
effect of this is that forms now need id attributes. If you do not
have one in your template, one is added for you in the standard
CForms rendering pipelines.
If you are not writing your own CForms Widgets, you are unlikely to
be effected.
4. Dojo widgets for ajax and non-ajax forms.
CFormForm.js which used to be the Dojo Widget used for ajax-enabled
CForms
Changes to CForms in trunk
Hi All As you may have seen from my previous message, I have ripped the bejebus out of CForms over the holidays and just committed the changes. I have the changes all tested and running in BRANCH_2.1.X, but have not/cannot test in trunk (umm, are samples working yet?). My understanding is that the forms block is shared between 2.1.X and 2.2, so no problem there (I hope). But 2.1.X uses the dojo in lib/optional/dojo-[date].jar and trunk uses blocks/cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/ apache/cocoon/dojo/resources/dojo-[version]-[profile].zip, which must have been expanded and built into the jar by building the package. Does this sound right? Or is there more to do to support this change in trunk ? thanks regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Changes to CForms in 2.1.11-dev
On 28 Dec 2006, at 07:38, Carsten Ziegeler wrote: Hi Jeremy, this sounds all great to me - cool :) but I can't really judge the impact of your suggested changes. not until I commit anyway ;) But I have two questions :) Is it still possible to use cforms without javascript after your changes? I have not tested how cforms works without javascript for a long time TBH. I do not see how my changes would effect that situation however, there is still a form with submit buttons, properly designed dojo widgets should embellish an existing form field, so just give you less functionality if the widget does not instantiate. But, this is a very good point, I will do some testing here. And does the new stuff better support multiple forms on one page. I think there are some problems with the current onsubmit handlers when there is more than one form. Yes, I had to change the API for adding submit handlers to allow for more than one form per page. Instead of this : forms_onsubmitHandlers.push(handler) You would have to do this : cocoon.forms.addOnSubmitHandler(formID, handler) Each of your forms must now have a unique ID attribute (one is added in XSLT for you if you did not add your own). Using this ID, I keep the list of submit handlers for each form separate and only call the handlers for the form being submitted. I was looking at ways of having the Form Widget keep it's own submit handlers (avoiding the need for the ID parameter), but I am not sure it would be reliable .. you would not be able to easily guarantee that the calls to add handlers were not made before the Form Widget had instantiated. Whereas cocoon.forms.addOnSubmitHandler is static so does not suffer that problem, it only needs to have been required. I have not tested multi-form pages yet, I am sure there will be other issues to deal with :) Thanks for the feedback regards Jeremy Jeremy Quinn wrote: Hi All I hope you all had a good Christmas. Santa's little helpers have been busy working on CForms over the holiday break :) Below is a list of changes I have in my local repo, ready to commit. I would like to get feedback on these changes, in case of dissent, or usecases I have not fully understood. 1. Updated to use Dojo 0.4.1 -- brings lots of improvements, bug fixes and broader browser support. 2. Introduction of widget namespaces, allows lazy loading of widgets via lookup from a manifest. 3. Dojo debugging is now turned on and off via an optional sitemap parameter. 4. The contents of the optional fi:init/ tag is now inserted after the scripts to load dojo etc. 5. TODO: cocoon.forms.* to take over from forms_* in forms_lib.js. this is done now BTW. snip/ -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Changes to CForms in 2.1.11-dev
On 28 Dec 2006, at 09:26, Jeroen Reijn wrote: Jeremy Quinn wrote: Hi All I hope you all had a good Christmas. Santa's little helpers have been busy working on CForms over the holiday break :) Below is a list of changes I have in my local repo, ready to commit. I would like to get feedback on these changes, in case of dissent, or usecases I have not fully understood. 1. Updated to use Dojo 0.4.1 -- brings lots of improvements, bug fixes and broader browser support. Great! :) 2. Introduction of widget namespaces, allows lazy loading of widgets via lookup from a manifest. Sounds interesting. It is a very cool feature, but it is going to create backwards incompatibility as widget declarations have to change. If all the user is doing is using the built-in XLST libraries, then they should notice no difference. 3. Dojo debugging is now turned on and off via an optional sitemap parameter. Cool Yes, and the debug facilities are far improved. see : http://archive.dojotoolkit.org/nightly/tests/debug/ test_debug_console.html 4. The contents of the optional fi:init/ tag is now inserted after the scripts to load dojo etc. 5. TODO: cocoon.forms.* to take over from forms_* in forms_lib.js. This sounds like a good idea to me. The cleanup has gone quite well. However, people who have written their own cforms rendering pipelines or custom widget will have some work to do. Notes: The upgrade to Dojo 0.4.1 brings us many advantages, but may break some user's custom widgets due to changes in some of the APIs. The work required to adapt the existing forms and ajax widgets was pretty minor. The widgets that come with 0.4.1 are much improved. This will make it far easier to replace the legacy javascripts like htmlarea and the mattkruse-libs with their dojo equivalents, while supporting a wider range of browsers. Hmm I'm still not sure if the Dojo rich text editor is capable of all HTMLArea functionalities. Do your changes allow me to still configure my own rich text editor for certain elements in my cforms page? I know you guys have a heavy investment in HtmlArea :) Also keep in mind that I have not started work on the dojo editor yet . My feelings ATM are that the Dojo Editor is probably more lightweight, has wider compatibility across browsers, is being more actively supported and developed and is therefore more likely to suit common rich-text editing needs of most users. Saying that however, I have no intention of stopping you from using htmlarea ! Currently my intention is not to take the existing 'htmlarea' styling and change it to output a Dojo Editor instead, but to leave the htmlarea styling as it is, and introduce a new styling to create the new editor. The existing XSLT for making an htmlarea need not be removed from cocoon, but IMO it should no longer be automatically imported into the built-in CForms rendering XSLT as it is more difficult to make it lazy-load than the dojo equivalent (htmlarea is always loaded in the current cforms, regardless of whether it is used in the form and this is one of the big issues I am trying to solve). My proposal is that after the change to add the Dojo Editor, anyone wanting to continue to use htmlarea should ensure that the legacy forms-htmlarea-styling.xsl is imported into their XSLT themselves. However, if you think that the XSLT can be adjusted so that forms- htmlarea-styling.xsl does not unconditionally add it's load scripts when it is not used, and does not add significantly to the render overhead, then I would be happy to leave it in. WDYT ? The main rationale for these changes has been to reduce the amount of javascript that gets loaded by a CForms page. Currently everything possible gets loaded, regardless of whether it gets used or not. I'm all +1 on that. Thanks for your feedback mate ! regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: onSubmit Handlers and Ajax
Hi All Another question Currently, when onSubmit Handers are called, they are able to stop the form submit by returning false. OK so far. However, if you have multiple handlers and say the middle one returns false, the ones after it, do not get called at all. Is this the right behaviour? Or should all handlers be always called, returning false if one (or more) of them returns false. i.e. onSubmit Handers should still be able to stop the form from submitting, but they should not be able to stop subsequent handers from being called. WDYT ? thanks regards Jeremy On 27 Dec 2006, at 18:14, Jeremy Quinn wrote: Hi All In 2.1.8, we called forms_onsubmitHandlers when Ajax forms were submitted. In 2.1.9 we stopped doing that and only called them on non-Ajax forms. I do not remember why this was done. Anybody ? thanks regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Changes to CForms in 2.1.11-dev
On 28 Dec 2006, at 12:01, Jeremy Quinn wrote:
And does the new stuff better support multiple forms on one page. I
think there are some problems with the current onsubmit handlers when
there is more than one form.
Yes, I had to change the API for adding submit handlers to allow
for more than one form per page.
Instead of this :
forms_onsubmitHandlers.push(handler)
You would have to do this :
cocoon.forms.addOnSubmitHandler(formID, handler)
A quick correction, the new function is this :
cocoon.forms.addOnSubmitHandler = function(elt, handler)
Where 'elt' is the Element that is adding the handler.
cocoon.forms.addOnSubmitHandler = function(elt, handler) {
if (typeof(handler.forms_onsubmit) == function) {
var form = this.getForm(elt);
if (form) {
var id = form.getAttribute(id);
if (id) {
if (!cocoon.forms.onSubmitHandlers[id])
cocoon.forms.onSubmitHandlers[id] = new Array();
cocoon.forms.onSubmitHandlers[id].push(handler);
} else {
if (dojo) dojo.debug(WARNING: SubmitHandler not
added. There is no id attribute on your form.);
}
}
}
}
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: onSubmit Handlers and Ajax
On 28 Dec 2006, at 15:16, Carsten Ziegeler wrote: Hmm, I'm not sure - I haven't used onSubmit handlers so far as they did not work with multiple forms :) So we are currently using our own handler implementation. Well hopefully this will be solved :) We mainly use them for client-site prevalidation like checking for required fields etc. In this case I think it makes sense to stop after the first failing handler. If I understand you correctly, I think I would prefer all pre- validation to occur even if there are validation errors found, otherwise user needs to fix-submit, fix-submit etc. to 'discover' the errors one by one. I would rather see all validation errors in one go. So I think the current behaviour is fine :) But perhaps there are other use cases? What about a chain implementation? So a handler can decide to call the next handler or not? Eeek! ;) You have a usecase for this ? Should an onSubmit Handler know if others exist ? This is going to mean more api changes and more incompatibility issues for people with custom widgets. :( Convince me ;) And BTW. Can you think why onSubmit Handlers should no longer be called before Ajax submits (the original question) ? best regards Jeremy Jeremy Quinn wrote: Hi All Another question Currently, when onSubmit Handers are called, they are able to stop the form submit by returning false. OK so far. However, if you have multiple handlers and say the middle one returns false, the ones after it, do not get called at all. Is this the right behaviour? Or should all handlers be always called, returning false if one (or more) of them returns false. i.e. onSubmit Handers should still be able to stop the form from submitting, but they should not be able to stop subsequent handers from being called. WDYT ? thanks regards Jeremy On 27 Dec 2006, at 18:14, Jeremy Quinn wrote: Hi All In 2.1.8, we called forms_onsubmitHandlers when Ajax forms were submitted. In 2.1.9 we stopped doing that and only called them on non-Ajax forms. I do not remember why this was done. Anybody ? thanks regards Jeremy -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ smime.p7s Description: S/MIME cryptographic signature
Re: onSubmit Handlers and Ajax
On 28 Dec 2006, at 16:12, Carsten Ziegeler wrote: Jeremy Quinn wrote: If I understand you correctly, I think I would prefer all pre- validation to occur even if there are validation errors found, otherwise user needs to fix-submit, fix-submit etc. to 'discover' the errors one by one. I would rather see all validation errors in one go. Ok, this depends on what you do in the handlers :) Now, we have the use case where we display a popup telling the user what to fix...now if two handlers open up a popup one after the other that's not that user friendly I guess...but we could just use one single handler for this and are done. No problem. Or display errors in a less modal way? BTW. Dojo is adding client-side validation to some of it's form widgets, I'll have a look at that stuff soon, to see if it would be useful in CForms. see: http://archive.dojotoolkit.org/nightly/tests/widget/ test_validate.html So I think the current behaviour is fine :) But perhaps there are other use cases? What about a chain implementation? So a handler can decide to call the next handler or not? Eeek! ;) :) I guessed you love it! You have a usecase for this ? Nope, see my example from above. If we use one single handler for all our prevalidation, we're fine. Should an onSubmit Handler know if others exist ? This is going to mean more api changes and more incompatibility issues for people with custom widgets. :( Convince me ;) Sorry, no :) He he he he ;) And BTW. Can you think why onSubmit Handlers should no longer be called before Ajax submits (the original question) ? I have no idea - but I could imagine that the idea was to invoke the handlers only if the form is really submitted and not for any form based ajax requests. So I guess this is a bug then, but it's just a guess :) I think this should be fixed if noone comes up with a good reason. I think I may have been confused about how dojo.event.connect 'around' advice works. Now I think maybe they are being called during Ajax submits, sorry for the noise. best regards Jeremy smime.p7s Description: S/MIME cryptographic signature
RFC: Changes to CForms in 2.1.11-dev
Hi All
I hope you all had a good Christmas.
Santa's little helpers have been busy working on CForms over the
holiday break :)
Below is a list of changes I have in my local repo, ready to commit.
I would like to get feedback on these changes, in case of dissent, or
usecases I have not fully understood.
1. Updated to use Dojo 0.4.1 -- brings lots of improvements, bug
fixes and broader browser support.
2. Introduction of widget namespaces, allows lazy loading of widgets
via lookup from a manifest.
3. Dojo debugging is now turned on and off via an optional sitemap
parameter.
4. The contents of the optional fi:init/ tag is now inserted after
the scripts to load dojo etc.
5. TODO: cocoon.forms.* to take over from forms_* in forms_lib.js.
Notes:
The upgrade to Dojo 0.4.1 brings us many advantages, but may break
some user's custom widgets due to changes in some of the APIs. The
work required to adapt the existing forms and ajax widgets was pretty
minor.
The widgets that come with 0.4.1 are much improved. This will make it
far easier to replace the legacy javascripts like htmlarea and the
mattkruse-libs with their dojo equivalents, while supporting a wider
range of browsers.
The main rationale for these changes has been to reduce the amount of
javascript that gets loaded by a CForms page. Currently everything
possible gets loaded, regardless of whether it gets used or not.
One of the big changes in 0.4.1 is the introduction of Widget
Namespaces, with it's auto-load mechanism, using a manifest and
namespace resolver to load the Widget's resources. This removes the
need to dojo.require Widgets before they are used :
Before :
script type=text/javascriptdojo.require
(cocoon.ajax.FormUploadProgress);/script
. . .
div dojoType=FormUploadProgressdivUpload Progress Sample/div/
div
After :
div dojoType=ajax:FormUploadProgressdivUpload Progress Sample/
div/div
NB. Unfortunately @class=namespace-WidgetName is not currently
supported by 0.4.1.
The default namespace (does not need declaring) is 'dojo:'.
I have introduced 2 new namespaces for Cocoon, 'forms:' is for
widgets in cocoon.forms.* and 'ajax:' is for widgets in
cocoon.ajax.*. There is a manifest file for each new namespace that
registers the name of each Widget and provides a mapping between a
widget name and it's module and path. i.e.
cformsform -- cocoon.forms.CFormsForm which can be found in : ../
forms/js/
Unfortunately, because dojo.ns does it's resolution in lower case and
we have CamelCase widget names, we need an actual map. New widgets
must be registered there for auto-discovery to work.
The manifest for the forms namespace looks like this :
dojo.provide(cocoon.forms.manifest);
(function(){
var map = {
html: {
cformsdraganddroprepeater :
cocoon.forms.CFormsDragAndDropRepeater,
cformsform: cocoon.forms.CFormsForm,
cformsrepeater: cocoon.forms.CFormsRepeater,
cformssuggest : cocoon.forms.CFormsSuggest
// register new Widgets in the cocoon.forms namespace here
}, svg: {
// register svg widgets here
}, vml: {
// register vml widgets here
}
};
function formsNamespaceResolver(name, domain){
if(!domain){ domain=html; }
if(!map[domain]){ return null; }
return map[domain][name];
}
// cocoon.forms module has a dependency on the cocoon.ajax module
libraries
dojo.registerModulePath(cocoon.ajax, ../ajax/js);
dojo.registerModulePath(cocoon.forms, ../forms/js);
dojo.registerNamespace(forms, cocoon.forms,
formsNamespaceResolver);
})();
The path is wide open for users to add their own auto-loading widget
namespaces via their own manifests. Converting existing custom
widgets to use a custom namespace is pretty trivial.
The big plus we get from this switch, is that is will be far easier
to write the CForms XSLT in a way that allows only used code to be
loaded by the browser. When we have managed to replace all legacy
widgets with dojo equivalents, the browser will only load code that
is actually used.
That pretty much covers points 1 and 2.
The next issues regard points 3 and 4: debugging and the use of
fi:init/.
The fi:init/ tag, introduced in 2.1.9, was being used to add
script/ tags into the html/head of pages *before* dojo was loaded.
It was being used in a couple of samples for turning on dojo debug
mode on the browser.
Debugging can now be turned on from the sitemap :
map:transform src=resources/forms-samples-styling.xsl
map:parameter name=resources-uri value={request:contextPath}/
_cocoon/resources/
map:parameter name=dojo-debug value=true/
/map:transform
Leave the param out or set it to false, to turn off debugging.
Debug messages now should go to the Browser's console (tested in
Safari, FireFox ± FireBug) instead of being written into the end of
the page. You can get navigable tree-views of
Re: [Vote] Release 2.1.10
My +1 too. Many thanks guys. regards Jeremy On 19 Dec 2006, at 12:46, Bertrand Delacretaz wrote: Thanks Carsten, and thanks Joerg for the bugfixing. +1 on the release. smime.p7s Description: S/MIME cryptographic signature
Re: Looking for help in upcoming release
On 16 Dec 2006, at 02:20, Joerg Heinicke wrote: Hello Gary, thanks very much for your efforts. Such extensive testing is very welcome of course. On 15.12.2006 17:48, Stewart, Gary wrote: snip/ Forms - The Capatcha form didn't work in the Forms example (it didn't show the string) and the Batik Block seemed to be working ok. Unfortunately that's a side effect of linking trunk sources into the branch. The Captcha only works with the new JXTemplateGenerator from the template block but not with the one from branch core. While on trunk the one from template block is for sure correctly registered as jx it is the old one on the branch. The new one is named newjx there. Don't know how to solve it without risking to break any template using jx. I could switch jx to oldjx and newjx to jx, but with which side effects? Can somebody comment where old and new differ? I do not know. At the recent GT we discussed the possibility of deprecating the CFormsTransformer, using instead the new JXTGenerator (as Ajax CForms only works with JXMacros and there are annoying differences between the schemas of the 2 generators). It may be too early to deprecate CFormsTransformer (for this release) but would it be possible to replace the old JXT with the new one, so it can be tested more heavily? Also on CForms, Jeroen Reijn pointed out some unsupported legacy code in some of the Ajax pages that needs cleaning up. Lucene Block After creating the index it the search page appeared but I couldn't seem to get any results. Didn't spend any more time on it. Default is http://localhost:/docs/index.html and - again - documentation is no longer included. Don't know what direct it to instead. I fixed the indexer for both the Lucene and QueryBean blocks. The Lucene Sample indexer now crawls http://localhost:888/samples/ blocks/. Run the indexer and you will see quite a few exceptions while crawling our samples :-/ The QueryBean Samples shows an example of how to index using an IndexingTransformer. It indexes all 'welcome.xml' files in block samples. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Looking for help in upcoming release
On 17 Dec 2006, at 16:51, Joerg Heinicke wrote:
On 17.12.2006 17:29, Jeremy Quinn wrote:
It may be too early to deprecate CFormsTransformer (for this
release) but would it be possible to replace the old JXT with the
new one, so it can be tested more heavily?
I'll give it a try and click around a bit.
Lucene Block
I fixed the indexer for both the Lucene and QueryBean blocks.
The Lucene Sample indexer now crawls http://localhost:888/samples/
blocks/.
Ah, nice. I tried it but it run endlessly as you pointed out in
your commit message.
Did you get the update to core samples?
I think it is a flow sample doing this.
Run the indexer and you will see quite a few exceptions while
crawling our samples :-/
For some it is even expected. For some you need correct
configuration. So I would not care too much about it. Gary seems to
have tested quite extensively.
Great!!
While working on QueryBean, I found there are problems with the OJB
Block now.
OJB is not allowing the persistance of QueryBean's Objects, but I do
not know why ATM .
This is the error I think :
ERROR (2006-12-17) 17:50.22:772
[ojb.broker.accesslayer.JdbcAccessImpl] (/samples/blocks/querybean/
add-favourite.html?hid=0) PoolThread-1/LoggerImpl:
PersistenceBrokerException during the execution of materializeObject:
Can't generate primary key values for given Identity
org.apache.ojb.broker.util.sequence.HighLowSequence{SEQ_QUERY}
java.lang.ArrayIndexOutOfBoundsException: 1
Any ideas anyone ?
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: [2.1.10] Javascript errors in multiple forms samples
Hi Jeroen Yes, the script in that page has fallen out of date with the rest of the Ajax infrastructure. Thing is, it does not actually cause errors for me . i.e. the sample works here, it just does not do a fade. Do you get something different ? regards Jeremy On 8 Dec 2006, at 09:52, Jeroen Reijn wrote: Hi, yesterday I started testing the forms block. I found out that some of the samples were broken due to Javascript issues. It seems that for example the car selector sample refers to an cocoon.ajax.Fader object that does not exist. I tried searching for it in the 2.1.10 as well as in the cocoon trunk. Can anybody tell me what happened here? Did somebody forgot to commit it or was it removed at a later time. Kind regards, Jeroen Reijn smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
Hi Carsten
For static files that are just using a reader, this may be a good
solution.
In the case of these system pipelines however, there is a sitemap/
flowscript etc. that has to be executed.
As for static files, they are currently being served for 2 blocks,
Forms which has CForms Dojo Widgets, CSS and Images; Ajax which has
more Widgets etc. plus it contains Dojo libs.
Due to a recent development at AOL, it could be possible to do
without distributing Dojo from Cocoon :
http://ajaxian.com/archives/including-dojo-via-the-aol-cdn
Alex Russell has:
constructed a couple of very small “wrapper” files that will let you
include the “Ajax” build of Dojo from various versions through the
cross-domain loader.
Including the latest stable Dojo couldn’t be simpler:
script src=http://download.dojotoolkit.org/dojo_0.3.1.js;/script
It’s also trivial to test out the latest 0.4.1 Release Candidate:
script src=http://download.dojotoolkit.org/dojo_0.4.1rc2.js;/script
I have not tested this yet.
My hopes are that CForms etc. will be compatible with Dojo 0.4.n very
shortly :)
regards Jeremy
On 6 Dec 2006, at 08:04, Carsten Ziegeler wrote:
I'm wondering if it would be better to use a resource servlet for
serving resources instead of going through the sitemap?
With 2.2 we can mount servlets at mount paths through the dispatcher
servlet. So perhaps this is a way to go? (Just a rough idea)
Carsten
Jeremy Quinn wrote:
Hi Guys
I am trying to get support for the new Upload Progress Bar working in
Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
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
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Next I am trying to get this compiled in, so that it is available for
the 'cocoon-dist-samples' and everything else that may be built from
this distribution.
I have tried to compile this in, but it never becomes available to
the samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know
where to start solving this.
What am I supposed to do ?
Thanks for any suggestions
regards Jeremy
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
smime.p7s
Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
Thanks to everyone who has contributed to this thread and made encouraging noises about documentation :) Meanwhile . On 5 Dec 2006, at 17:38, Jeremy Quinn wrote: When I went to http://localhost:/_cocoon/system/ajax/upload/ status I get this error : java.io.FileNotFoundException: Could not open ServletContext resource [/resource://org/apache/cocoon/ajax/system/sitemap.xmap] Why should it say /resource:// ? (the leading slash is not in the sitemap.) Does anyone know what is going on with this error ? Thanks regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Building changes into the top level sitemap
Hi Guys
I am trying to get support for the new Upload Progress Bar working in
Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
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
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Next I am trying to get this compiled in, so that it is available for
the 'cocoon-dist-samples' and everything else that may be built from
this distribution.
I have tried to compile this in, but it never becomes available to
the samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know
where to start solving this.
What am I supposed to do ?
Thanks for any suggestions
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 13:42, Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. OK, Thanks, I am trying that now . Getting NPEs from org.apache.maven.plugin.war.AbstractWarMojo.unpack (AbstractWarMojo.java:704) now while trying to run $ mvn install or $ mvn package in dists/cocoon-dist-samples/ Trying a complete clean install from scratch. (Why does this happen in such an unpredictable way ?) core/cocoon-webapp/ dists/cocoon-dist-samples/ Neither results in the changes happening to the file at : dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap TBH I find this new build system so deeply opaque, I do not know where to start solving this. Read the Maven Manuals as you've read the Ant one years ago :-) Excuse the mild sarcasm, but I never actually had to read the Ant manual to develop for Cocoon 2.1 :-) Thanks for your reply regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 13:49, Reinhard Poetz wrote:
Jeremy Quinn wrote:
Hi Guys
I am trying to get support for the new Upload Progress Bar working
in Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
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
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Next I am trying to get this compiled in, so that it is available
for the 'cocoon-dist-samples' and everything else that may be
built from this distribution.
I have tried to compile this in, but it never becomes available to
the samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know
where to start solving this.
What am I supposed to do ?
Thanks for any suggestions
One of our problems is that we use the styling resources from
cocoon-webapp. We have to move all styling related things into
cocoon-samples-style-default and use it from all our sample blocks
instead of using the infamous context protocol.
For system resources we should provide a system-resources block.
For now it could be mounted at _cocoon, later we should install a
LinkRewritingTransformer that is aware of blocks.
The idea was that any block could provide a system pipeline. In this
case, the system pipeline is provided by the Ajax Block.
One problem with these changes is, that they are incomptable with
2.1. As we are sharing them across both versions. For this reason I
propose to create a cocoon-forms-samples-22 block that makes use of
blocks and we have the opportunity to tidy up a bit.
AFAICS this is the one and only change required to support Upload
Progress that is not shared by Trunk and Branch.
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 14:04, Daniel Fagerstrom wrote:
Jeremy Quinn skrev:
Hi Guys
I am trying to get support for the new Upload Progress Bar working
in Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
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
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Yes, that should be the place.
Good :)
Next I am trying to get this compiled in, so that it is available
for the 'cocoon-dist-samples' and everything else that may be
built from this distribution.
I have tried to compile this in, but it never becomes available to
the samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know
where to start solving this.
What am I supposed to do ?
First, the dist samples (cocoon-dist-samples, cocoon-dist-
publishing) are really just distribution samples. They just unpack
and package together the cocoon-webapp and samples and
implementations from the various blocks. For development of samples
it would be really inconvenient to work from the dist samples as
you would need to rebuild about the whole trunk after each change.
OK
So what I would recommend to do is to start from the cocoon-webapp
instead and to add (locally) all the block samples you need for
your work, as dependencies to cocoon-webapp. What happens then is
that during startup Cocoon will find all the COB-INF directories
from the block samples from the class path. From here two different
things can happen: if the block is in a jar at the class path, the
COB-INF directory of the block will be unpacked in a blocks/
blockname directory in the temp directory of the servlet
container. If the block is in a class directory (if you devolop in
Eclipse e.g. and your cocoon-webapp depends on another block
project), Cocoon will read directly from the block without any
unpacking.
All this is done by using a new blockcontext protocol that is aware
of the locations of the blocks (see http://marc.theaimsgroup.com/?
l=xml-cocoon-devm=116326232408386w=2).
So the above should hopefully make it easier to work on making the
new stuff functional. After that you can try to compile the dist
samples and see if it works in them as well.
The above described functionality actually make it easier and
faster than ever to develop samples, as you can test them without
any copying or jetty restarts at all in Eclipse. But some
documentation about this would probably not hurt ;)
Documentation would really help.
I have just been working on an established project that is built from
2.2 and I could see the advantages of the new platform.
However, many perceive 2.2 as almost unusable. It clearly is being
used but the procedures are very different from 2.1 . the results
can be completely unpredictable . it will compile one minute and
not the next, this is very off-putting. If the less experienced
developers like myself cannot feel confidant with the build system
for 2.2 what hope do we have of users embracing it?
Sorry this is in no way intended as a personal criticism, merely a
statement of facts as I perceive them.
From my PoV, the areas most urgently in need of documentation are :
A cookbook for how to develop 2.2 (as you describe)
Recipes for starting your own project.
Troubleshooting hint for solving common build problems.
Reading the Maven2 manual as Giacomo suggested, may well help :) but
that still leaves understanding how 2.2 performs it's built using Maven.
Thanks for your reply :)
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 16:25, Reinhard Poetz wrote: Jeremy Quinn wrote: On 5 Dec 2006, at 13:49, Reinhard Poetz wrote: For system resources we should provide a system-resources block. For now it could be mounted at _cocoon, later we should install a LinkRewritingTransformer that is aware of blocks. The idea was that any block could provide a system pipeline. In this case, the system pipeline is provided by the Ajax Block. This shouldn't be a problem because from the Java level POV there is no concept of blocks. Good, that is what I thought. Thanks. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 13:42, Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. Ever since I ran $ mvn install in core/cocoon-webapp/, I cannot get $ mvn package to work in dists/cocoon-dist-samples/. No matter how many times I run it (I also went back and did a complete clean install from root) I get this from the build : [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.war.AbstractWarMojo.unpack (AbstractWarMojo.java:704) at org.apache.maven.plugin.war.AbstractWarMojo.unpackWarToTempDirectory (AbstractWarMojo.java:680) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp (AbstractWarMojo.java:600) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp (AbstractWarMojo.java:379) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCoco onAppAsWebapp(AbstractDeployMojo.java:182) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute (DeployExplodedMojo.java:64) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) And of course I don't have a clue where to start looking . regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
OK, so even though I could not get $ mvn package to run inside the dists/cocoon-dist-samples, I found that the changes to the top-level sitemap from core/cocoon-webapp/ had in fact been added to the sitemap at : dists/cocoon-dist-samples/target/cocoon-samples/ sitemap.xmap I was able to start Jetty in : dists/cocoon-dist-samples When I went to http://localhost:/_cocoon/system/ajax/upload/ status I get this error : java.io.FileNotFoundException: Could not open ServletContext resource [/resource://org/apache/cocoon/ajax/system/sitemap.xmap] Why should it say /resource:// ? (the leading slash is not in the sitemap.) Doing a $ jar -tf dists/cocoon-dist-samples/target/cocoon-samples/WEB- INF/lib/cocoon-ajax-impl-1.0.0-M2-SNAPSHOT.jar I see all of the new stuff that is needed : . . . org/apache/cocoon/ajax/system/i18n/messages.xml org/apache/cocoon/ajax/system/sitemap.xmap org/apache/cocoon/ajax/system/System.JSON.js org/apache/cocoon/ajax/system/System.Upload.js . . . Am I looking in the right place? Thanks regards Jeremy On 5 Dec 2006, at 17:08, Jeremy Quinn wrote: On 5 Dec 2006, at 13:42, Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. Ever since I ran $ mvn install in core/cocoon-webapp/, I cannot get $ mvn package to work in dists/cocoon-dist-samples/. No matter how many times I run it (I also went back and did a complete clean install from root) I get this from the build : smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 17:38, Jeremy Quinn wrote: Am I looking in the right place? OK, so as Jetty starts up, it reports that it loads ~/.m2/repository/ org/apache/cocoon/cocoon-ajax-impl/1.0.0-M2-SNAPSHOT/cocoon-ajax- impl-1.0.0-M2-SNAPSHOT.jar. I can confirm that the system resources I seek exist there too. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Ajaxifying the ImageMap widget
Ciao Gabriele
On 24 Nov 2006, at 18:27, Gabriele Columbro wrote:
Hi devs!
I'm currently working togheter with Luca Morandini on a GIS project
based on Cocoon 2.1.9, of course using the ImageMap [1] widget that
Luca contributed nearly one year ago.
After having developed the whole application (based on Geoserver
[2] as WMS/WFS server and Weblogic 9.2 as appserver) in the plain
old full page refresh mode, we had a sudden requirement change that
forced us to switch to a more buzz-word driven ( Ajax ;-) ) approach.
All went smoothly (ajax=true is almost the only change I needed,
making bosses astonished, thx guys) until I had to make the
imagemap widget value change after am XHR ( i.e. update the src of
the input type=image that represents the map and tells geoserver
how to draw the map). I discovered, in fact, that the ImageMap
widget was never calling the
org/apache/cocoon/forms/formmodel/Form.java#addWidgetUpdate
( org.apache.cocoon.forms.formmodel.Widget)
method, that then triggers the Browser update process.
Once I patched this (of course planning to contribute it, but
waiting for a completely working version) all actions performed on
other widgets *but the map* were correctly reflected on a partial
update on the map (in case its server side state was modified), but
I'm now facing a different problem handling clicks *on* the map:
whereas a full page submit on an input type=image sends two
parameters ( /widgetId.x/ and /widgetId.y/ , i.e. the coordinates
of the mouse click) that are used to recompute map extent, the XHR
is just not sending this parameters (verified with tcpmon), so that
map status does not get modified, and map not redrawn.
I'm stuck as I don't know where to take action, wheter if it's a
dojo framework lack (I'm using the jar that is contained in cocoon
2.1.9, should I try with the latest trunk?), or it's a problem of
the dojo-cocoon js bridge.
It would be great if someone can point me to the right direction,
also because I think that this can be a good (and contributable)
improvement for the imagemap widget to support AJAX, in a web world
where ajax maps are now the standard.
Your problem lies here, I think :
src/blocks/forms/java/org/apache/cocoon/forms/resources/js/common.js
in cocoon.forms.buildQueryString line: 109 :
if (input.type == submit || input.type == image ||
input.type == button) {
// Skip buttons
continue;
}
Your image-type input is not added to the query string.
You could patch this function to output what you need.
Alternatively it is possible call cocoon.forms.CFormsForm.submit
(name, params) directly and pass the 'name' of the submitting control
and extra form parameters in 'params' (an associative array).
This has changed in 2.1.10-dev, as I re-wrote all of this stuff to
add the ability to send XHR via IframeIO if there are file-type
inputs. I threw the buildQueryString function away and use Dojo's
built-in code for assembling the form.
HTH
regards Jeremy
PS. Are you sure this will look good though ? If what you are doing
is just re-centering the map on the new coords, I'd be tempted to
write a Dojo WIdget to handle this itself, give you a smooth scroll
to the new centre (everyone is used to Google Maps etc.) rather than
replace the image using BrowserUpdate. (Just my humble opinion ;))
smime.p7s
Description: S/MIME cryptographic signature
Re: getting started with 2.2
Hi Mark, Thanks for the reply. I recompiled and ran the samples under 1.4 successfully !! So my problems lay in trying to use Java 1.5. Many thanks regards Jeremy PS: These were my steps : $ mvn -Dmaven.test.skip -Dallblocks - Dmaven.war.shieldingclassloader=false clean install $ cd dists/cocoon-dist-samples/ $ mvn clean package $ mvn jetty:run On 25 Nov 2006, at 17:00, Mark Lundquist wrote: On Nov 22, 2006, at 10:25 AM, Jeremy Quinn wrote: Hi Mark So you have the samples running now ? I still cannot .. Is it best to use Java 1.4 or 1.5 I am using 1.5. Hi Jeremy — sorry, didn't see your email 'til just now... 1) Yes, I have samples running; 2) I'm using 1.4 on this machine. cheers, —ml— smime.p7s Description: S/MIME cryptographic signature
Re: getting started with 2.2
Hi Guys On 22 Nov 2006, at 00:22, Daniel Fagerstrom wrote: Mark Lundquist skrev: On Nov 21, 2006, at 12:36 PM, Mark Lundquist wrote: On Nov 21, 2006, at 12:21 PM, Daniel Fagerstrom wrote: Testing again, it happens to me also when I do a mvn package after a mvn clean, if I do a second mvn package it works. Yes, OK... the second time worked. Now then, how do I run the webapp? mvn jetty:run invoked from cocoon-dist-samples yields [INFO] The plugin 'org.apache.maven.plugins:maven-jetty- plugin' does not exist or no valid version could be found thx, —ml— OK... /now/, I've done the following: 1) svn up'd (to get Jeremy's commit that is supposed to fix something or other) It includes a snippet to the pom that makes the jetty:run goal available. 2) maven -Dmaven.test.skip -Dallblocks - Dmaven.war.shieldingclassloader=false install 3) cd dists/cocoon-dist-samples 4) mvn package ...and now, I get the NPE no matter how many times I do mvn package: java.lang.NullPointerException at org.apache.maven.plugin.war.AbstractWarMojo.unpack (AbstractWarMojo.java:704) at org.apache.maven.plugin.war.AbstractWarMojo.unpackWarToTempDirectory( AbstractWarMojo.java:680) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp (AbstractWarMojo.java:600) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp (AbstractWarMojo.java:379) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicC ocoonAppAsWebapp(AbstractDeployMojo.java:182) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute (DeployExplodedMojo.java:64) Don't know why you get that problem. For me it worked after having updating to current and having recompiled. Anyway, the problem lies in the use of the cocoon deployer plugin. And it is not necessary to use that. The only thing it adds IIUC is the shielding classloader that you have turned of anyway. To remove the use of the cocoon deployer you remove the following snippet from the pom for cocoon-dist-samples: plugin groupIdorg.apache.cocoon/groupId artifactIdcocoon-deployer-plugin/artifactId version1.0.0-M2-SNAPSHOT/version configuration serverVersion2.2/serverVersion /configuration executions execution phasepackage/phase goals goaldeploy/goal /goals /execution /executions /plugin OK, I removed this plugin from dists/cocoon-dist-samples/pom.xml ran this from root : $mvn -Dmaven.test.skip -Dallblocks - Dmaven.war.shieldingclassloader=false install and it successfully compiled next I ran this from ists/cocoon-dist-samples/ : $mvn package again, that was successful then : $mvn jetty:run and it fails with : snip/ 2006-11-22 11:51:59.299::INFO: Bound java:comp/env/greeting=Hello, World 2006-11-22 11:52:35.646::WARN: failed [EMAIL PROTECTED]/,file:/ Users/Shared/Development/Checkouts/Apache/Cocoon/Cocoon_2_2/dists/ cocoon-dist-samples/target/cocoon-samples/} 2006-11-22 11:52:35.647::WARN: failed [EMAIL PROTECTED] 2006-11-22 11:52:35.647::WARN: failed [EMAIL PROTECTED] 2006-11-22 11:52:35.660::INFO: Started SelectChannelConnector @ 0.0.0.0: 2006-11-22 11:52:35.661::WARN: failed [EMAIL PROTECTED] [INFO] Jetty server exiting. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.StackOverflowError at java.util.zip.ZipFile.getEntry(ZipFile.java:252) at java.util.jar.JarFile.getEntry(JarFile.java:200) at java.util.jar.JarFile.getJarEntry(JarFile.java:183) at sun.misc.URLClassPath$JarLoader.getResource (URLClassPath.java:674) at sun.misc.URLClassPath.getResource(URLClassPath.java:161) at java.net.URLClassLoader$1.run(URLClassLoader.java:192) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.apache.cocoon.maven.deployer.servlet.ShieldedClassLoader.getClass (ShieldedClassLoader.java:58) at org.apache.cocoon.maven.deployer.servlet.ShieldedClassLoader.loadClass (ShieldedClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.apache.cocoon.maven.deployer.servlet.ShieldingListener.init (ShieldingListener.java:112) at org.apache.cocoon.maven.deployer.servlet.ShieldingListener.contextInitia lized(ShieldingListener.java:202) at org.apache.cocoon.maven.deployer.servlet.ShieldingListener.invoke (ShieldingListener.java:152) snip/ it gets repeated 100's of times [INFO]
Re: getting started with 2.2
Hi On 22 Nov 2006, at 00:22, Daniel Fagerstrom wrote: To remove the use of the cocoon deployer you remove the following snippet from the pom for cocoon-dist-samples: plugin groupIdorg.apache.cocoon/groupId artifactIdcocoon-deployer-plugin/artifactId version1.0.0-M2-SNAPSHOT/version configuration serverVersion2.2/serverVersion /configuration executions execution phasepackage/phase goals goaldeploy/goal /goals /execution /executions /plugin Should this be removed from both modules in /dists/, then committed ? I just tried a clean install with -Dalldists and the cocoon-dist- publishing failed. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
