[Prototype-core] Re: features request
Here is the Scriptaculous.require method ...
var Scriptaculous = {
Version: '1.8.0',
require: function(libraryName) {
// inserting via DOM fails in Safari 2.0, so brute force approach
document.write('script type=text/javascript
src='+libraryName+'\/script');
},
Notice the comment? I'm not in a position to test this (I don't have Safari).
On 22/11/2007, tbela99 [EMAIL PROTECTED] wrote:
Hello Mr Ken,
you did not understand me very well, i do the same thing as you do,
merging many javascript and css files into single files to optimize
resources. but i do not merge all files at once. as user need, i may
dynamically load one or many optimized file, and this does not require
XMLHTTPRequest, just setting up a script or link correctly and
push it into the head section, this make the browser load the file.
function loadScript(src) {
myScript = document.createElement('SCRIPT');
myScript.src = url
my.type = 'text/javascript';
...
}
after that, you just insert the script into the head section of the
page. you can do the same for css with the link element. additionnaly
you may add a way to set up a callback function that control the
loading state.
-- best regards --
--
-
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: features request
I've made a ticket with an attached patch that adds a script insertion
method a few months ago, right here:
http://dev.rubyonrails.org/ticket/9871
I also believe that this method works with Safari 2 (It works with
Konqueror). And so far, It has worked very well for me.
On Nov 22, 11:56 am, Richard Quadling [EMAIL PROTECTED]
wrote:
Here is the Scriptaculous.require method ...
var Scriptaculous = {
Version: '1.8.0',
require: function(libraryName) {
// inserting via DOM fails in Safari 2.0, so brute force approach
document.write('script type=text/javascript
src='+libraryName+'\/script');
},
Notice the comment? I'm not in a position to test this (I don't have Safari).
On 22/11/2007, tbela99 [EMAIL PROTECTED] wrote:
Hello Mr Ken,
you did not understand me very well, i do the same thing as you do,
merging many javascript and css files into single files to optimize
resources. but i do not merge all files at once. as user need, i may
dynamically load one or many optimized file, and this does not require
XMLHTTPRequest, just setting up a script or link correctly and
push it into the head section, this make the browser load the file.
function loadScript(src) {
myScript = document.createElement('SCRIPT');
myScript.src = url
my.type = 'text/javascript';
...
}
after that, you just insert the script into the head section of the
page. you can do the same for css with the link element. additionnaly
you may add a way to set up a callback function that control the
loading state.
-- best regards --
--
-
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: features request
On Nov 22, 2007 11:57 AM, Viktor Kojouharov [EMAIL PROTECTED] wrote: I've made a ticket with an attached patch that adds a script insertion method a few months ago, right here: http://dev.rubyonrails.org/ticket/9871 Whoa, that's a lot of code. I think the problem with this sort of functionality being in core is that a lot of people have different requirements for their apps and also optimize their code and asset files differently. We must take into account that most of our users might not use the feature at all, and that we may be introducing bloat to the framework then. I would welcome a cross-browser feature for dynamic script tag with callback only if it were a few lines long. Rest of the core team, what are your opinions on any of this becoming a part of the library? While dynamic script tag may not be so popular vs. bundling scripts into one optimized, gzipped file, I still think CSS injection could be a good addition. On the other hand, almost everything that can be accomplished with CSS injection can also be done with classname switching... --~--~-~--~~~---~--~~ 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: features request
This is a bit off topic, but what would be the ideal process of submitting patches for you guys? It seems to me that the trac bugtracker is pretty much ignored, so should I send patches to this ML. And should I send multiple patches, or one big patch from which you can pick what you feel would be a good addition? On Nov 22, 1:20 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: On Nov 22, 2007 11:57 AM, Viktor Kojouharov [EMAIL PROTECTED] wrote: I've made a ticket with an attached patch that adds a script insertion method a few months ago, right here: http://dev.rubyonrails.org/ticket/9871 Whoa, that's a lot of code. I think the problem with this sort of functionality being in core is that a lot of people have different requirements for their apps and also optimize their code and asset files differently. We must take into account that most of our users might not use the feature at all, and that we may be introducing bloat to the framework then. I would welcome a cross-browser feature for dynamic script tag with callback only if it were a few lines long. Rest of the core team, what are your opinions on any of this becoming a part of the library? While dynamic script tag may not be so popular vs. bundling scripts into one optimized, gzipped file, I still think CSS injection could be a good addition. On the other hand, almost everything that can be accomplished with CSS injection can also be done with classname switching... --~--~-~--~~~---~--~~ 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: features request
Because of the silence of other core members at the moment, it would be best for you to make a plug-in script that is included after Prototype library. Then you can share it on this ML with specific proposals what you think should be core functionality. Think it through, though; we are very picky about what gets included in the library. Trac is *not* ignored, we're checking it daily and are subscribed to RSS updates. The reason patches generally take long to be accepted is that people contribute untested code or some tricky hacks that we must fully discuss before just applying. There is more than a hundred patches in Trac, with multiple new tickets being created every day. We are trying to follow through on every one but because of their quantity and, very often, difficulty of understanding and testing a specific one. We encourage you to continue using Trac for patches. To quickly get attention to your patch feel free to use the ML. Thanks, Mislav On Nov 22, 2007 2:07 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: This is a bit off topic, but what would be the ideal process of submitting patches for you guys? It seems to me that the trac bugtracker is pretty much ignored, so should I send patches to this ML. And should I send multiple patches, or one big patch from which you can pick what you feel would be a good addition? On Nov 22, 1:20 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: On Nov 22, 2007 11:57 AM, Viktor Kojouharov [EMAIL PROTECTED] wrote: I've made a ticket with an attached patch that adds a script insertion method a few months ago, right here: http://dev.rubyonrails.org/ticket/9871 Whoa, that's a lot of code. I think the problem with this sort of functionality being in core is that a lot of people have different requirements for their apps and also optimize their code and asset files differently. We must take into account that most of our users might not use the feature at all, and that we may be introducing bloat to the framework then. I would welcome a cross-browser feature for dynamic script tag with callback only if it were a few lines long. Rest of the core team, what are your opinions on any of this becoming a part of the library? While dynamic script tag may not be so popular vs. bundling scripts into one optimized, gzipped file, I still think CSS injection could be a good addition. On the other hand, almost everything that can be accomplished with CSS injection can also be done with classname switching... --~--~-~--~~~---~--~~ 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: features request
On Nov 22, 10:29 am, Mislav Marohnić [EMAIL PROTECTED] wrote: Because of the silence of other core members at the moment, Keep in mind the western faction has been asleep, and it is a holiday in America. ;-) it would be best for you to make a plug-in script that is included after Prototype library. Then you can share it on this ML with specific proposals what you think should be core functionality. Think it through, though; we are very picky about what gets included in the library. This is a good way to proceed. Prototype 2.0 will place greater focus on HTTP transports other than Ajax (embedded IFRAMEs, SCRIPT tags, etc.). Until then it works best as a plugin. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: features request
On Nov 22, 6:29 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: Because of the silence of other core members at the moment, it would be best for you to make a plug-in script that is included after Prototype library. Then you can share it on this ML with specific proposals what you think should be core functionality. Think it through, though; we are very picky about what gets included in the library. That's pretty much what I do right now. I include the following js file, which contains some 'generic' methods, and some of them might be useful to the prototype core (while others are really only for my project). http://iwl.googlecode.com/svn/trunk/share/jscript/prototype_extensions.js From what I've gathered over time, the following might be useful for a wider audience than myself: browser detection for KHTML and IE7 Event.KEY_SPACE Element methods: for obtaining the text of the element, positioning it at the center of the screen and getting the scroll dimensions, Modified Function.bindAsEventListener, to which you can pass arguments like in Function.bind Creating a text node from a string, and parseInt|Float for strings. Array.slice (and I made it like the ruby slice, even though I am a perl dev, so that you guys may include it :) ) Object.isBoolean and Object.isObject (why weren't these included in the first place) A periodical accelerator class (like periodical executer, but continuously shortens the time between callbacks, I use this for my spinner, so I don't know if this is going to be useful for core at all) A lot of Date methods, i.e for checking if the year is leap, obtaining the century, the week number, the day of the year, and some inc/ decremental methods. The document.insertScript and evalScripts modifications I posted earlier. cellspacing|padding attribute translations for IE (I've posted a patch for this bug in trac already: http://dev.rubyonrails.org/ticket/9983) custom 'new Element' function for IE, which handles old-fashioned on* events. document.viewport methods for finding the max page dimensions, as well as the native scrollbar size. So if you are interested in any of these, I can quickly produce patches against prototype with the relative test cases for any of them. And I've also have tested them in IE6 + 7, FF2 + 3, Opera 9.2 and Safari 3 (don't have a mac for safari 2) Trac is *not* ignored, we're checking it daily and are subscribed to RSS updates. The reason patches generally take long to be accepted is that people contribute untested code or some tricky hacks that we must fully discuss before just applying. There is more than a hundred patches in Trac, with multiple new tickets being created every day. We are trying to follow through on every one but because of their quantity and, very often, difficulty of understanding and testing a specific one. We encourage you to continue using Trac for patches. To quickly get attention to your patch feel free to use the ML. Thanks, Mislav On Nov 22, 2007 2:07 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: This is a bit off topic, but what would be the ideal process of submitting patches for you guys? It seems to me that the trac bugtracker is pretty much ignored, so should I send patches to this ML. And should I send multiple patches, or one big patch from which you can pick what you feel would be a good addition? On Nov 22, 1:20 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: On Nov 22, 2007 11:57 AM, Viktor Kojouharov [EMAIL PROTECTED] wrote: I've made a ticket with an attached patch that adds a script insertion method a few months ago, right here: http://dev.rubyonrails.org/ticket/9871 Whoa, that's a lot of code. I think the problem with this sort of functionality being in core is that a lot of people have different requirements for their apps and also optimize their code and asset files differently. We must take into account that most of our users might not use the feature at all, and that we may be introducing bloat to the framework then. I would welcome a cross-browser feature for dynamic script tag with callback only if it were a few lines long. Rest of the core team, what are your opinions on any of this becoming a part of the library? While dynamic script tag may not be so popular vs. bundling scripts into one optimized, gzipped file, I still think CSS injection could be a good addition. On the other hand, almost everything that can be accomplished with CSS injection can also be done with classname switching... --~--~-~--~~~---~--~~ 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: features request
When I get around to adding it, i'll add a community section to my company
homepage, with a few of these bits and pieces on there.
Til then, i think I have a blog (virtually never updated) somewhere, and I
could post them there. I'll make a spinoffs post on this when I add it.
Thanks for the tip on adding methods, I never thought to check for
Element.addMethods!
1. agreed
2. $(myform).username works when the 'username' is static, and the use
case for non static names is very rare, so sounds fine.
3. I've used number.between a fair bit myself, and I seem to recall seeing
it recently in a library. Mainly in keyhandlers and drag/drop handling. but
yeah, it is easily accomplished with conditions.
4. Do you want me to create a patch for this? Last time I did it, I think I
used some code that allowed you to range dates by more than just day but
that's probably overkill. I think
Ken Snyder's date methods patch is here which I think has a better
implementation of Date.prototype.succ that allows more than just
day-iteration.
http://dev.rubyonrails.org/ticket/9452
Gareth
On Nov 23, 2007 1:21 PM, Mislav Marohnić [EMAIL PROTECTED] wrote:
On Nov 23, 2007 1:03 AM, Gareth Evans [EMAIL PROTECTED] wrote:
While possible features are being discussed, I have a 'get iframe
document object' function, and functions to set/get the caret position in an
input, and get [I haven't written set] the selection in a input.
While maybe not a good fit for core (most of the users wouldn't use it),
those seem definitely useful. I'll hope you'll still share them somehow
(public dir in your svn repo is an option).
They're not implemented as prototypes currently since i havent managed
to figure out how to add extra methods to 'element' (since IE doesnt extend
automatically, i imagine its not Element.prototype.functionName = ... ),
and I dont really understand how to mix in my own methods to element without
modifying the prototype.js, I should really post to spinoffs to find out
this one :)
Element.addMethods({
myAwesomeMethod(element, foo, bar) {
element = $(element);
/* your code ... */
return element; // allows chaining
}
});
You can also target specific elements:
Element.addMethods('INPUT', { ... });
Yeah, we know. It's awesome :)
Re:
1. Array#sum - nice, but very easily implemented by users themselves
using #inject or a simple for loop. We generally add such small methods to
native prototypes like Function, Array etc. when we feel the need for it in
the library.
2. Findings inputs by name - definitely a real-world need, but
obtaining a reference is easily accomplished like this:
$(myform).username
3. Number.between - again, easily accomplished with conditions, and
the need for it is very rare (IMO) when looking at web applications in
general
4. Date.succ - enabling Date ranges? I say why not.
--~--~-~--~~~---~--~~
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: features request
Andrew, thanks for positive words about scripteka! I talked to Mislav earlier and the main reason for not mentioning it on a blog seemed to be 1.6 incompatibility issues. I manually input all of the 75+ extensions into a DB and have obviously read through all the descriptions. You will be surprised how vigorously script authors took 1.6 as a requirement - since the site went live (same day as 1.6 release), 10 out of 16 new submissions were 1.6 compatible. Having said that, I like useful core additions, but it gets annoying to hear people (who have never heard of server compression) whining about 120K+ size (putting jQuery in comparison). The problem with custom methods are quality and test coverage. I don't mind downloading custom include/require, as long as it's fast and cross-browser. Unfortunately, too many authors could care less about writing unit tests, so we end up writing our own stuff (http://dev.prototype-ui.com/ browser/trunk/src/core) Some time ago, I had an idea of creating a repository of such small snippets of code. Snippets which would come with tests and documentation. http://yura.thinkweb2.com/playground/strip-tags/ best, 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: features request
While possible features are being discussed, I have a 'get iframe document object' function, and functions to set/get the caret position in an input, and get [I haven't written set] the selection in a input. I have them tested them in opera, ie and ff at present. They *are* based on snippets I found on the net, but it took a fair bit of searching to find good methods that worked in all [most] browsers. They're not implemented as prototypes currently since i havent managed to figure out how to add extra methods to 'element' (since IE doesnt extend automatically, i imagine its not Element.prototype.functionName = ... ), and I dont really understand how to mix in my own methods to element without modifying the prototype.js, I should really post to spinoffs to find out this one :) A few other things i've found useful are: Array.sum Finding inputs by *name* (so you can locate radiobutton and checkbox sets) Number.between - and optionally setting to min/max if out of range) Date.succ I am well aware of the bloat issue, which is why I haven't mentioned any of this before. Can open patches etc if you feel any are candidates for core. Gareth On Nov 23, 2007 12:19 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Nov 22, 6:29 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: Because of the silence of other core members at the moment, it would be best for you to make a plug-in script that is included after Prototype library. Then you can share it on this ML with specific proposals what you think should be core functionality. Think it through, though; we are very picky about what gets included in the library. That's pretty much what I do right now. I include the following js file, which contains some 'generic' methods, and some of them might be useful to the prototype core (while others are really only for my project). http://iwl.googlecode.com/svn/trunk/share/jscript/prototype_extensions.js From what I've gathered over time, the following might be useful for a wider audience than myself: browser detection for KHTML and IE7 Event.KEY_SPACE Element methods: for obtaining the text of the element, positioning it at the center of the screen and getting the scroll dimensions, Modified Function.bindAsEventListener, to which you can pass arguments like in Function.bind Creating a text node from a string, and parseInt|Float for strings. Array.slice (and I made it like the ruby slice, even though I am a perl dev, so that you guys may include it :) ) Object.isBoolean and Object.isObject (why weren't these included in the first place) A periodical accelerator class (like periodical executer, but continuously shortens the time between callbacks, I use this for my spinner, so I don't know if this is going to be useful for core at all) A lot of Date methods, i.e for checking if the year is leap, obtaining the century, the week number, the day of the year, and some inc/ decremental methods. The document.insertScript and evalScripts modifications I posted earlier. cellspacing|padding attribute translations for IE (I've posted a patch for this bug in trac already: http://dev.rubyonrails.org/ticket/9983) custom 'new Element' function for IE, which handles old-fashioned on* events. document.viewport methods for finding the max page dimensions, as well as the native scrollbar size. So if you are interested in any of these, I can quickly produce patches against prototype with the relative test cases for any of them. And I've also have tested them in IE6 + 7, FF2 + 3, Opera 9.2 and Safari 3 (don't have a mac for safari 2) Trac is *not* ignored, we're checking it daily and are subscribed to RSS updates. The reason patches generally take long to be accepted is that people contribute untested code or some tricky hacks that we must fully discuss before just applying. There is more than a hundred patches in Trac, with multiple new tickets being created every day. We are trying to follow through on every one but because of their quantity and, very often, difficulty of understanding and testing a specific one. We encourage you to continue using Trac for patches. To quickly get attention to your patch feel free to use the ML. Thanks, Mislav On Nov 22, 2007 2:07 PM, Viktor Kojouharov [EMAIL PROTECTED] wrote: This is a bit off topic, but what would be the ideal process of submitting patches for you guys? It seems to me that the trac bugtracker is pretty much ignored, so should I send patches to this ML. And should I send multiple patches, or one big patch from which you can pick what you feel would be a good addition? On Nov 22, 1:20 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: On Nov 22, 2007 11:57 AM, Viktor Kojouharov [EMAIL PROTECTED] wrote: I've made a ticket with an attached patch that adds a script insertion method a few months ago, right here: http://dev.rubyonrails.org/ticket/9871
