Hi Thomas,
On 11/30/06, Thomas Fuchs <[EMAIL PROTECTED]> wrote:
>
> Am 29.11.2006 um 22:38 schrieb Peter Michaux:
>
> > I understand the idea of liking one API over another. Fair enough.
> > However, I think that choosing an library because it has a nice API
> > but poor internals is an unfortunate choice.
>
> I take that as an offence.
I hope you don't take it personally. I don't mean any criticism that way.
> Good luck with your libary,
Thanks.
> but please don't FUD around in this group.
The term "FUD" has unfortunately been overused in the Rails world as a
catch all to deflect unwanted criticism. I think this could only be
detrimental to the improvement of Rails, Prototype and Scriptaculous.
To make criticism concrete here are a few examples.
-----------
In the following code snip the first link doesn't work but the second
does. Given the logic for making the second link work is already in
Prototype why not have the first one work too? As far as I remember,
Element.update is in a similar situation and there are other problems
when trying to replace or update a tbody element.
<table>
<tbody id='tableBody'>
<tr id="rowOne"><td>a</td><td>b</td></tr>
<tr><td>c</td><td>c</td></tr>
</tbody>
</table>
<p><a href="#" onclick="Element.replace('rowOne',
'<tr><td>e</td><td>f</td></tr>');return false;">change row</a></p>
<p><a href="#" onclick="new Insertion.Bottom('tableBody',
'<tr><td>y</td><td>z</td></tr>');return false;">insert row</a></p>
----------
I cannot find any match for "dblclick" in Prototype 1.5RC1. What
happens when a developer uses Prototype's event API to attach a
dblclick, doesn't have a Mac with Safari 1.3 and a site user has
Safari 1.3? Is their Prototype documentation warning for this
situation? The more important situation is the click/preventDefault
with Safari and I couldn't find anything for that in Prototype. I have
to do Safari 1.3 testing by phone now so cannot verify these problems
but it doesn't look like Prototype is handling them.
----------
In the following code snip, what happens if the event does not
support.pageX and does support event.clientX but both attempts to get
scrollLeft return null? The scrollLeft value will type convert to zero
and the returned value will be just clientX which will be wrong if the
page has been scrolled.
pointerX: function(event) {
return event.pageX || (event.clientX +
(document.documentElement.scrollLeft || document.body.scrollLeft));
},
It is not necessary to check if event.pageX exists each time this
function is run. Checking just the first time is sufficient. Perhaps
this is just a stylistic bias on my part but this would be a minor
piece in improving performance in a demanding situation like dragdrop
where pointerX() is run frequently.
----------
There are also design decisions like augmenting the Array prototype
which means I cannot safely use Prototype with existing code that uses
a for-in loop on an array.
-----------
You may be able to dismiss some or all of the above criticisms however
I think these are just a few examples that build the case against
Prototype being high quality. There are many other examples like the
ones above. I think Prototype's track record has to be considered.
Because of this track record, by default I now doubt that Prototype
code works until I read and test it carefully myself. I am uncertain
that Prototype will fix all the problems it has (minus the design
decisions). I would be very afraid to launch a mission critical site
using Prototype that was to run on a wide variety of user agents I
don't have.
Peter
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
