Roadmap for 1.6.1 (My take)

[John-David Dalton]

I haven't seen the official roadmap for 1.6.1.
So here is my take on it.

1.6.0.3 was a bug fix release.
I see 1.6.1 as an optimization and new feature/API release.

I see things like:

* Use of documentFragment (Huge IE boost in spots),
* Use of "_each" instead of "each" in places were we can
* Remove the event onunload mechanism for IE (I have a working
prototype of it)
* Avoiding wrapped methods internally (Element.method(element)
instead of element.method())
* Implement "hasOwnProperty" for Safari 2.0.4 (can finally use it in
the rest of the code)
* Make $H(...).include() work properly
* Pass optional conditionals to methods like Element#show,
Element#hide and others)
* Optimize the Template class.
* Make Element#getStyle automatically convert units to px and handle
the "inherit" style.
* Use of Dimensions class
* Create various methods where needed:
- Object.isNodeList()
- Element#isOrphaned
- Element#getNumericStyle [cssToNumber]

* Ajax Fixes:
- Network error fixes
- Timeout added
- Abort added
- Detect when status 0 is allows (when its ftp or file
protocols)

I am sure I missed a few, but the good news is almost all of these
listed features/modifications have already been programmed. We should
be able to create the tickets and unit tests rather fast.

Do yall have anything else to add?
Here is a list of tickets currently marked to be addressed for 1.6.1
(not nessesarily included in 1.6.1)
http://prototype.lighthouseapp.com/projects/8886-prototype/tickets?filter=&page=1&q=state%3Aopen+milestone%3A1.6.1

- JDD

[John-David Dalton]

Also utilizing element.ownerDocument more (this will help in
compatibility with iframes).
Maybe a Element#getDocument(), getBodyElement, getRootElement.

[Ken Snyder]

Is avoiding document.write() for IE dom:loaded included in 1.6.1? I
think the core team concluded that doScroll was the way to go, but I'm
not sure.

What about fixing String#escapeHTML for IE and WebKit?

