[isf-wifidog] Picking an AJAX library for wifidog
Max Horváth
max.horvath at maxspot.de
Mer 14 Juin 03:57:57 EDT 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Any decision regarding the Ajax library, yet?
And what about the PEAR:HTML_AJAX library?
Cheers, Max!
Max Horváth wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>
> iD8DBQFEVQIo+BKgC+eQ3ooRAvVkAJ9x9UQB11N27DKV3zqoNac08XsN+ACdH+vf
> xQrM0YFh9/AD9re2iyZsI4Q=
> =GAm7
> -----END PGP SIGNATURE-----
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFEj8GF+BKgC+eQ3ooRAj1HAJ9BuGp+2gil+Sa0wRRTI6vudH0MnwCgjKsm
AbJeS6skx0iv8V/mKB0s/Gs=
=DJhY
-----END PGP SIGNATURE-----
More information about the WiFiDog
mailing list