[Prototype-core] Re: Foreach Loops

2008-09-11 Thread Simon Charette
I think you can achieve this with a grep and a match 'factory' in a cleaner
way.

That would be, based on your example:

Type = function(className)
{
   return {match:function(o){return o.className == className}};
}

yourArray.grep(Type('YourProtoClass'), function(obj) { obj.doStuff() });

Correct me if if i'm wrong,

Simon

2008/9/11 EMoreth <[EMAIL PROTECTED]>

>
> Working with prototype from a long time ago I always need a function
> that could do something just like the Strongly Type languages, as Java
> or many others, that is a for ( ObjectClass object in
> arrayLikeStructure ) to get all objects from that array that are from
> the class ObjectClass and do something...
>
> Since Javascript does not have this kind of Typed Class its is very
> hard and annoying to do such thing... I recently tought two ways that
> could make it work...
>
> First (and simpler) is a foreach function that applyes on Enumerable
> items and Accepts two functions.. the first one is a boolean that will
> tell the code when the object is the class/type that I want, and the
> second function should be the action at real... to apply in that
> object. Something like :
>
> myArray.foreach(function(obj){ return obj.className ==
> 'MyProtoClass'}, function(obj) { obj.doStuff() })
>
> The second one is just a little different (more Java-Like)... in this
> case we would need a previous custom method on all objects that would
> say if this one matches a defined parameter or not... something like
>
> a.className = 'MyClass';
> b.className = 'MyProtoClass';
>
> a.isMyObject = function(check) { return this.className == check }
> b.isMyObject = function(check) { return this.className == check }
>
> myArray.foreach( 'MyProtoClass', function(obj) { obj.doStuff() })
>
> and it would only apply on b.doStuff()
>
> I cant tell if this would have the same utility for everyone that
> would have for me... But i thing that would be very good for people
> who are used to other Typed Languages...
>
> Please tell me what you think about that..
>
> EMoreth
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Foreach Loops

2008-09-16 Thread Simon Charette
Sorry Yannick,
but even if I agree with you that findAll().each() is the 'Prototype' way
which i would prefer to the grep method i suggested.
It still creates two iterations while the grep solutions doesn't.

Thats the main reason why i suggested this formula.

2008/9/16 Yanick <[EMAIL PROTECTED]>

>
> I have seen two responses using filter().each() (or grep().each()) and
> I just wanted to say that, IMHO, this is not good practice, and thus
> should not be recommanded as this creates two iterations over the same
> array for the same purpose and encourages bad coding habbits. The
> question is not "would this work?" but rather "is this the best way?"
> The OP must've felt the same way, otherwise he would've used such
> "double sequential loops way" in the first place. In fact, what T.J.
> Crowder suggested is the most Prototype way. I hope we'll all learn
> from this :)
>
> yanick
>
>
> On Sep 15, 12:24 pm, Grant Hutchins <[EMAIL PROTECTED]> wrote:
> > It seems to me that Enumerable#findAll (aliased as select) is what you
> > want for your first example.
> >
> > myArray.findAll( function(obj){ obj.className ==
> > 'MyProtoClass' } ).each( function(obj){ obj.doStuff } );
> >
> > This way you're using the official Prototype way to do these
> > operations.
> >
> > Grant
> >
> > On Sep 11, 6:17 pm, EMoreth <[EMAIL PROTECTED]> wrote:
> >
> > > Working with prototype from a long time ago I always need a function
> > > that could do something just like the Strongly Type languages, as Java
> > > or many others, that is a for ( ObjectClass object in
> > > arrayLikeStructure ) to get all objects from that array that are from
> > > the class ObjectClass and do something...
> >
> > > Since Javascript does not have this kind of Typed Class its is very
> > > hard and annoying to do such thing... I recently tought two ways that
> > > could make it work...
> >
> > > First (and simpler) is a foreach function that applyes on Enumerable
> > > items and Accepts two functions.. the first one is a boolean that will
> > > tell the code when the object is the class/type that I want, and the
> > > second function should be the action at real... to apply in that
> > > object. Something like :
> >
> > > myArray.foreach(function(obj){ return obj.className ==
> > > 'MyProtoClass'}, function(obj) { obj.doStuff() })
> >
> > > The second one is just a little different (more Java-Like)... in this
> > > case we would need a previous custom method on all objects that would
> > > say if this one matches a defined parameter or not... something like
> >
> > > a.className = 'MyClass';
> > > b.className = 'MyProtoClass';
> >
> > > a.isMyObject = function(check) { return this.className == check }
> > > b.isMyObject = function(check) { return this.className == check }
> >
> > > myArray.foreach( 'MyProtoClass', function(obj) { obj.doStuff() })
> >
> > > and it would only apply on b.doStuff()
> >
> > > I cant tell if this would have the same utility for everyone that
> > > would have for me... But i thing that would be very good for people
> > > who are used to other Typed Languages...
> >
> > > Please tell me what you think about that..
> >
> > > EMoreth
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Foreach Loops

