Antonio Gallardo wrote:
Hi:
Simply, wow, it is great! :-)
Thanks :-)
(stupid Struts people that think the whole world reads their articles and mailing lists)
I started to do something similar 4 days before you posted this solution!
My main motivation was because repeater widget with comboboxes are very slow in 2.1.x. I saw a browser waiting around 2 minutes to show a form because the repeater data. The all form was +100kB! Of course, this was an unusable solution. Then we thought that a solution was break the form in more pieces, but this looked very ugly from a user POV.
At that time, Tim Larson advised to look for an XmlHttpRequest solution integrated into cforms. The same day, I saw an struts related article in the theserverside:
http://theserverside.com/news/thread.tss?thread_id=33056
And I started to migrate this to cocoon in my free time. But with no major success. :-(
I think, your solution is more elegant than what I tried to do. My idea was to generate client-side java script for every widget and send it to the browser, then the browser will react to the onfocus event of the widget and fill the list on demand. That way we don't need to fill all the lists at once and the page will load faster. I expected cocoon caching will help here.
Also, given the fact that this solution was not needed on every combo, I
thought to include an @ajax attribute in the "fi" namespace on the
template as flag. Something similiar like I saw in the struts sample
pointed above. Not at the form level as the committed solution.
The current solution makes Ajax totally transparent and is suitable for most cases and requires no specific client-side JS, but is not the most optimal for some frequent use cases such as populating dropdowns.
So a second phase of Ajax-in-Cocoon is to write some "ajax-aware" stylings, that provide some finer-grained updates or some additional behaviour. And these styling will be triggered as usual in <fi:styling>, e.g. <fi:styling type="ajax-dropdown">
I have 2 questions:
1- Will this ajax implementation improve the combo loads in cforms?
What do you mean by "combo loads"? If this is changing selection lists, then it already does it (see the carselector). If it's lazily populating dropdowns when the user clicks on them, this should be part of the second phased described above.
2- Are you planning to merge it in 2.1.x? If not I will see the urge to
move to 2.2 soon! :-D
Yes, sure this will go to 2.1.x. It's currently in 2.2 only as I wanted to gather people's feeback on this original approach.
Thanks for this great improvement!
Thanks :-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
