Re: RFC: Ajax Roadmap
On 14 Dec 2005, at 18:22, Sylvain Wallez wrote: Jeremy Quinn wrote: I am stuck, not able to commit at the moment, as the code in Dojo for loading javascripts in the fly, currently has fatal problems on Safari. Jerm, I'm catching up on this, and will have time to dedicate to it starting next week. So I'd be happy to take the ball! Perfect timing Sylvain! I just got some work, starting tomorrow, so I will be a bit busy now. I will do a cleanup and make a diff for you. best regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Ajax Roadmap
Antonio Gallardo wrote: Carsten Ziegeler wrote: I think this global switch is a misconception. Can we change the meaning to: "use ajax if it's enabled in the form *and* if the current browser supports it?" Currently I only have the choice for switching ajax on for *all* users. Now if they happen to have turned off javascript, they simply can't use the form. So I would prefer to have a detection mechanism, if the current browser supports ajax or something like that. AFAIK, we have a detection mechanism at the browser level: http://svn.apache.org/viewcvs.cgi/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/resources/js/cforms.js?view=markup (see the end of the "cocoon.forms.submitForm", at the end we founda comment: "/// Non ajax-aware browser : regular submit" Yep. This handles non-Ajax browsers that have Javascript enable. Browsers with Javascript disabled will not be able to use event-handlers on widgets other than submits. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: RFC: Ajax Roadmap
Jeremy Quinn wrote: I am stuck, not able to commit at the moment, as the code in Dojo for loading javascripts in the fly, currently has fatal problems on Safari. Jerm, I'm catching up on this, and will have time to dedicate to it starting next week. So I'd be happy to take the ball! Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: RFC: Ajax Roadmap
On 13 Dec 2005, at 00:54, Carsten Ziegeler wrote: Ralph Goers wrote: Jeremy Quinn wrote: Hi Ralph On 9 Dec 2005, at 15:06, Ralph Goers wrote: Jeremy Quinn wrote: The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) If there are multiple forms on a page (i.e. in the portal) will multiple copies be loaded? I don't know :) Is there anything in the portal samples I can try this on? I don't know. Carsten has been working on Ajax support. The ajax support in the portal is currently just for the portal itself (reloading of coplets etc.), but not for the portlets itself. (Yes, Ralf I'm mixing coplet and portlet again - like I did in the presentation :( ) The xslt : src/blocks/portal/samples/skins/basic/styles/forms- styling.xsl loads the standard CForms XSLT, so this could work straight off with the new Dojo libs. Would you mind pointing out the other areas where Ajax or CForms is used in the Portal? Now, we could integrate a cforms test tab in the portal. If someone could give me one or two urls for simple forms samples, I can integrate them into the portal and we can see what happens and what has to be done. The 'Car Selector' is probably a good choice as it is a small screen and has Ajax turned on. Another good one may be the 'Registration' sample, again a small form, no Ajax. HTH regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Ajax Roadmap
On 14 Dec 2005, at 11:17, Jean-Baptiste Quenot wrote: Hello Jeremy, Thank you for taking care of integrating Dojo in Cocoon. We are very interested in that, and especially to have the suggestion list working with Dojo and CForms. Do you plan to commit your changes soon? We would be glad to help if we can manage to get into it. Hi Jean-Baptiste, Thanks for interest. I am stuck, not able to commit at the moment, as the code in Dojo for loading javascripts in the fly, currently has fatal problems on Safari. They know about the problem, but we have no solution yet. [1] So, yes, it is rather frustrating, but I imagine there would be hell to pay if I broke CForms for in that browser !! regards Jeremy [1] http://dojotoolkit.org/trac/ticket/236 smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Ajax Roadmap
Hello Jeremy, Thank you for taking care of integrating Dojo in Cocoon. We are very interested in that, and especially to have the suggestion list working with Dojo and CForms. Do you plan to commit your changes soon? We would be glad to help if we can manage to get into it. Thanks in advance, -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/
Re: RFC: Ajax Roadmap
Carsten Ziegeler wrote: I think this global switch is a misconception. Can we change the meaning to: "use ajax if it's enabled in the form *and* if the current browser supports it?" Currently I only have the choice for switching ajax on for *all* users. Now if they happen to have turned off javascript, they simply can't use the form. So I would prefer to have a detection mechanism, if the current browser supports ajax or something like that. AFAIK, we have a detection mechanism at the browser level: http://svn.apache.org/viewcvs.cgi/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/resources/js/cforms.js?view=markup (see the end of the "cocoon.forms.submitForm", at the end we founda comment: "/// Non ajax-aware browser : regular submit"/ / Best Regards, Antonio Gallardo. / Apart from that a general +1 for your ideas. Carsten
Re: RFC: Ajax Roadmap
Carsten Ziegeler wrote: > The ajax support in the portal is currently just for the portal itself > (reloading of coplets etc.), but not for the portlets itself. (Yes, Ralf > I'm mixing coplet and portlet again - like I did in the presentation :( ) > Sorry, I misspelled your name, it should read Ralph of course (Ralf is the german version)...sorry! Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: RFC: Ajax Roadmap
Ralph Goers wrote: > Jeremy Quinn wrote: > > >>Hi Ralph >> >>On 9 Dec 2005, at 15:06, Ralph Goers wrote: >> >> >>>Jeremy Quinn wrote: >>> >>> The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) >>> >>> >>>If there are multiple forms on a page (i.e. in the portal) will >>>multiple copies be loaded? >> >> >> >>I don't know :) >> >>Is there anything in the portal samples I can try this on? >> > > I don't know. Carsten has been working on Ajax support. The ajax support in the portal is currently just for the portal itself (reloading of coplets etc.), but not for the portlets itself. (Yes, Ralf I'm mixing coplet and portlet again - like I did in the presentation :( ) Now, we could integrate a cforms test tab in the portal. If someone could give me one or two urls for simple forms samples, I can integrate them into the portal and we can see what happens and what has to be done. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: RFC: Ajax Roadmap
Jeremy Quinn wrote: > > Refactor Cocoon JS > -- > > forms-lib.js and cforms.js get merged into a new file that will > contain all (non-ajax) CForms-specific code in the following > namespace: cocoon.forms.cforms. > > Any ajax-specific code from the files above and from cocoon-ajax.js > go into a new file in the following namespace: cocoon.ajax.cforms. > This is only loaded by your browser if you have Ajax enabled in your > form. > I think this global switch is a misconception. Can we change the meaning to: "use ajax if it's enabled in the form *and* if the current browser supports it?" Currently I only have the choice for switching ajax on for *all* users. Now if they happen to have turned off javascript, they simply can't use the form. So I would prefer to have a detection mechanism, if the current browser supports ajax or something like that. Apart from that a general +1 for your ideas. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: RFC: Ajax Roadmap
Jeremy Quinn wrote: Hi Ralph On 9 Dec 2005, at 15:06, Ralph Goers wrote: Jeremy Quinn wrote: The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) If there are multiple forms on a page (i.e. in the portal) will multiple copies be loaded? I don't know :) Is there anything in the portal samples I can try this on? I don't know. Carsten has been working on Ajax support. http://svn.apache.org/viewcvs?rev=331752&view=rev http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113152940422930&w=2 http://mail-archives.apache.org/mod_mbox/cocoon-users/200511.mbox/[EMAIL PROTECTED]
Re: RFC: Ajax Roadmap
Hi Antonio, On 9 Dec 2005, at 17:17, Antonio Gallardo wrote: Jeremy Quinn wrote: Hi All I am working on refactoring our CForms Ajax code to use the Dojo Ajax Library. [1] The aim of this is to reduce the amount of cocoon-specific ajax code that needs maintaining by us, to a minimum, while simultaneously adding useful new functionality. The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) This goes for all of the cforms, ajax, mattkruse and htmlarea libs we currently use. This is not working in Safari ATM, so I cannot commit the changes yet unfortunately. I am pretty confidant that it is fixable. [2] So what is the next step? This is what I was thinking, I would appreciate your feedback. Refactor Cocoon JS -- forms-lib.js and cforms.js get merged into a new file that will contain all (non-ajax) CForms-specific code in the following namespace: cocoon.forms.cforms. Can we change the namespace from "cocoon.forms.cforms" to "cocoon.forms"? Any ajax-specific code from the files above and from cocoon- ajax.js go into a new file in the following namespace: cocoon.ajax.cforms. This is only loaded by your browser if you have Ajax enabled in your form. cocoon.ajax.cforms --> cocoon.ajax.forms 3 levels are ok if we will have others "cocoon.ajax." namespaces, if not the case, then "cocoon.ajax" should be enough. Shorter names --> faster typing --> faster development. ;-) Sorry, I cannot help you there :) The namespace works like this : [framework].[block].[file] [] The namespaces are converted into URLs, we need to distinguish between Cocoon and Dojo and between Ajax and Forms Blocks. FormsMultiValueEditor from forms-lib.js goes into it's own file in the namespace : cocoon.ajax.FormsMultiValueEditor. So that it may be loaded only when that widget is displayed. AFAIK, the FormsMultiValueEditor works in non-AJAX mode too. If this is true, then we should not store it under "cocoon.ajax"? Yes, thanks for pointing that out. Here is something interesting, JS allow us to create more complex widgets. The FormsMultiValueEditor is only one of this "complex" widgets. I believe in the future we can have more sofisticated widgets as a widget looking up data from a database and others. If this is really going to happens, then we can create a namespace for them: cocoon.ajax.widget cocoon.forms.widget Hence we can store the FormsMultiValueEditor under: cocoon.forms.widget.FormsMultiValueEditor WDYT? Fine by me. DOMUtils from cocoon-ajax.js either get incorporated into cocoon.ajax.cforms or gets loaded separately in cocoon.ajax.DOMUtils. +1 for cocoon.ajax.DOMUtils Switch to Dojo Libs --- Re-implement our BrowserUpdater(s) using dojo.io.bind. [3] Re-implement our load and submit event handlers using dojo.event.connect. [4] Determine which existing CForms code/widgets etc. may be replaced by their dojo equivalent. Determine which existing CForms code/widgets etc. do not have a dojo equivalent and what to do about it. Determine what widgets there are in dojo, that are not in CForms but may be usefully added to CForms. Determine what widget functionality is available in dojo, but not in CForms that could be added to our widgets (drag and drop repeaters? upload progress bar ? etc.). +1! Thanks Jeremy for taking care of this. :-) Thank /you/ for you useful feedback ;) regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Ajax Roadmap
Hi Ralph
On 9 Dec 2005, at 15:06, Ralph Goers wrote:
Jeremy Quinn wrote:
The first thing I have done is to use the dojo.require mechanism
to dynamically load all JS in the browser, so for instance, if
your form does not use htmlarea, the javascripts are not loaded :)
If there are multiple forms on a page (i.e. in the portal) will
multiple copies be loaded?
I don't know :)
Is there anything in the portal samples I can try this on?
With my changes, forms processed through the built-in cforms xslt now
only load 2 files via script tags :
The first one gets dojo bootstrapped, the second plugs in Cocoon's
namespace to the script loader, so we keep our code separate.
Then the other libs are 'required' as appropriate. eg. these are
always used (these samples are using the 'old' names) :
dojo.require("cocoon.forms.forms-lib");
dojo.require("cocoon.forms.cforms");
or
. . .
dojo.require("cocoon.ajax.cocoon-ajax");
cocoon.forms.ajax = true;
. . .
If the same dojo.require is called several times, only the first one
results in a file actually loading.
HTH
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: RFC: Ajax Roadmap
Jeremy Quinn wrote: Hi All I am working on refactoring our CForms Ajax code to use the Dojo Ajax Library. [1] The aim of this is to reduce the amount of cocoon-specific ajax code that needs maintaining by us, to a minimum, while simultaneously adding useful new functionality. The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) This goes for all of the cforms, ajax, mattkruse and htmlarea libs we currently use. This is not working in Safari ATM, so I cannot commit the changes yet unfortunately. I am pretty confidant that it is fixable. [2] So what is the next step? This is what I was thinking, I would appreciate your feedback. Refactor Cocoon JS -- forms-lib.js and cforms.js get merged into a new file that will contain all (non-ajax) CForms-specific code in the following namespace: cocoon.forms.cforms. Can we change the namespace from "cocoon.forms.cforms" to "cocoon.forms"? Any ajax-specific code from the files above and from cocoon-ajax.js go into a new file in the following namespace: cocoon.ajax.cforms. This is only loaded by your browser if you have Ajax enabled in your form. cocoon.ajax.cforms --> cocoon.ajax.forms 3 levels are ok if we will have others "cocoon.ajax." namespaces, if not the case, then "cocoon.ajax" should be enough. Shorter names --> faster typing --> faster development. ;-) FormsMultiValueEditor from forms-lib.js goes into it's own file in the namespace : cocoon.ajax.FormsMultiValueEditor. So that it may be loaded only when that widget is displayed. AFAIK, the FormsMultiValueEditor works in non-AJAX mode too. If this is true, then we should not store it under "cocoon.ajax"? Here is something interesting, JS allow us to create more complex widgets. The FormsMultiValueEditor is only one of this "complex" widgets. I believe in the future we can have more sofisticated widgets as a widget looking up data from a database and others. If this is really going to happens, then we can create a namespace for them: cocoon.ajax.widget cocoon.forms.widget Hence we can store the FormsMultiValueEditor under: cocoon.forms.widget.FormsMultiValueEditor WDYT? DOMUtils from cocoon-ajax.js either get incorporated into cocoon.ajax.cforms or gets loaded separately in cocoon.ajax.DOMUtils. +1 for cocoon.ajax.DOMUtils Switch to Dojo Libs --- Re-implement our BrowserUpdater(s) using dojo.io.bind. [3] Re-implement our load and submit event handlers using dojo.event.connect. [4] Determine which existing CForms code/widgets etc. may be replaced by their dojo equivalent. Determine which existing CForms code/widgets etc. do not have a dojo equivalent and what to do about it. Determine what widgets there are in dojo, that are not in CForms but may be usefully added to CForms. Determine what widget functionality is available in dojo, but not in CForms that could be added to our widgets (drag and drop repeaters? upload progress bar ? etc.). +1! Thanks Jeremy for taking care of this. :-) Best Regards, Antonio Gallardo.
Re: RFC: Ajax Roadmap
Jeremy Quinn wrote: The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) If there are multiple forms on a page (i.e. in the portal) will multiple copies be loaded? Ralph
Re: RFC: Ajax Roadmap
On 9 Dec 2005, at 12:46, hepabolu wrote: Jeremy Quinn wrote: I am working on refactoring our CForms Ajax code to use the Dojo Ajax Library. [1] GREAT! :) The aim of this is to reduce the amount of cocoon-specific ajax code that needs maintaining by us, to a minimum, while simultaneously adding useful new functionality. +1, will this be available in the 2.1 branch as well or will it be reserved for 2.2? I understood that the Forms Block was shared between the two branches. I am working in 2.1. The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) Great, this has been on my wish list for quite some time. I just hope the Safari problems can be overcome, plus this is not tested at all on Windows yet ;) forms-lib.js and cforms.js get merged into a new file that will contain all (non-ajax) CForms-specific code in the following namespace: cocoon.forms.cforms. +1 Any ajax-specific code from the files above and from cocoon- ajax.js go into a new file in the following namespace: cocoon.ajax.cforms. This is only loaded by your browser if you have Ajax enabled in your form. +1 Are they mutually exclusive? There is a bunch of code to support the background updating of widgets (without page refresh) like adding to or rearranging items in a repeater widget, that is not needed if Ajax is not turned on for the form. There was a thread lately by Antonio about resetting the form/ widget handlers to null, thereby removing the ability for widgets to use AJAX after the first (AJAX) submit. For non-ajax forms that was the correct behaviour IIUC. Yes I read that. I am not completely up to speed on the issues, but would expect to re- visit that when dealing with the events stuff (below). FormsMultiValueEditor from forms-lib.js goes into it's own file in the namespace : cocoon.ajax.FormsMultiValueEditor. So that it may be loaded only when that widget is displayed. +1 DOMUtils from cocoon-ajax.js either get incorporated into cocoon.ajax.cforms or gets loaded separately in cocoon.ajax.DOMUtils. what would be the reason to make it separate? I don't have any strong arguments either way ATM. Re-implement our BrowserUpdater(s) using dojo.io.bind. [3] Re-implement our load and submit event handlers using dojo.event.connect. [4] I cannot figure out the implications for this, but given the goal of minimizing our own ajax code: +1 Determine which existing CForms code/widgets etc. may be replaced by their dojo equivalent. This could include stuff like tabs, help popups, visual effects, trees, date picker, rich text editor etc. Determine which existing CForms code/widgets etc. do not have a dojo equivalent and what to do about it. I am not sure there is a dojo equivalent to our multivalue fields, we may prefer the functionality of our current date picker, rich text editor etc. Determine what widgets there are in dojo, that are not in CForms but may be usefully added to CForms. There are widgets for time picking, colour picking, etc. This I don't understand (due to lack of dojo knowledge). Could you give one example of each? I also probably do not have enough knowledge yet about available dojo widgets either, yet :) But see above. IIUC Dojo is all client-side behaviour of widgets. There is nothing that could replace the server-side, model and binding of CForms. If all this is true, I don't understand the above 3 actions. Some of the behaviours we have in Ajax CForms are purely client-side code, others a mixture of client and server-side. Dojo helps with the client-side in terms of its widget framework but also with stuff like the interaction between client and server, it's powerful event api etc. CForms would continue to work in the same way, i.e. transparently provide the behaviours you turn on in your form. Hopefully the range of behaviours can get richer, while the amount of code for us to maintain gets smaller :) Determine what widget functionality is available in dojo, but not in CForms that could be added to our widgets (drag and drop repeaters? upload progress bar ? etc.). +1 HTH. Thanks for your response. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Ajax Roadmap
Jeremy Quinn wrote: I am working on refactoring our CForms Ajax code to use the Dojo Ajax Library. [1] GREAT! The aim of this is to reduce the amount of cocoon-specific ajax code that needs maintaining by us, to a minimum, while simultaneously adding useful new functionality. +1, will this be available in the 2.1 branch as well or will it be reserved for 2.2? The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) Great, this has been on my wish list for quite some time. forms-lib.js and cforms.js get merged into a new file that will contain all (non-ajax) CForms-specific code in the following namespace: cocoon.forms.cforms. +1 Any ajax-specific code from the files above and from cocoon-ajax.js go into a new file in the following namespace: cocoon.ajax.cforms. This is only loaded by your browser if you have Ajax enabled in your form. +1 Are they mutually exclusive? There was a thread lately by Antonio about resetting the form/widget handlers to null, thereby removing the ability for widgets to use AJAX after the first (AJAX) submit. For non-ajax forms that was the correct behaviour IIUC. FormsMultiValueEditor from forms-lib.js goes into it's own file in the namespace : cocoon.ajax.FormsMultiValueEditor. So that it may be loaded only when that widget is displayed. +1 DOMUtils from cocoon-ajax.js either get incorporated into cocoon.ajax.cforms or gets loaded separately in cocoon.ajax.DOMUtils. what would be the reason to make it separate? Re-implement our BrowserUpdater(s) using dojo.io.bind. [3] Re-implement our load and submit event handlers using dojo.event.connect. [4] I cannot figure out the implications for this, but given the goal of minimizing our own ajax code: +1 Determine which existing CForms code/widgets etc. may be replaced by their dojo equivalent. Determine which existing CForms code/widgets etc. do not have a dojo equivalent and what to do about it. Determine what widgets there are in dojo, that are not in CForms but may be usefully added to CForms. This I don't understand (due to lack of dojo knowledge). Could you give one example of each? IIUC Dojo is all client-side behaviour of widgets. There is nothing that could replace the server-side, model and binding of CForms. If all this is true, I don't understand the above 3 actions. Determine what widget functionality is available in dojo, but not in CForms that could be added to our widgets (drag and drop repeaters? upload progress bar ? etc.). +1 HTH. Bye, Helma
RFC: Ajax Roadmap
Hi All I am working on refactoring our CForms Ajax code to use the Dojo Ajax Library. [1] The aim of this is to reduce the amount of cocoon-specific ajax code that needs maintaining by us, to a minimum, while simultaneously adding useful new functionality. The first thing I have done is to use the dojo.require mechanism to dynamically load all JS in the browser, so for instance, if your form does not use htmlarea, the javascripts are not loaded :) This goes for all of the cforms, ajax, mattkruse and htmlarea libs we currently use. This is not working in Safari ATM, so I cannot commit the changes yet unfortunately. I am pretty confidant that it is fixable. [2] So what is the next step? This is what I was thinking, I would appreciate your feedback. Refactor Cocoon JS -- forms-lib.js and cforms.js get merged into a new file that will contain all (non-ajax) CForms-specific code in the following namespace: cocoon.forms.cforms. Any ajax-specific code from the files above and from cocoon-ajax.js go into a new file in the following namespace: cocoon.ajax.cforms. This is only loaded by your browser if you have Ajax enabled in your form. FormsMultiValueEditor from forms-lib.js goes into it's own file in the namespace : cocoon.ajax.FormsMultiValueEditor. So that it may be loaded only when that widget is displayed. DOMUtils from cocoon-ajax.js either get incorporated into cocoon.ajax.cforms or gets loaded separately in cocoon.ajax.DOMUtils. Switch to Dojo Libs --- Re-implement our BrowserUpdater(s) using dojo.io.bind. [3] Re-implement our load and submit event handlers using dojo.event.connect. [4] Determine which existing CForms code/widgets etc. may be replaced by their dojo equivalent. Determine which existing CForms code/widgets etc. do not have a dojo equivalent and what to do about it. Determine what widgets there are in dojo, that are not in CForms but may be usefully added to CForms. Determine what widget functionality is available in dojo, but not in CForms that could be added to our widgets (drag and drop repeaters? upload progress bar ? etc.). WDYT ? regards Jeremy [1] http://dojotoolkit.org [2] http://dojotoolkit.org/trac/ticket/236 [3] http://dojotoolkit.org/docs/intro_to_dojo_io.html [4] http://dojotoolkit.org/docs/dojo_event_system.html smime.p7s Description: S/MIME cryptographic signature