2008-09-17 Thread Simon Charette
Oh, I'm not offended at all,
i just wanted to justify the use of this 'non-conventionnal' way
and have some feedback about it.

simon :)


2008/9/17 Yanick <[EMAIL PROTECTED]>

>
> Simon,
> Indeed, I realized that what you suggested didn't imply an each()
> function call thereafter, only after I clicked the 'Send' button.
> (Didn't read the 'match' function in your code.) My apologies. Thus,
> your suggestion is almost as equal as T.J. Crowder's one. (...moving
> on)
>
> A note to clarify; I do not believe that findAll().each() is the
> 'Prototype' way. Or, at least, I don't believe that they were designed
> specifically to work that way. For small size arrays, this may be
> irrelevant, but what I intended to say is that suggesting to
> concatenate two iterative functions to achieve a goal is poor coding
> habbit, regardless of the size of the object being iterated. The
> comment wasn't directed to you specifically, but to those who quickly
> suggest such things (and I see too often poor suggestions being given
> in many forums).
>
> That being said, I'm sorry if I offended you, or anyone in that
> matter.
>
> yanick
>
>
> On Sep 16, 12:08 pm, "Simon Charette" <[EMAIL PROTECTED]> wrote:
> > Sorry Yannick,
> > but even if I agree with you that findAll().each() is the 'Prototype' way
> > which i would prefer to the grep method i suggested.
> > It still creates two iterations while the grep solutions doesn't.
> >
> > Thats the main reason why i suggested this formula.
> >
> > 2008/9/16 Yanick <[EMAIL PROTECTED]>
> >
> >
> >
> > > I have seen two responses using filter().each() (or grep().each()) and
> > > I just wanted to say that, IMHO, this is not good practice, and thus
> > > should not be recommanded as this creates two iterations over the same
> > > array for the same purpose and encourages bad coding habbits. The
> > > question is not "would this work?" but rather "is this the best way?"
> > > The OP must've felt the same way, otherwise he would've used such
> > > "double sequential loops way" in the first place. In fact, what T.J.
> > > Crowder suggested is the most Prototype way. I hope we'll all learn
> > > from this :)
> >
> > > yanick
> >
> > > On Sep 15, 12:24 pm, Grant Hutchins <[EMAIL PROTECTED]> wrote:
> > > > It seems to me that Enumerable#findAll (aliased as select) is what
> you
> > > > want for your first example.
> >
> > > > myArray.findAll( function(obj){ obj.className ==
> > > > 'MyProtoClass' } ).each( function(obj){ obj.doStuff } );
> >
> > > > This way you're using the official Prototype way to do these
> > > > operations.
> >
> > > > Grant
> >
> > > > On Sep 11, 6:17 pm, EMoreth <[EMAIL PROTECTED]> wrote:
> >
> > > > > Working with prototype from a long time ago I always need a
> function
> > > > > that could do something just like the Strongly Type languages, as
> Java
> > > > > or many others, that is a for ( ObjectClass object in
> > > > > arrayLikeStructure ) to get all objects from that array that are
> from
> > > > > the class ObjectClass and do something...
> >
> > > > > Since Javascript does not have this kind of Typed Class its is very
> > > > > hard and annoying to do such thing... I recently tought two ways
> that
> > > > > could make it work...
> >
> > > > > First (and simpler) is a foreach function that applyes on
> Enumerable
> > > > > items and Accepts two functions.. the first one is a boolean that
> will
> > > > > tell the code when the object is the class/type that I want, and
> the
> > > > > second function should be the action at real... to apply in that
> > > > > object. Something like :
> >
> > > > > myArray.foreach(function(obj){ return obj.className ==
> > > > > 'MyProtoClass'}, function(obj) { obj.doStuff() })
> >
> > > > > The second one is just a little different (more Java-Like)... in
> this
> > > > > case we would need a previous custom method on all objects that
> would
> > > > > say if this one matches a defined parameter or not... something
> like
> >
> > > > > a.className = 'MyClass';
> > > > > b.className = '

