[isf-wifidog] Picking an AJAX library for wifidog

Max Horváth max.horvath at maxspot.de
Dim 30 Avr 14:29:59 EDT 2006

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)


More information about the WiFiDog mailing list