[Prototype-core] Re: samples
On 30/01/2008, sharosh [EMAIL PROTECTED] wrote: hi got you hear about prototype from a friend of mine. im a usablity designer so im more intersted in seeing protype in action is there some demo's or samples put up in the website, cas i was trying to find out in the website . i would really apperciate if you can help me with some URLS for the same.. thanks sharosh Prototype is a library. It doesn't DO anything itself. You have to create your own applications. A good example of the use of Prototype is it's sister-in-crime, Scriptaculous. Lot's of demos - http://script.aculo.us/ -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! --~--~-~--~~~---~--~~ 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] samples
hi got you hear about prototype from a friend of mine. im a usablity designer so im more intersted in seeing protype in action is there some demo's or samples put up in the website, cas i was trying to find out in the website . i would really apperciate if you can help me with some URLS for the same.. thanks sharosh --~--~-~--~~~---~--~~ 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: samples
thanks richard for your inputs. scriptacouls has some really amazing works in it sharosh On Jan 30, 3:22 pm, Richard Quadling [EMAIL PROTECTED] wrote: On 30/01/2008, sharosh [EMAIL PROTECTED] wrote: hi got you hear about prototype from a friend of mine. im a usablity designer so im more intersted in seeing protype in action is there somedemo'sor samples put up in the website, cas i was trying to find out in the website . i would really apperciate if you can help me with some URLS for the same.. thanks sharosh Prototype is a library. It doesn't DO anything itself. You have to create your own applications. A good example of the use of Prototype is it's sister-in-crime, Scriptaculous. Lot's of demos -http://script.aculo.us/ -- - Richard Quadling Zend Certified Engineer :http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! --~--~-~--~~~---~--~~ 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: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
And I've managed to misspell Starting in the title (as Staring...) in both posts, ftl. Tobie - what did you mean (in other thread) about doing the work in a closure. Which work were you referring to? On Jan 31, 1:38 am, Tobie Langel [EMAIL PROTECTED] wrote: Just to clarify, I suggested reposting the thread here, not providing a noConflict mode ;) --~--~-~--~~~---~--~~ 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] Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
[As suggested by Tobie - reposted from http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thread/a7edd31205e69472] I've started a path to reimplementing commonly reused global names with a patch (http://dev.rubyonrails.org/ticket/10958) This patch is for $ function. I've giving it the namespace Prototype.upgradeElement, but the actual name is unimportant currently - its very easy to change in my git branch and to recreate the patch. Whilst there are many classes and functions in the global namespace, this patch is a start to give an idea how easy it is to replace the code throughout the src, and ensure the original tests still work (and thus all dependent code will still work). Subsequent patches can fix up other commonly overused variables/ functions, and most importantly, create a noConflict() method to let users manage it at runtime. Cheers Nic --~--~-~--~~~---~--~~ 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: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
Just to clarify, I suggested reposting the thread here, not providing a noConflict mode ;) --~--~-~--~~~---~--~~ 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: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
Well, there's more elegant ways to handle that than converting each and every call to a global than the one you're using. Using a closure could be a solution. Dean's got an interesting system in base2 for that kind of stuff: http://base2.googlecode.com/svn/trunk/src/base2/Package.js Personally, I'm not too fond of namespacing, as imho it just encourages poor coding practices. There's technically no reason afaik (except laziness maybe) to include another framework on top of Prototype (and yes, I know Digg does so - shame on them !). But I'm ready to hear any sound argument in that direction. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
My driving reason is to let jquery developers use unittest for their unit tests as I like it a lot as a test suite. Without noConflict, the jquery app will need to use its noConflict setup, rather than Prototype using its noConflict setup. Fixing prototypes critical namespacing conflicts - the $() - method seemed a solid, clean approach. On Jan 31, 2:12 am, Tobie Langel [EMAIL PROTECTED] wrote: Well, there's more elegant ways to handle that than converting each and every call to a global than the one you're using. Using a closure could be a solution. Dean's got an interesting system in base2 for that kind of stuff:http://base2.googlecode.com/svn/trunk/src/base2/Package.js Personally, I'm not too fond of namespacing, as imho it just encourages poor coding practices. There's technically no reason afaik (except laziness maybe) to include another framework on top of Prototype (and yes, I know Digg does so - shame on them !). But I'm ready to hear any sound argument in that direction. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
Is it worth the extra bloat so that some people can use noConflict? I don't think so, most people never use noConflict. People who want to have multiple frameworks play together should think twice. Maybe that's just me, but I wouldn't want to stimulate people into mixing frameworks. --~--~-~--~~~---~--~~ 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: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
Alternately, can I have permission to make unittest independent of prototype? :P I did look at it _very briefly_ and realised that I just needed to cleanup the use of $. I don't mind Prototype.$ as its namespaced version. Its short and if there is no driving cause for complete refactoring to support inter- library namespacing happiness, then it seems a suitably minimal refactoring. Nic On Jan 31, 2:17 am, Dr Nic [EMAIL PROTECTED] wrote: My driving reason is to let jquery developers use unittest for their unit tests as I like it a lot as a test suite. Without noConflict, the jquery app will need to use its noConflict setup, rather than Prototype using its noConflict setup. Fixing prototypes critical namespacing conflicts - the $() - method seemed a solid, clean approach. On Jan 31, 2:12 am, Tobie Langel [EMAIL PROTECTED] wrote: Well, there's more elegant ways to handle that than converting each and every call to a global than the one you're using. Using a closure could be a solution. Dean's got an interesting system in base2 for that kind of stuff:http://base2.googlecode.com/svn/trunk/src/base2/Package.js Personally, I'm not too fond of namespacing, as imho it just encourages poor coding practices. There's technically no reason afaik (except laziness maybe) to include another framework on top of Prototype (and yes, I know Digg does so - shame on them !). But I'm ready to hear any sound argument in that direction. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
On 30 jan, 17:22, Dr Nic [EMAIL PROTECTED] wrote: Alternately, can I have permission to make unittest independent of prototype? :P I did look at it _very briefly_ and realised that I just needed to cleanup the use of $. If multi framework unittests is what you want, you should have a look at Ext.js adapters. Writing something similar for your unittests is easier then getting every framework to implement noConflict. --~--~-~--~~~---~--~~ 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: methodize parseInt parseFloat
Btw, isn't there a site for sharing such small extensions for prototype? I have lots of them, and I understand most will never make it into prototype core library. I'd like to see it make it into the framework but if I have to add it to extensions.js (my 'extra' methods for prototype) then its not the end of the world. On Jan 30, 2008 1:01 PM, Mislav Marohnić [EMAIL PROTECTED] wrote: On Jan 30, 2008 12:01 AM, Andrew Dupont [EMAIL PROTECTED] wrote: In ECMAScript 4, parseInt and parseFloat are becoming static methods on Number, not on String (i.e., Number.parseInt(3)). I could more easily see adding String#toNumber, but it's not a must-have for me. What do others think? I don't care very much either, that's why I think it's not needed. We have just witnessed how easy it is to add, then why don't leave it to the users who use parseInt/Float extensively? We only use it a couple of times within the framework. -- arty ( http://arty.name ) --~--~-~--~~~---~--~~ 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: methodize parseInt parseFloat
artemy; scripteka! http://scripteka.com/ On Jan 31, 2008 6:34 AM, Artemy Tregoubenko [EMAIL PROTECTED] wrote: Btw, isn't there a site for sharing such small extensions for prototype? I have lots of them, and I understand most will never make it into prototype core library. I'd like to see it make it into the framework but if I have to add it to extensions.js (my 'extra' methods for prototype) then its not the end of the world. On Jan 30, 2008 1:01 PM, Mislav Marohnić [EMAIL PROTECTED] wrote: On Jan 30, 2008 12:01 AM, Andrew Dupont [EMAIL PROTECTED] wrote: In ECMAScript 4, parseInt and parseFloat are becoming static methods on Number, not on String (i.e., Number.parseInt(3)). I could more easily see adding String#toNumber, but it's not a must-have for me. What do others think? I don't care very much either, that's why I think it's not needed. We have just witnessed how easy it is to add, then why don't leave it to the users who use parseInt/Float extensively? We only use it a couple of times within the framework. -- arty ( http://arty.name ) --~--~-~--~~~---~--~~ 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: methodize parseInt parseFloat
thanks for this link, but I thought scripteka was for quite large extensions, while mine are mostly functions less then 10 lines of code artemy; scripteka! http://scripteka.com/ On Jan 31, 2008 6:34 AM, Artemy Tregoubenko [EMAIL PROTECTED] wrote: Btw, isn't there a site for sharing such small extensions for prototype? I have lots of them, and I understand most will never make it into prototype core library. I'd like to see it make it into the framework but if I have to add it to extensions.js (my 'extra' methods for prototype) then its not the end of the world. On Jan 30, 2008 1:01 PM, Mislav Marohnić [EMAIL PROTECTED] wrote: On Jan 30, 2008 12:01 AM, Andrew Dupont [EMAIL PROTECTED] wrote: In ECMAScript 4, parseInt and parseFloat are becoming static methods on Number, not on String (i.e., Number.parseInt(3)). I could more easily see adding String#toNumber, but it's not a must-have for me. What do others think? I don't care very much either, that's why I think it's not needed. We have just witnessed how easy it is to add, then why don't leave it to the users who use parseInt/Float extensively? We only use it a couple of times within the framework. -- arty ( http://arty.name ) -- arty ( http://arty.name ) --~--~-~--~~~---~--~~ 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: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
Lack of namespace management is thing to be fixed, not protected as sacred. Whether its unittest or a widget that needs to coshare JavaScript-land with other widgets built ontop of other frameworks, I think it should be possible, not impossible. Nic On Jan 31, 2:50 am, Nick Stakenburg [EMAIL PROTECTED] wrote: On 30 jan, 17:22, Dr Nic [EMAIL PROTECTED] wrote: Alternately, can I have permission to make unittest independent of prototype? :P I did look at it _very briefly_ and realised that I just needed to cleanup the use of $. If multi framework unittests is what you want, you should have a look at Ext.js adapters. Writing something similar for your unittests is easier then getting every framework to implement noConflict. --~--~-~--~~~---~--~~ 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: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
/is thing to be fixed/is something to be fixed/ sorry On Jan 31, 7:53 am, Dr Nic [EMAIL PROTECTED] wrote: Lack of namespace management is thing to be fixed, not protected as sacred. Whether its unittest or a widget that needs to coshare JavaScript-land with other widgets built ontop of other frameworks, I think it should be possible, not impossible. Nic On Jan 31, 2:50 am, Nick Stakenburg [EMAIL PROTECTED] wrote: On 30 jan, 17:22, Dr Nic [EMAIL PROTECTED] wrote: Alternately, can I have permission to make unittest independent of prototype? :P I did look at it _very briefly_ and realised that I just needed to cleanup the use of $. If multi framework unittests is what you want, you should have a look at Ext.js adapters. Writing something similar for your unittests is easier then getting every framework to implement noConflict. --~--~-~--~~~---~--~~ 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: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
Sure. Handling namespacing inside of the global scope is one issue, and it's pretty simple to deal with... but what about extended prototypes? How am I supposed to know that some other script / lib / framework, hasn't extended Function.prototype.bind with something else, something that would *totally* break Prototype ? What's the point in handling the global scope issue if we're not handling that issue too ? And we all know what that implies. Best, Tobie Dr Nic wrote: Lack of namespace management is thing to be fixed, not protected as sacred. Whether its unittest or a widget that needs to coshare JavaScript-land with other widgets built ontop of other frameworks, I think it should be possible, not impossible. Nic On Jan 31, 2:50 am, Nick Stakenburg [EMAIL PROTECTED] wrote: On 30 jan, 17:22, Dr Nic [EMAIL PROTECTED] wrote: Alternately, can I have permission to make unittest independent of prototype? :P I did look at it _very briefly_ and realised that I just needed to cleanup the use of $. If multi framework unittests is what you want, you should have a look at Ext.js adapters. Writing something similar for your unittests is easier then getting every framework to implement noConflict. --~--~-~--~~~---~--~~ 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: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
Right so there are some frameworks that will never work together, and there are some frameworks that could work together with a little love'n'care to prototypejs. Resolving the every framework has its own $ operator conflict is a big win, and doesn't mean prototype needs to plan to be conpatible/non- conflict with all other libraries. On Jan 31, 8:34 am, Tobie Langel [EMAIL PROTECTED] wrote: Sure. Handling namespacing inside of the global scope is one issue, and it's pretty simple to deal with... but what about extended prototypes? How am I supposed to know that some other script / lib / framework, hasn't extended Function.prototype.bind with something else, something that would *totally* break Prototype ? What's the point in handling the global scope issue if we're not handling that issue too ? And we all know what that implies. Best, Tobie Dr Nic wrote: Lack of namespace management is thing to be fixed, not protected as sacred. Whether its unittest or a widget that needs to coshare JavaScript-land with other widgets built ontop of other frameworks, I think it should be possible, not impossible. Nic On Jan 31, 2:50 am, Nick Stakenburg [EMAIL PROTECTED] wrote: On 30 jan, 17:22, Dr Nic [EMAIL PROTECTED] wrote: Alternately, can I have permission to make unittest independent of prototype? :P I did look at it _very briefly_ and realised that I just needed to cleanup the use of $. If multi framework unittests is what you want, you should have a look at Ext.js adapters. Writing something similar for your unittests is easier then getting every framework to implement noConflict. --~--~-~--~~~---~--~~ 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: methodize parseInt parseFloat
Maybe just put them up on a blog or similar and link people from rails-spinoffs then? I'm quite keen to see what you have. This is definitely not core discussion tho. On Jan 31, 2008 9:49 AM, Artemy Tregoubenko [EMAIL PROTECTED] wrote: thanks for this link, but I thought scripteka was for quite large extensions, while mine are mostly functions less then 10 lines of code artemy; scripteka! http://scripteka.com/ On Jan 31, 2008 6:34 AM, Artemy Tregoubenko [EMAIL PROTECTED] wrote: Btw, isn't there a site for sharing such small extensions for prototype? I have lots of them, and I understand most will never make it into prototype core library. I'd like to see it make it into the framework but if I have to add it to extensions.js (my 'extra' methods for prototype) then its not the end of the world. On Jan 30, 2008 1:01 PM, Mislav Marohnić [EMAIL PROTECTED] wrote: On Jan 30, 2008 12:01 AM, Andrew Dupont [EMAIL PROTECTED] wrote: In ECMAScript 4, parseInt and parseFloat are becoming static methods on Number, not on String (i.e., Number.parseInt(3)). I could more easily see adding String#toNumber, but it's not a must-have for me. What do others think? I don't care very much either, that's why I think it's not needed. We have just witnessed how easy it is to add, then why don't leave it to the users who use parseInt/Float extensively? We only use it a couple of times within the framework. -- arty ( http://arty.name ) -- arty ( http://arty.name ) --~--~-~--~~~---~--~~ 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: protopacked
Hello, Please direct future questions to the email sipplied in the readme_first.txt. If you are referring to the base 62 encoded x_packed.js versions, that appears to be part of Dean Edwards' Packers code and I would not remove it. - JD --~--~-~--~~~---~--~~ 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: protopacked
I really suggest usig the varshrink versions and gzipping them. You get the smallest file size most of the time that way and no clientside delay for js decoding. --~--~-~--~~~---~--~~ 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: Staring noconflict support - putting $() into a namespace [reposted from Spinoffs group]
But it doesn't have to be the $ feature - this can be cleanly noconflict-proofed; giving some useful benefits. I'm still keen to see this refactoring as I think its a Good Thing. On Jan 31, 9:17 am, Tobie Langel [EMAIL PROTECTED] wrote: Right so there are some frameworks that will never work together, and there are some frameworks that could work together with a little love'n'care to prototypejs. The question remains: how will we ever know which ones ? The frameworks which are self contained will always work. The others won't necessarily, and we don't have proper means to test which that. I'd also like to add that, afaik, the only libs concerned by $ are jQuery - which sports a noConflict mode - and mootools, which extends native prototypes about as much as we do - so there would most certainly be conflicts there. I personally don't think it is reasonable to release a feature which, by design, is and always will be incomplete. But that's just my $ .02 and isn't necessarily a view shared by everyone in core. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
