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
-~----------~----~----~----~------~----~------~--~---

Reply via email to