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 > > > > > > 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