[Prototype-core] Re: new swap method for elements

2008-09-23 Thread Simon Charette
Using native IE method (swapNode) might help for weird issues in table.

http://msdn.microsoft.com/en-us/library/ms536774(VS.85).aspx

if (element.swapNode) return element.swapNode(secondElement);

2008/9/23 EMoreth <[EMAIL PROTECTED]>

>
> Shouldnt it use the parent node of both elements ??
>
> Cause if i decide to swap 'div1' and 'div2' here ill have no
> nextSibling (assuming that no textNodes would be returned as
> siblings)...
>
> 
>   
>  
>   
>   
>  
>   
> 
>
>
> EMoreth
> On Sep 23, 5:04 pm, kangax <[EMAIL PROTECTED]> wrote:
> > On Sep 23, 11:25 am, John-David Dalton <[EMAIL PROTECTED]>
> > wrote:
> >
> > > @Tag can you provide a case where this would be a real issue ?
> > > I can't see someone swapping nodes with the document.documentElement
> > > or anything.
> >
> > I think `Element.replace` is a good way to ensure no cross-browser
> > bugs crawl in (aren't there glitches with `insertBefore`, table
> > elements and IE?)
> >
> > --
> > kangax
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: update two container by one ajax call

2008-11-21 Thread Simon Charette
Hi,

You'll want to post to the user's group:
http://groups.google.com/group/prototype-scriptaculous

This groups is for core development discussion, not end user
questions.

Simon

2008/11/21 tushersuvro <[EMAIL PROTECTED]>

>
> Hey. Everyone! how r u?
>
> um having trouble in updating two container (ids) in one ajax call.
> the function here I use is protoype's updater function.
>
> Suppose there is two ids
>
> somethinf
>
> there are some code here. there are some code here. there are some
> code here. there are some code here. there are some code here. there
> are some code here. there are some code here. there are some code
> here. there are some code here. there are some code here.
>
> another bunch of code
>
> 
>
> 
> 
>
> 
>
> Now from the if submit button is pressed, two ids in above will be
> updated with two different contents with one ajax call. can it be done
> with prototype?
>
> Thnaks. Tushersuvro
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Prototype in French

2009-01-05 Thread Simon Charette
Well I might be interested to help you translate the doc to french also.

2009/1/5 Christophe Porteneuve 

>
> Sébastien Gruhier a écrit :
> > TTD's book is a great book in
> > French
> http://www.eyrolles.com/Informatique/Livre/bien-developper-pour-le-web-2-0-9782212123913
> > :)
>
> "TDD," man.  Although I'm discontinuing the nickname :-)  Also, the book
> is a great French resource, but in its 2nd edition, which is up-to-date
> on 1.6.0.2 (the first edition was geared towards 1.5.0).
>
> --
> Christophe Porteneuve aka TDD
> t...@tddsworld.com
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Prototype in French

