[isf-wifidog] Picking an AJAX library for wifidog

Max Horváth max.horvath at maxspot.de
Mer 14 Juin 03:57:57 EDT 2006

Hash: SHA1

Any decision regarding the Ajax library, yet?

And what about the PEAR:HTML_AJAX library?

Cheers, Max!

Max Horváth wrote:

> Hash: SHA1
> I'll support any decision made regarding the AJAX library, as I  
> don't have any experience with any of those libraries ...
> Cheers, Max!
> Rob Janes wrote:
>> First of all, here's some links:
>> Dojo - http://dojotoolkit.org
>> json - http://en.wikipedia.org/wiki/JSON
>> ajaxian - http://www.ajaxian.com
>> prototype - http://prototype.conio.net - there are php libraries  
>> for this, probably mvc
>> scriptaculous - http://script.aculo.us - derivative of prototype
>> mochikit - http://mochikit.com/ - derivative of prototype
>> rico - http://openrico.org - also a derivative of prototype - i've  
>> heard this is buggy
>> Now, here's my two cents.
>> The drag and drop features of prototype would be really nice to  
>> have on the content layout page.  I really dislike the current  
>> form based page.
>> I suspect that my recent checkin of javascripting is what prompted  
>> Benoit to start this thread.  So, I'll explain what I did and try  
>> to separate my stuff from the ajax bandwagon.
>> First of all the prototype library is great, and I am totally on  
>> for that.  I'm actually using it in other projects, so I know of  
>> what I speak when I say that I think it's great.  However, the  
>> prototype library has nothing in it for form usability.  There are  
>> some handy things for forms, like the $F function which really  
>> helps when you don't want to mess with the dom for select form  
>> elements, and Form.getInputs or getElements is really nice for  
>> generic loops and some quick json or query building.  There's also  
>> short cuts for setting the focus field, disabling the entire form,  
>> yada yada yada.  But, all in all we've just traded a standard pure  
>> javascript one liner with cross browser support for a prototype  
>> one liner that might be a bit easier to read, and comes with a  
>> whole bunch of warning messages in the javascript console  
>> (prototype is full of constructs that trigger warning messages).
>> The javascript checkins I put forward were all about form  
>> usability.  Rather than being guided by some misgiven attempt to  
>> fix things right, it was instead driven by complaints by actual  
>> hotspot owners, one in particular, who when turning on the wifidog  
>> gateway was inundated with complaints from customers about the  
>> unusable forms wifidog-auth throws up.  The complaints were fair  
>> and plainly obvious when they were pointed out.
>> Issues pointed out by vendors:
>> * buttons should look like buttons and shouldn't be hard to find.
>> * links that do a button's job should look like buttons.
>> * errors need to look like errors and not loose their context.
>> * login and signup pages need better help text.
>> * navigation help.
>> I'll admit that some of the issues were exacerbated by  
>> customizations we had made earlier.  Throwing in a buggy checkout  
>> from the bleeding edge certainly didn't help.  (mental note:  
>> verify all pages of a new checkout before cutting over).  Setting  
>> those aside, the issues were still there in the stock pages.
>> People seemed to be having trouble with the forms, and traversing  
>> the login/signup and portal redirection process.  The ancilliary  
>> functions of change password, resend validation, i need help, i  
>> forgot my password, i forgot my userid, were confusing and not  
>> especially helpful.  The i need help throws up a faq page that  
>> assumes you already know what you are doing.  We at Wireless  
>> Toronto find that an large number of newcomers never bother to  
>> validate their account.  That seems to strongly suggest by itself  
>> that there are usability problems with the website, let alone the  
>> complaints from the innundated hotspot owners.
>> On the form usability side I'd add
>> * rollover actions where there is an action (lets the user know  
>> something is there)
>> * forms should validate themselves.  Gives immediate contextual help.
>> * form fields in error should get the cursor focus.
>> * links that go to another website should open another window and  
>> not leave the portal page.  Given the lack of navigation aids  
>> throughout the website I think this is important.  Lack of  
>> navigational aids is another point, but not one related to forms.
>> * click actions should have a visible response, always.  I found a  
>> lot of pages gave no notice that anything was done after you  
>> clicked the submit button.
>> The javascripting I did was all about
>> * form navigation
>> * form validation
>> * error messages
>> * navigation
>> There are a few things in prototype and other libraries to help  
>> out with this, but not a lot.  Mostly you replace one set of  
>> problems with another, and a dependency on an external library of  
>> limited support.  In my experience, the above four issues in  
>> environments like ours (non-mvc templating) are always custom  
>> built.  Prototype shines in the mvc environments like ruby on  
>> rails and jsp.  It's strengths are cross browser support, ajax,  
>> asynchronous event handling, and special effects like drag and  
>> drop or nifty magic for making things appear and disappear.   
>> Prototype is all about making (asynchronous) dynamic content  
>> feasible and usable.  Oh - it's also for people who like ruby  
>> style iterators.
>> There is really nothing in prototype for the above four things.
>> Prototype really only makes sense if you have your own dynamic  
>> content, and at this time wifidog-auth doesn't have any of it's  
>> own dynamic content.  Sure, there's the google maps and some rss  
>> stuff, but all this is cookie cutter stuff embedding content and  
>> putting other website servers in the drivers seat.  I mean,  
>> prototype is great, but until wifidog-auth starts off in a new  
>> direction I'd have to say that prototype is of limited utility.
>> -rob
>> François Proulx wrote:
>>> huh ? script.aculo.us in itself provides some cool special  
>>> effects  and some advanced Web UI elements that we might  
>>> consider, but I doubt  Wifidog really needs that, maybe as a  
>>> bonus, but Benoit is asking for  an AJAX framework.
>>> Ideally I would suggest something that is based upon Prototype   
>>> (script.aculo.us already uses it), since it's the most active,  
>>> most  complete, cross browser and efficient library out there,  
>>> but there it  only provides the client side part. There are a few  
>>> good framework  out there, but they are solid state and cannot be  
>>> used sporadically  (Symfony for example is a PHP clone of Ruby on  
>>> Rails and Zephyr is  very similar).
>>> This page lists the PHP frameworks for script.aculo.us
>>> http://wiki.script.aculo.us/scriptaculous/show/IntegrationWithPHP
>>> So there is no out-of-the-box solution for Wifidog, we will  
>>> probably  have to code our own server-side responder, but let's  
>>> make it very  flexible and scalable by abstracting in classes the  
>>> parsing logic. So  one entry point with a few parameters to load  
>>> the appropriate  responding class...
>>> http://prototype.conio.net/
>>> Documentation : http://wiki.script.aculo.us/scriptaculous/show/ 
>>> Prototype
>>> Prototype dissected : http://www.snook.ca/archives/prototype1280.png
>>> The biggest advantage of using Prototype is the richness of its   
>>> client side libraries and it abstracts all common crossbrowser   
>>> problematic calls by choosing the appropriate equivalent.  
>>> Prototype  also enables us to use the Event-Selector library for  
>>> managing very  cleanly Javascript events (click, drag, timer  
>>> etc... on html  elements) using a clever CSS-selectors based system.
>>> http://www.encytemedia.com/event-selectors/
>>> On 24-Apr-2006, at 6:40 PM, Benjamin Crulli wrote:
>>>> Scriptaculous ?
>>>> On 4/24/06, Benoit Grégoire <bock at step.polymtl.ca> wrote:
>>>>> We have to pick one, and only one soon, before UI hacking   
>>>>> degenerates in a
>>>>> mess of libraries and custom implementation.
>>>>> I have no strong opinions on which one to chose.
>>>>> Important factors I can think of:
>>>>> -Good PHP integration
>>>>> -Can be integrated in our class and UI separation properly   
>>>>> (especially when
>>>>> setting up it's responders).
>>>>> -Good documentation
>>>>> -- 
>>>>> Benoit Grégoire, http://benoitg.coeus.ca/
>>>>> _______________________________________________
>>>>> WiFiDog mailing list
>>>>> WiFiDog at listes.ilesansfil.org
>>>>> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>>>> -- 
>>>> Ben Crulli
>>>> _______________________________________________
>>>> WiFiDog mailing list
>>>> WiFiDog at listes.ilesansfil.org
>>>> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>>> _______________________________________________
>>> WiFiDog mailing list
>>> WiFiDog at listes.ilesansfil.org
>>> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>> _______________________________________________
>> WiFiDog mailing list
>> WiFiDog at listes.ilesansfil.org
>> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
> Version: GnuPG v1.4.1 (Darwin)
> iD8DBQFEVQIo+BKgC+eQ3ooRAvVkAJ9x9UQB11N27DKV3zqoNac08XsN+ACdH+vf
> xQrM0YFh9/AD9re2iyZsI4Q=
> =GAm7
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog

Version: GnuPG v1.4.1 (Darwin)


More information about the WiFiDog mailing list