Heya all,
I made an enhancement to the feedback module, in an unobtrusive way, and that degrades gracefully.
Unfortunately I don't have time to format it as a proper patch, so I'm sending you here the mods, hoping somebody will put that in the right form :)
here are the things needed:
prototype.js is needed (http://prototype.conio.net/),
scrip.aculo.us libraries (http://script.aculo.us) are recommended for the Effects.Appear to work.
prototype.js is bunled as part of script.aculo.us
behaviour.js (http://www.ripcord.co.nz/behaviour/) is recommended to add gracefully and unobtrusively the functions to window.onload
You can see a demo at:
http://development.mindblaze.net/index.php?q=en/feedback
the file attached is NOT A PATCH, it's a text file with the mods described.
| Comment | File | Size | Author |
|---|---|---|---|
| feedback_ajaxed.txt | 3.25 KB | astroboy |
Comments
Comment #1
kbahey commentedWhat is missing from your description is how Ajax would help here?
Ajax is cool and all, but what added functionality does it get us when incorporated in feedback?
The only thing I can think of, is to disable the Send button until we get all valid input. Anything else?
Also, please take some time to check the licenses of the js parts that are needed. They have to be GPL.
Without a working patch, it is too much demand on my time to test it.
This is not to say that this is not useful, or belittle your contribution, but we need a whole picture before we can move on and decide whether it goes into the standard release or not.
Thanks
Comment #2
kbahey commentedAs explained in my earlier comment.
Comment #3
astroboy commentedI completely understand these points, and taken no offence; I'll answer in order:
Added functionnality is enhanced/snappier user experience while being unobtrusive and requiring minimal to none modifications to the existing structure, and above all, no inline javascript or whatsoever, thus achieving enhanced functionnality without sacrificing coding style nor "degraded" (read standard) user experience.
Main benefit is: No reloading of pages, and on some user-heavy sites, drupal can be slow to output a page : when you get the form right from the first time, this is a minimal gain, but if you make mistakes submitting the form, and have to fill it again, and eventually twice, this can be frustrating.
Forms and server-side validation IMHO are the one component on the web that frustrate users and can benefit from asynchronous updates, because they have to eventually fill some info and then correct, and even sometimes, re-type some info that's already been typed.
Secondary benefit would be: This could also be the foundation to a realtime server-side validation of the forms (more secure and flexible than client-side only javascript, because it still would work on javascript-disabled browsers, with one set of rules and one implementation).
The licenses:
Prototype.js :
Behaviour.js:
BSD Licensed
Script.aculo.us:
"MIT-style license"
On a broader spectrum, I think that these libraries would be the magic bullet to almost all drupal js needs, instead of building drupal specific js, and having them duplicate the functionnality of these libraries, (I already have to use both on my test installation).
But this is out of the scope of this discussion
Lastly, I'll try and take the time to make a patch.
Comment #4
kbahey commentedFirst, "snappier" and "enhanced" and such descriptions are really subjective and cannot be quantified.
So, to summarize, the only benefit is to validate data on the fly, and not having to reload the page. Is this justified for such a simple and infrequently used module (by the average user on a site. I mean how many times will they use it?)
Second, why not do so with standard javascript that is part of HEAD (and soon to be in 4.7) rather than each module requiring its own set of JS functions? Has this option been explored?
Finally, for licenses, I am not a lawyer, and do not have the time to be one. So I cannot tell if these licenses are GPL compatible or not, as per FSF rules.
So, someone else has to do the homework on this part (licensing compatibility), and come with a conclusion of Yes or No, and why s/he came to that conclusion, with backing from FSF web site on compatibility or not.
Comment #5
sunDevelopment on Feedback module v1.x has ended. Beginning from 2.x, the Feedback module has been replaced with a completely different module with a different purpose. Please note that Feedback 2.x is not compatible with 1.x. See #279636: Turn Feedback into user feedback module for further information.
There will be a final 5.x-1.1 release with all existing and tested patches in the issue queue applied. If you need the functionality of the Feedback 1.x module, the Contact module in Drupal core as well as the contributed Webform module are recommended replacements. However, there is no migration path to those modules.
Marking as won't fix.