2009-01-06 Thread Simon Charette

Is there a i18n branch planed for protodoc?

2009/1/6, CHARLIER Cyril :
> Hi !
> thanks for your help, I will make a site for this (a wiki).
>
> --
> Cyril Charlier
> cyril.charl...@gmail.com
> --
> Afin de contribuer au respect de l'environnement, merci de n'imprimer cet
> e-mail que si nécessaire
>
>
> On Tue, Jan 6, 2009 at 01:01, Simon Charette  wrote:
>
>> Well I might be interested to help you translate the doc to french also.
>>
>> 2009/1/5 Christophe Porteneuve 
>>
>>
>>> Sébastien Gruhier a écrit :
>>> > TTD's book is a great book in
>>> > French
>>> http://www.eyrolles.com/Informatique/Livre/bien-developper-pour-le-web-2-0-9782212123913
>>> > :)
>>>
>>> "TDD," man.  Although I'm discontinuing the nickname :-)  Also, the book
>>> is a great French resource, but in its 2nd edition, which is up-to-date
>>> on 1.6.0.2 (the first edition was geared towards 1.5.0).
>>>
>>> --
>>> Christophe Porteneuve aka TDD
>>> t...@tddsworld.com
>>>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Growing the community?

2009-01-15 Thread Simon Charette
Don't get me wrong but PUI is more likely an undead atm.

http://github.com/xilinus/prototypeui/network

I've been trying to get in contact with xilinus since last august and I
finally decided to try to push things up with starpeak:  added a Datagrid,
fixed some issues made a spec for a decent release
https://docs.google.com/View?docID=dc5xrvwk_2r6hs36vb&revision=_latest
but never had any feedback and starpeak seems a bit busy atm.

2009/1/15 Yanick 

>
> On Jan 15, 2:28 am, Dan  wrote:
> > [snip]
> > So, what concrete steps can I help with? Some of the things that I'd
> > like to see are:
> >
> > - Make the documentation searchable
> > - Implement developer input within the api documentation website
> > - Add user-submitted code feature, much like Plugins. I know we've got
> > Scripteka, but there really should be something *tied to the prototype
> > site*.
>
> This could be a good idea actually. There are examples already, but
> the PHP API has the user comments too and it's really something great
> when searching for specific problems (even with Google). This could
> attrack more people into using the library (*grin*). Of course, since
> there can be _many_ bad user comments, there should be a validation
> system. I would suggest that users should request a membership instead
> of just anyone posting, and post should be submitted for approval. (I
> would register in such system)
>
> As for the tutorial, readmap and such to help new comers to get
> involved and learn about the best practices and all, there's always
> the prototype irc channel on freenode, and the the other user group
> (spinoff), and the LinkedIn / Facebook groups... If one user wants to
> write his own learning tutorial, no one is keeping him to do so, but I
> don't think that this falls into the hands of the core development.
>
>
> > - Bring all of the various Prototype resources under a single roof:
> > forums, extensions, "plugins", scripty, UI, etc
>
> There is Prototype UI that needs support, they have their own website
> and IRC channel, and all. But this project is and should not be
> dependant of these, IMHO.
>
> > - Add a section devoted to 3rd-party Prototype education: links to hi-
> > quality Prototype-centric blogs, links to and snippets from Prototype/
> > Scripty books, etc.
> >
> > [snip]
> >
> > Thanks,
> > Dan
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Protopacked version bigger than original?

2009-03-20 Thread Simon Charette
You forgot scriptaculous effect.js

On Fri, Mar 20, 2009 at 4:32 PM, wes  wrote:

>
> Am I missing something here?
>
> protoaculous1.6.packed.js is 146Kb
>
> prototype.js (1.6.0.2) is 123Kb and scriptaculous is 3Kb totalling
> 126Kb.
>
> Isn't the packed version supposed to be smaller?
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Form.serialize additional functionality ...

2009-04-16 Thread Simon Charette
var serialized =
$('certain-container').select('input,select,textarea').collect(Form.Element.serialize).join('&');

What do you think of this approach?

2009/4/16 Andrew Dupont 

>
>
>
> On Apr 16, 10:44 am, mr_justin  wrote:
> > Has the topic ever came up to add the ability to serialize elements of
> > a form just but only within a certain container element?
>
> Not as such, no. But we've had thoughts to make the serialization
> logic itself "pluggable." The last time we broached this topic, there
> were heated exchanges about key/value pair serialization, and whether
> the conventions popularized by Rails and PHP were justifiable
> defaults.
>
> Not quite what you're talking about (which I do think is too
> esoteric), but should make your thing easier. No idea when we'll get
> around to that, though. ;-)
>
> Cheers,
> Andrew
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Changing the key of a hashvalue

2009-04-23 Thread Simon Charette
I have trouble figuring out why you would need such a fonctionnality since
hash indexing is based on key value mapping.
It looks like a value reassign to me.

However, if you have the "oldKey" you can get away with that one line
reassign:

hash.update({newKey : hash.get(oldKey)}).unset(oldKey);


Just a snippet in case you dont want to type that line every time:

Hash.prototype.reassign = function(oldKey, newKey){
this.set(newKey, this.get(oldKey));
this.unset(oldKey);
};

Simon
2009/4/23 Benjamin 

>
> Hey guys,
>
> i miss the functionality of changing the key of a hashvalue. Makes
> such a functionality sense, for example in the next prototype version?
>
> greets
> benjamin
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Form.serialize additional functionality ...

2009-04-27 Thread Simon Charette
@bkerley That would work except for non-input form elements.

Imho Dawid Krysiak approach is the most appropriate.

2009/4/27 bker...@gmail.com 