What about enhancing Element#siblings to accept a selector?
(http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thread/4dd057addb2b0be1/c354acd62c1fbe43?lnk=gst&q=siblings+check#c354acd62c1fbe43)

What are the thoughts on adding an Object.isEmpty or
Object.hasProperties? (http://dev.rubyonrails.org/ticket/10356)

Thanks,

- Ken

[kangax]

+1 for hasProperties/isEmpty
I would also want to see #setProperty.

Ken, which #escapeHTML fix are you talking about? We actually made few
changes in a current trunk.

Besides what was mentioned:

- deprecate Try.these
- deprecate Array#reduce (for compatibility with FF3+)
- update String#isJSON

-- kangax

On Jul 2, 4:34 pm, Ken Snyder <kendsny...@gmail.com> wrote:
> Is avoiding document.write() for IE dom:loaded included in 1.6.1? I
> think the core team concluded that doScroll was the way to go, but I'm
> not sure.
>
> What about fixing String#escapeHTML for IE and WebKit?
>
> What about enhancing Element#siblings to accept a selector?

> (http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thr...)

> >http://prototype.lighthouseapp.com/projects/8886-prototype/tickets?fi...
>
> > - JDD

[Gareth Evans]

Automagical stopObserving on update/remove?

 

Event delegation modification in core (so you can attach delegated events to observe instead of having to write the same document.observe pattern with a series of if-s and element.match(cssSelector)?

Gareth

[John-David Dalton]

@Gareth Evans

* 1.6.0.3 will automagically stopObserving on Element#update.
Element#remove doesn't automate this because you could keep a
reference to the element.
In 1.6.1 it might be a non issue because the Event system may
avoid the memoryleak issue alltogeather
and not have to worry about stopObserving().

* Is element.match just a renaming of element.select?

* Event delegation FTW :) (jQuery will soon have it too)


@Ken Snyder

* 1.6.0.3 has fixed IE and WebKits escapeHTML/unescapeHTML to be as
fully featured as Firefoxes and others.

* 1.6.0.3 has replaced the document.write for IE dom loaded
detection with doScroll

* I dig Object.isEmpty, I don't like the "hasProperties" name
because it may have methods or something.

* I believe Juriy has mentioned having optional conditionals for
Element methods I could see that being
similar to an optional selector :)

- JDD

[Gareth Evans]

element.match is a boolean operator that tells you if a given element matches a css selector.

so if you're observing document.click (delegation) and you want to know if the element was clicked was a particular one...

 

(this is not an actual example)

if(e.element().match('div.fieldset div.subfield input'))

{

//input inside subfield inside fieldset was clicked

[Ken Snyder]

Yes, those escapeHTML fixes are what I was thinking.

I'm excited to see Event delegation!

Also, I wanted to suggest some more ways to extend and customize Prototype:

Event.addMethods to allow adding methods to Event instances (http://prototype.lighthouseapp.com/projects/8886-prototype/tickets/203)

Class.addMethods to allow adding methods to every class instance for classes created with Class.create() (http://dev.rubyonrails.org/ticket/10089)

Enumerable.addMethods as a quick way to add methods to all enumerables:

Enumerable.addMethods = function(methods) { 
  Hash.addMethods(methods); 
  ObjectRange.addMethods(methods); 
  Object.extend(Ajax.Responders, methods); 
  Object.extend(Array.prototype, methods); 
  Element.ClassNames.addMethods(methods); // i think this is deprecated now
};

- Ken

[kangax]

All good additions, Ken.

Regarding Enumerables, we were actually considering a late-bound mixin
implementation. If we were to use such pattern, any objects that mix
Enumerable in, would automagically have methods that are added to
Enumerable later on. That would obviously work for any other mixin as
well.

I made a Class additions draft some time ago:

- Static methods should allow inheritance (Class.extend (?))
- Mixin methods should allow inheritance (Class.include (?))
- Object.isClass
- Callbacks (object:initialized, method:added, method:inherited, etc.)
- Context-safe constructors. new Person() === Person(); (turn on/off:
Class.CONTEXT_SAFE = true)
- Sugar: Class.getInstanceMethods (Object.keys of
constructor.prototype), Class.getClassMethods (Object.keys of
constructor)
- Late bound mixin methods (maybe to be able to specify early/late
when adding)

-- kangax

On Jul 3, 12:31 am, "Ken Snyder" <kendsny...@gmail.com> wrote:
> Yes, those escapeHTML fixes are what I was thinking.
>
> I'm excited to see Event delegation!
>
> Also, I wanted to suggest some more ways to extend and customize Prototype:
>

> *Event.addMethods* to allow adding methods to Event instances (http://prototype.lighthouseapp.com/projects/8886-prototype/tickets/203)
>
> *Class.addMethods* to allow adding methods to every class instance for

> classes created with Class.create() (http://dev.rubyonrails.org/ticket/10089
> )
>

> *Enumerable.addMethods* as a quick way to add methods to all enumerables:

[Viktor Kojouharov]

Ken, wouldn't Enumerable.addMethods be just a wrapper around
Class.addMethods? Like Class.addMethods(Enumerable, methods)

On Jul 3, 7:31 am, "Ken Snyder" <kendsny...@gmail.com> wrote:
> Yes, those escapeHTML fixes are what I was thinking.
>
> I'm excited to see Event delegation!
>
> Also, I wanted to suggest some more ways to extend and customize Prototype:
>

> *Event.addMethods* to allow adding methods to Event instances (http://prototype.lighthouseapp.com/projects/8886-prototype/tickets/203)
>
> *Class.addMethods* to allow adding methods to every class instance for

> classes created with Class.create() (http://dev.rubyonrails.org/ticket/10089
> )
>

> *Enumerable.addMethods* as a quick way to add methods to all enumerables:

[Ken Snyder]

Viktor Kojouharov wrote:
> Ken, wouldn't Enumerable.addMethods be just a wrapper around
> Class.addMethods? Like Class.addMethods(Enumerable, methods)
>
>

No because Enumerable is not a class, it is a mixin or collection of
methods. Adding methods to or extending the Enumerable mixin leaves
Hash.prototype and Array.prototype without those methods.

I am interested to see kangax's late-bound mixin implementation. That
sounds like multiple inheritance to me :)

- Ken

[Nick Stakenburg]

I'll throw in some things:

* mouse(enter|leave) events: Would be a big plus. I don't like the
idea that Prototype authors have to write up hacks while other
frameworks have had this available in core for some time now. If this
is added using custom events it will require
* Firing non-bubbling events with Event#fire
* Recursive Object.extend: Could be useful, http://dev.rubyonrails.org/ticket/11089
* Revisiting unit tests on dimensions and position: It seems like
these parts of the code are always in flux, there are still issues
that are not addressed. More unit tests will help to get these parts
stable, those could go hand in hand with the Dimensions class.

- Nick

On 2 jul, 20:19, John-David Dalton <John.David.Dal...@gmail.com>
wrote:

> (not nessesarily included in 1.6.1)http://prototype.lighthouseapp.com/projects/8886-prototype/tickets?fi...
>
> - JDD

[Ignacio Coloma]

Any thoughts about a script.aculo.us 2 roadmap?

Maybe this is not the place to ask, but I had to try...

[Namotco]

I don't have anything specific that I'd like to see in Prototype. The
event delegation sounds excellent! I'm happy it will fix the memory
leak that's been plaguing me because of it.
My general feeling is that we should implement some new features that
get developers excited about Prototype. The new browsers are
introducing many new technologies and it would be great to expand this
framework into that piece of the future (DOM storage, HTML5,
webforms2, etc).

Additionally, scriptaculous2 is called "scripty". I'm not sure what
the road map is, but I'd like to see it take advantage of the new
browsers just the same by implementing CSS3 Transitions for example.

There are many new things to learn with FF3, IE8, new Opera, and
WebKit. It would be great to have 1 framework that brought us the
advantages of all those great new things. Maybe that's better for a
1.7 or 1.8 since it's slightly ambitious.

Oh, also, does anyone know where I galleries of busty teens? Is this
list being moved like the other one?

[John Resig]

Looks like a great focus here, kudos.

I wanted to bring up one point: we at the jQuery project have had a
long-standing policy of not releasing library speed comparison
numbers. It looks like you're shooting for some performance
optimizations here so you'll be forced to make a similar decision.

We've found that public multi-library comparisons just lead to
needless bickering and frustration, especially when only one author
controls the tests. Now private comparisons - or tests that've been
mutually agreed upon - are absolutely fine. Competition is healthy and
everyone benefits from the result.

I'd just like to ask that if any comparison tests are created that we
be contacted and be given, at least, some lead time. We will be happy
to do the same for you, should the situation ever arrise.

Happy hacking!

--John

On Jul 2, 2:19 pm, John-David Dalton <John.David.Dal...@gmail.com>
wrote:

> (not nessesarily included in 1.6.1)http://prototype.lighthouseapp.com/projects/8886-prototype/tickets?fi...
>
> - JDD

[kangax]

On Jul 24, 3:23 pm, John Resig <jere...@gmail.com> wrote:
> Looks like a great focus here, kudos.
>
> I wanted to bring up one point: we at the jQuery project have had a
> long-standing policy of not releasing library speed comparison
> numbers. It looks like you're shooting for some performance
> optimizations here so you'll be forced to make a similar decision.
>
> We've found that public multi-library comparisons just lead to
> needless bickering and frustration, especially when only one author
> controls the tests. Now private comparisons - or tests that've been
> mutually agreed upon - are absolutely fine. Competition is healthy and
> everyone benefits from the result.
>
> I'd just like to ask that if any comparison tests are created that we
> be contacted and be given, at least, some lead time. We will be happy
> to do the same for you, should the situation ever arrise.
>
> Happy hacking!

John,

Any speed comparisons are usually performed against previous revisions
of prototype.js, not other libraries.
Those are the most relevant results.

Does jQuery not reveal any tests at all, or is it multi-library
comparison you're talking about?

Best,
--
kangax

[John Resig]

> Any speed comparisons are usually performed against previous revisions
> of prototype.js, not other libraries.
> Those are the most relevant results.

Agreed completely - this is good to hear.

> Does jQuery not reveal any tests at all, or is it multi-library
> comparison you're talking about?

We reveal all performance tests when we publish associated numbers -
we don't reveal any multi-library comparisons. If we were ever to
consider such a move we would bring it up for discussion with the
other libraries first and ask them to approve the tests, to make sure
they were equitable (and give them time to appropriately respond).

--John

[Ryan Johnson]

Little late but wanted to reply to kangax's proposals:

+1 : Static methods should allow inheritance (Class.extend (?))
+1 : Mixin methods should allow inheritance (Class.include (?))
+1 - Object.isClass
neutral - Callbacks (object:initialized, method:added,
method:inherited, etc.)
-1 : Context-safe constructors. new Person() === Person(); (turn on/
off:
Class.CONTEXT_SAFE = true)
+1 : Sugar: Class.getInstanceMethods (Object.keys of

constructor.prototype), Class.getClassMethods (Object.keys of
constructor)

-1 : Late bound mixin methods (maybe to be able to specify early/late
when adding)

With context safe constructors you should always have to use the "new"
keyword.

With late bound mixin methods, my gut reaction is that this is a
little too much magic and has the potential for a lot of unintended
consequences.

With the regards to the callbacks, there should be a mechanism to add
this, but it should not happen automatically.

[John-David Dalton]

Here is a little update.
I have created tickets and patches for the following items:

* Use of documentFragment,

* Use of "_each" instead of "each" in places were we can
* Remove the event onunload mechanism for IE

* Implement "hasOwnProperty" for Safari 2.0.4 (can finally use it in

* Object.isEmpty() [links to kens ticket]

Items not originally listed but added:
* Optimization for $A
* Optimization for Object.isArray
* Fix for Element#adjacent (limits the css selector to the elements
siblings)

Currently working on understanding the gutts of the Templat class
* Optimize the Template class (by Mathias).

- JDD

[Christophe Porteneuve]

John-David Dalton a écrit :

> Currently working on understanding the gutts of the Templat class
> * Optimize the Template class (by Mathias).

I wrote the current version, if you need help, ping me :-)

--
Christophe Porteneuve aka TDD
t...@tddsworld.com

[Matt Foster]

Hey Guys,

I've put together an article on the Ajax Request timeout
functionality. Including working demo and clearly denoted changes to
the code. I've also talked about some different variations that we
should consider. Its currently working well in IE and FF.

http://positionabsolute.net/blog/2008/07/prototype-ajax-request-timeout.php

Regards,
Matt

[John-David Dalton]

@Matt Foster -
I think Prado (PHP Framework, which uses Prototype as its core
clientside),
also extends it to support timeouts, and aborting requests on ajax
calls.
Here is there source:
http://www.protolific.net/ajax3.js

- JDD

[Matt Foster]

Very interesting code on that link, although it is dependent on a lot
of the Prado framework. I don't think it could be used as a viable
option for the "road map". I have refactored Ajax.Request in my
article, not extended it. I am trying to keep my changes as minimal as
possible and am currently reworking my first attempt based on Tobie's
suggestion for a more desirable behavior model. Please take a look at
the article when you have a moment I would appreciate your feedback.
I have posed quite a few questions which are pertinent to how the
timeout behavior should flow and your input would be valuable.

Cheers,
Matt

On Aug 8, 1:21 pm, John-David Dalton <John.David.Dal...@gmail.com>
wrote: