[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
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
On Nov 22, 6:21 pm, "Mislav Marohnić" <[EMAIL PROTECTED]> wrote: > 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). I'd like to emphasize this. Despite the vast size increase in Prototype from 1.5 to 1.6, we still want to keep the API as small as possible. If we don't want to include something, then, we're not saying that the proposed feature has no value to anyone; it just wouldn't be useful to enough people to warrant including it in core. We are enthusiastic when users of Prototype create plugins, and even happier when they document and maintain them. Doing so will lead to fame, fortune, and prowess with the opposite sex. The fame will come from inclusion in kangax's excellent Scripteka site (http:// scripteka.com) and a near-guarantee of an Ajaxian post; the other two you'll have to figure out on your own. Should we make a blog post about this? I notice we still haven't mentioned Scripteka on the blog, so it might be useful to use that same post to encourage people to write formal plugins. >4. Date.succ - enabling Date ranges? I say why not. I agree. We're touching the Date object already, so adding this in would mean fewer than 5 new lines of code. 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 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
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 tic
[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 m
[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
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
I probably handle up to 10 patches a week on trac. So we don't ignore them we just treat them as quickly as we can. Also, the goal for the upcoming 1.6.0.1 version is to remove bugs, not add features. What would very helful though, would be to help clean-up trac by closing duplicated tickets, tickets that have been resolved, etc. The mailing list is good for discussing enhancements or issues - but patches should be posted to trac. If you want a patche to make it in, it should be small, tackle one feature only and have adequate tests. It should also work in all of the following browsers: Safari 2 & 3, Opera 9, IE 6 & 7 and Firefox 2 & 3 Hope this helps, Best, Tobie On Nov 22, 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
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, 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
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('
[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('
[Prototype-core] Re: features request
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
[Prototype-core] Re: features request
On Nov 21, 2007 3:29 AM, tbela99 <[EMAIL PROTECTED]> wrote: > > hello all the guys from the prototype core. > > I really adore what you're doing. it changed the way I was programming > javascript for a while. anyway I have some features that will please > me if they are incorporated in the prototype.js file. > > the first is the ability to dynamically load javascript and css into > the page. ... One thing to keep in mind is that using several http requests (even when content is cached) instead of using one is a lot slower. I use a script that combines js and css files on the server side and serves the combined files out of a public cache directory. You can use firebug + yslow to compare the no-cache and prime-cache cases for separate and combined files. For developers, yes, keeping files separate and dependencies mapped can be very quick. That is why I keep a directory called "global" where I keep lots of files with small snippets. The snippets are compiled into one file for global use. In my environment, firebug + yslow showed an enormous improvement with 1 http request instead of 12 http requests. The primed-cache comparison also showed improvement. - Ken Snyder --~--~-~--~~~---~--~~ 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
For the Cookies you have Prototype.Tidbits on livepipe:
http://livepipe.net/projects/prototype_tidbits/
And I know someone had done Moo's Assets for Prototype, but can't find the link.
Best,
-Nicolas
On Nov 21, 2007 8:35 AM, Mislav Marohnić <[EMAIL PROTECTED]> wrote:
> These are useful, but I don't think most of them deserve their place in core.
> The ones I'd like to have are:
>
>
> dynamic SCRIPT element
> injecting CSS contentAlso, cookies could make an excellent add-on. Tobie, did
> you have some code ready for cookie support? I think I can recall you
> mentioning it several months ago.
>
> - M
>
>
>
>
>
> On Nov 21, 2007 11:29 AM, tbela99 <[EMAIL PROTECTED]> wrote:
>
> >
> > hello all the guys from the prototype core.
> >
> > I really adore what you're doing. it changed the way I was programming
> > javascript for a while. anyway I have some features that will please
> > me if they are incorporated in the prototype.js file.
> >
> > the first is the ability to dynamically load javascript and css into
> > the page. i was looking for a solution a i used script from the google
> > web toolkit, and a few days ago, while inspecting the code of
> > mootools.js (http://mad4milk.net, an MIT-licence library, i saw a
> > class implementing these fonctionnalities.
> > here is the code:
> >
> >
> > /*
> > Script: Assets.js
> >provides dynamic loading for images, css and javascript files.
> >
> > License:
> >MIT-style license.
> > */
> >
> > var Asset = new Abstract({
> >
> >/*
> >Property: javascript
> >Injects a javascript file in the page.
> >
> >Arguments:
> >source - the path of the javascript file
> >properties - some additional attributes you might want to
> > add to the
> > script element
> >
> >Example:
> >> new Asset.javascript('/scripts/myScript.js', {id:
> > 'myScript'});
> >*/
> >
> >javascript: function(source, properties){
> >properties = $merge({
> >'onload': Class.empty
> >}, properties);
> >var script = new Element('script', {'src':
> > source}).addEvents({
> >'load': properties.onload,
> >'readystatechange': function(){
> >if (this.readyState == 'complete')
> > this.fireEvent('load');
> >}
> >});
> >delete properties.onload;
> >return
> > script.setProperties(properties).inject(document.head);
> >},
> >
> >/*
> >Property: css
> >Injects a css file in the page.
> >
> >Arguments:
> >source - the path of the css file
> >properties - some additional attributes you might want to
> > add to the
> > link element
> >
> >Example:
> >> new Asset.css('/css/myStyle.css', {id: 'myStyle', title:
> > 'myStyle'});
> >*/
> >
> >css: function(source, properties){
> >return new Element('link', $merge({
> >'rel': 'stylesheet', 'media': 'screen', 'type':
> > 'text/css', 'href':
> > source
> >}, properties)).inject(document.head);
> >},
> >
> >/*
> >Property: image
> >Preloads an image and returns the img element. does not
> > inject it to
> > the page.
> >
> >Arguments:
> >source - the path of the image file
> >properties - some additional attributes you might want to
> > add to the
> > img element
> >
> >Example:
> >> new Asset.image('/images/myImage.png', {id: 'myImage',
> > title:
> > 'myImage', onload: myFunction});
> >
> >Returns:
> >the img element. you can inject it anywhere you want with
> > //
> >*/
> >
> >image: function(source, properties){
> >properties = $merge({
> >'onload': Class.empty,
> >'onabort': Class.empty,
> >'onerror': Class.empty
> >}, properties);
> >var image = new Image();
> > image.src = source;
> >var element = new Element('img', {'src': source});
> >['load', 'abort', 'error'].each(function(type){
> >var event = properties['on' + type];
> >delete properties['on' + type];
> >element.addEvent(type, function(){
> >this.removeEvent(type, arguments.callee);
> > event.call(this);
> >});
> >});
> >if (image.width && image.height) element.fireEvent('load',
> > element,
> > 1);
> >return element.setProperties (properties);
> >},
> >
> >/*
[Prototype-core] Re: features request
These are useful, but I don't think most of them deserve their place in
core. The ones I'd like to have are:
1. dynamic SCRIPT element
2. injecting CSS content
Also, cookies could make an excellent add-on. Tobie, did you have some code
ready for cookie support? I think I can recall you mentioning it several
months ago.
- M
On Nov 21, 2007 11:29 AM, tbela99 <[EMAIL PROTECTED]> wrote:
>
> hello all the guys from the prototype core.
>
> I really adore what you're doing. it changed the way I was programming
> javascript for a while. anyway I have some features that will please
> me if they are incorporated in the prototype.js file.
>
> the first is the ability to dynamically load javascript and css into
> the page. i was looking for a solution a i used script from the google
> web toolkit, and a few days ago, while inspecting the code of
> mootools.js (http://mad4milk.net, an MIT-licence library, i saw a
> class implementing these fonctionnalities.
> here is the code:
>
>
> /*
> Script: Assets.js
>provides dynamic loading for images, css and javascript files.
>
> License:
>MIT-style license.
> */
>
> var Asset = new Abstract({
>
>/*
>Property: javascript
>Injects a javascript file in the page.
>
>Arguments:
>source - the path of the javascript file
>properties - some additional attributes you might want to
> add to the
> script element
>
>Example:
>> new Asset.javascript('/scripts/myScript.js', {id:
> 'myScript'});
>*/
>
>javascript: function(source, properties){
>properties = $merge({
>'onload': Class.empty
>}, properties);
>var script = new Element('script', {'src':
> source}).addEvents({
>'load': properties.onload,
>'readystatechange': function(){
>if (this.readyState == 'complete')
> this.fireEvent('load');
>}
>});
>delete properties.onload;
>return script.setProperties(properties).inject(
> document.head);
>},
>
>/*
>Property: css
>Injects a css file in the page.
>
>Arguments:
>source - the path of the css file
>properties - some additional attributes you might want to
> add to the
> link element
>
>Example:
>> new Asset.css('/css/myStyle.css', {id: 'myStyle', title:
> 'myStyle'});
>*/
>
>css: function(source, properties){
>return new Element('link', $merge({
>'rel': 'stylesheet', 'media': 'screen', 'type':
> 'text/css', 'href':
> source
>}, properties)).inject(document.head);
>},
>
>/*
>Property: image
>Preloads an image and returns the img element. does not
> inject it to
> the page.
>
>Arguments:
>source - the path of the image file
>properties - some additional attributes you might want to
> add to the
> img element
>
>Example:
>> new Asset.image('/images/myImage.png', {id: 'myImage',
> title:
> 'myImage', onload: myFunction});
>
>Returns:
>the img element. you can inject it anywhere you want with
> //
>*/
>
>image: function(source, properties){
>properties = $merge({
>'onload': Class.empty,
>'onabort': Class.empty,
>'onerror': Class.empty
>}, properties);
>var image = new Image();
>image.src = source;
>var element = new Element('img', {'src': source});
>['load', 'abort', 'error'].each(function(type){
>var event = properties['on' + type];
>delete properties['on' + type];
>element.addEvent(type, function(){
>this.removeEvent(type, arguments.callee);
>event.call(this);
>});
>});
>if (image.width && image.height) element.fireEvent('load',
> element,
> 1);
>return element.setProperties(properties);
>},
>
>/*
>Property: images
>Preloads an array of images (as strings) and returns an
> array of img
> elements. does not inject them to the page.
>
>Arguments:
>sources - array, the paths of the image files
>options - object, see below
>
>Options:
>onComplete - a function to execute when all image files are
> loaded
> in the browser's cache
>onProgress - a function to execute when one image file is
> loaded in
> the browser's cache
>
>Example:
>