>
> Would this work:
> $$('div#my-div input').invoke('serialize').join('&')
>
> On Apr 17, 2:42 am, mr_justin  wrote:
> >
> > I think it would be darn handy to be able to do this: $('my-
> > form').serialize({within:'my-div'});
> >
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Element.setOpacity have a strange behaviour on prototype 1.6.1RC2

2009-05-13 Thread Simon Charette
Virtual Box is fine.

You should have no problems testing many Windows and linuxes distros.

I've not tried with Mac and you might have to get another virtualisation
tool and get a "Special Version" of Mac OS since
Mr. Jobs doesn't allow Mac software running on non-Mac hardware.

Anyway, thats the tool I used for myself and it works great.

2009/5/13 david 

>
> Hi tobie,
>
> one click install for Window seems good, and it didn't seems to
> complicate after, I just look the documentation in the prototype
> website.
> I just make some research on the net, and i found VirtualBox, for
> testing on different OS version and browser. Is it the good choice, or
> is there a better tool (free of course) ???
>
> thanks,
>
>
> On 13 mai, 15:21, Tobie Langel  wrote:
> > > I will do the unit test but I think I need RoR to do that, so it could
> > > take a couple of days because I did not know Rails.
> >
> > You just need Ruby, which comes bundled with OS 10.5 or is available
> > as a one-click install for Windows.
> >
> > The tests are then just run from the command line.
> >
> > Regarding your initial question, I think there might be legacy
> > versions of FF which had weird issues.
> >
> > Best,
> >
> > tobie
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Element.setOpacity have a strange behaviour on prototype 1.6.1RC2

2009-05-19 Thread Simon Charette
@david You can boot on an .iso to install the oses. Anyway, if you need some
help testing your fork on windows and linuxes browsers let me know.

2009/5/19 Tobie Langel 

>
> Hi David,
>
> You'll need to open a ticket in LH and add your patch to it. Please
> mark it as an enhancement.
>
> Thank you!
>
> Tobie
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Porting JQuery's .live extension to prototype.

2009-05-28 Thread Simon Charette
I can help providing a cross platform test environement if you provide test
cases.

2009/5/28 Radoslav Stankov 

>
> p.p. In several day I will make Event.delegate to be able to watch for
> focus / blur / submit events ( and probably will try to make a good
> patch for Prototype.js but the testing of this thing is really hard
> for me )
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Node List?

2009-07-31 Thread Simon Charette
I don't want to sound rude but what's the point of a jquery'ish prototype?
Isn't it like taking all the javascript sugar out of it?

Can't you get away using jquery in safe mode and prototype?

2009/7/30 Rick Waldron 

> To add a little more information... GenevaJS dynamically redefines all of
> prototype's Element methods to behave like Enumerable methods and comes with
> about 80% of jQuery's methods...
>
>
>
>
> On Thu, Jul 30, 2009 at 3:04 PM, Rick Waldron wrote:
>
>> If you're interested, I've actually built a "bridge" library called
>> GenevaJS that does exactly what you're looking for.
>>
>> Keep in mind, it's not yet finished, but the core concept you're looking
>> for, things like:
>>
>> $('collection').addClassName('classname');
>>
>> Is there.
>>
>> Yes... thats a single $...  GenevaJS modifies the $ to behave like $$
>> (without breaking anything...ever)
>>
>> http://genevajs.com
>>
>> Rick
>>
>>
>>
>>
>> On Thu, Jul 30, 2009 at 2:43 PM, Ken Snyder  wrote:
>>
>>> Mike,
>>>
>>> Yes, that type of class is quite helpful. Here is a concise
>>> implementation of your idea: http://gist.github.com/158849
>>>
>>> It could be improved a lot. For example, you could alter
>>> Element.addMethods() to also add methods to the NodeList object.
>>>
>>> This type of class is probably appropriate for a Scripteka submission,
>>> but there may be other implementations already there.  Feel free to use my
>>> code however you like and submit it if you want.
>>>
>>> Best regards,
>>>
>>> Ken Snyder
>>>
>>>
>>> On Mon, Jul 27, 2009 at 2:53 PM, Mike Rumble wrote:
>>>

 A developer that's recently joined my team is new to Prototype and is
 finding himself trying to do things in a jQuery-ish way, for example:

 $$('.panel').addClassName('red').addClassName('blue');

 I explained the differences between the Prototype and JQuery ways of
 doing things, and demonstrated that the same result could be achieved
 using Prototype with not a great deal more code:

 $$('.panel').invoke('addClassName', 'red').invoke('addClassName',
 'blue');

 At the same time I noticed the NodeList present in the BBC's new Glow
 library (see here:
 http://www.bbc.co.uk/glow/docs/1.5/api/glow.dom.nodelist.shtml
 ), and wondered whether Prototype could benefit of a similar module to
 allow the element methods to be invoked on a collection of DOM nodes
 (the return of $$) and chained together jQuery-style.

 A real basic implementation could look something like this, only less
 lame

 var NodeList = Class.create(Enumerable, {
  initialize : function(elements){
this.elements = elements;
  },
  _each : function(iterator){
this.elements.each(iterator);
  },
  item : function(i){
return this.elements[i];
  }
  addClassName : function(className){
this.elements.invoke('addClassName', className);
return this;
  }
  // More methods here
 });

 I don't think Prototype needs to make itself like jQuery, and I'm not
 looking to start that debate here. I am however interested to hear if
 anyone thinks there is any value in this approach, or indeed if not.

 Personally I think it would do well to make Prototype more accessible
 to newcomers.

 Thanks,
 Mike.




>>>
>>>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: mouseenter and mouseleave events don't fire when an element is resized from under it.

2009-08-26 Thread Simon Charette
Can you provide a test case, it would make it easier to test on our side.

It looks rather like a browser issue due to the way mouse events are handled
than a Prototype problem to me.

2009/8/26 Ngan 

>
> I'm only having problems with mouseleave (mouseenter doesn't concern
> me as much).  If an element is resized to be smaller and the mouse is
> no longer over the element, the element fails to fire a "mouseleave"
> event.  I've tested this in FF 3.5x, Safari 4.0.3, and IE8.  IE8 works
> properly, but FF and Safari does not.
>
> Is this a bug? or how it's suppose to be?
>
> Thanks!
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: mouseenter and mouseleave events don't fire when an element is resized from under it.

2009-08-26 Thread Simon Charette
I see what you mean, however I think this implementation is the correct
behavior according to W3C DOM
Events<http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-MouseEvent>(see
mouseover and mouseout).

The mouseover event occurs when the pointing device is *moved* onto an
> element. This event is valid for most elements.


2009/8/26 Ngan 

>
> I just posted a test script.  Just realized that IE8 fails as well...
> maybe it's just how it is...
>
> 
> 
>  mouseenter/mouseleave test
>  
> 
> function addToConsole(consoleDiv, msg) {
>  msgE = new Element('div');
>  msgE.update(msg);
>  consoleDiv.insert({top: msgE});
> }
> Event.observe(window, 'load', function() {
>  var consoleDiv = $('console');
>  $('test1').observe('mouseenter', function() {
>addToConsole(consoleDiv, 'mouseenter');
>  });
>  $('test1').observe('mouseleave', function() {
>addToConsole(consoleDiv, 'mouseleave');
>  });
>  $('test1').observe('click', function() {
>$('test1').remove();
>  });
> });
> 
> 
> 
>  
>
>  
>
>
>  Mouse Box
>  Click to remove
>
>
>Console:
>
>
>  
>  
>Notes:
>Firefox, IE8, Chrome (Fail):
>
>  Clicking on any part of the mouse box will not fire a
> mouseleave.
>
>Safari (Partial Fail):
>
>  Clicking on "Click to remove" or "Mouse Box" will not
> fire a mouseleave.  However, any other part of the mouse box will fire
> properly.
>
>  
>
>  
> 
> 
>
>
> On Aug 26, 3:01 pm, Simon Charette  wrote:
> > Can you provide a test case, it would make it easier to test on our side.
> >
> > It looks rather like a browser issue due to the way mouse events are
> handled
> > than a Prototype problem to me.
> >
> > 2009/8/26 Ngan 
> >
> >
> >
> >
> >
> > > I'm only having problems with mouseleave (mouseenter doesn't concern
> > > me as much).  If an element is resized to be smaller and the mouse is
> > > no longer over the element, the element fails to fire a "mouseleave"
> > > event.  I've tested this in FF 3.5x, Safari 4.0.3, and IE8.  IE8 works
> > > properly, but FF and Safari does not.
> >
> > > Is this a bug? or how it's suppose to be?
> >
> > > Thanks!
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Memory Leak in IE

2009-10-02 Thread Simon Charette
Element#destroy would definitely be useful. +1

I really think this is a better idea then making a public interface to reach
destroyCache since it resolves into one function call and the learning curve
(making difference between remove and destroy) is smaller since you don't
have to teach developer the whole "EventCache" concept and why they should
call the related function.

Simon

2009/10/2 Mike Rumble 

>
> Ok, good points that I hadn't considered.
>
> However, I would think that many developers will just use Event#remove
> without considering the need to remove the event listeners, which
> could lead to memory leaks.
>
> Maybe an Element#destroy method could fill this gap - remove event
> listeners, remove element from the DOM and then trash it - a
> destructive method for when the developer says "OK, I'm done with this
> element..."
>
> On Oct 2, 9:06 am, Jim Higson  wrote:
> > On Thursday 01 October 2009 21:56:30 Mike Rumble wrote:
> >
> > > You could also encapsulate this in a function wrapping Element#remove,
> > > which IMHO is something Prototype should do out of the box.
> >
> > Quite disagree:
> >
> > * If I remove an element and add it elsewhere, I don't expect its events
> to
> > have been de-registered. The code that moves the element shouldn't have
> to be
> > aware of the (possibly unrelated) code that added the event listeners in
> order
> > to ask it to add them again.
> >
> > * Removing from the document is not the same as allowing to be GC'd
> >
> > * Some elements may never be added to the document. Eg, an XML document
> which
> > you download, manipulate then build some HTML representation of. Perhaps
> you
> > want to monitor for mutations and keep the HTML in sync? [1]
> >
> > Jim
> >
> > [1] Not actually possible in IE or Chrome/Safari but would be nice if it
> were.
> > In Chrome DOM mutation events only fire if the element is in the
> document:
> http://jimhigson.blogspot.com/2009/09/chrome-and-dom-mutation-events
> >
> > --
> > Jim
> > my wiki ajaxification thing:http://wikizzle.org
> > my blog:http://jimhigson.blogspot.com/
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Re: Suggestion: String#isEmpty instead String#empty

2009-10-02 Thread Simon Charette
+1 for renaming both.
2009/10/2 Samuel Lebeau 

> I totally agree.
> `Array#isEmpty` would be useful too.
> Maybe we should rename those methods and deprecate the original names in
> 1.7.
>
> Best,
> Samuel.
>
> 2009/10/2 Allen Madsen 
>
> I'd prefer isEmpty as well.
>> Allen Madsen
>> http://www.allenmadsen.com
>>
>>
>>
>> On Fri, Oct 2, 2009 at 3:34 PM, joneff  wrote:
>>
>>>
>>> I've been pondering on this one for quite a long time -- why is it
>>> String#empty instead of String#isEmpty? To me String.empty should be a
>>> field equal / referencing the empty string and not a method.
>>>
>>> I was gonna hold this to my self, but the last few days there's been
>>> some discussion about semantics (Element#destroy and Function.empty
>>> per say) and I though may be it about time to ask this question.
>>>
>>> So is there any particular reason, besides #empty being shorter than
>>> #isEmpty and does my suggestion make sense to you?
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---



[Prototype-core] Event.relatedElement

2009-12-05 Thread Simon Charette
Hi all, I've been working on fixing issues
#708and
#865while
reducing overhead caused by the current fix for those inconsistencies.

On master branch, IE doesn't pass functional test for mouseleave because we
rely on event.relatedTarget which is not set on the event returned by
Prototype 
(#708).
Another issue is caused by this Firefox < 3.6
bugwhich is
nothandled
correctly  in
the current mouse(enter|leave) simulation implementation
(#865).
(We should *break* in the catch block in order to dispatch the event when we
mouse(over|out) observed element parent scrollbars).

Solving the *detection* part of the mouse(enter|leave) implementation is
easy enough (breaking does it), however patching the XULElement as
relatedTarget in mouse(over|out) one is tricky since the relatedTarget is
readonly and thus cannot be reassigned a correct value. I had a first quick
attempt at this
problembut then
I realised it never really fixed the main issue because
mouse(over|out) events were still able to dispatch erronous relatedTarget.

I came out with what seems to be a viable
solutionthat
introduce a new method to the Event api but reduce the overhead on IE
(_relatedTarget) and wrap the issues in a thin abstraction layer. I also
adapted the functional test and added a new one to test the scrollbar issue
on Firefox.

I'm aware that this solution might cause problems to the few people that
were relying on the* *undocumented addition of the relatedTarget property to
event on IE but IMO performance gains and the fact that this method offers a
way to ensure cross-browser compatibility are worth the introduction of this
method in a future release (1.7+).

Let me know what you guys think.

Simon

ps: The method name could probably be more concise and the documentation
more elaborated, feel free to suggest alternatives.

-- 
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en