Re: [Prototype-core] Playing with Google's Closure Compiler and got a message for Prototype 1.7.0.0
I like that it warns about *lack* of side effects. I mean, any
functional programmer would think that's a great warning to have :)
-foca
On Tue, May 17, 2011 at 3:24 PM, Rick Waldron waldron.r...@gmail.com wrote:
Andrew, Richard
Not sure if this helps, but I figured it was worth the mention... jQuery no
longer uses GCC for min/compression... but when we did, we had the warn
level set to quiet:
https://github.com/jquery/jquery/commit/d503845d0cf45632c0d7c3542ffd1b19257a8e5e#L0L104
Hopefully that's useful information :)
Rick
On Tue, May 17, 2011 at 1:53 PM, Andrew Dupont goo...@andrewdupont.net
wrote:
I had to look it up, because that's part of Sizzle [1], but accessing that
property does have a side effect, apparently. It makes the `selected`
property work correctly when something is selected by default.
That strikes me as a spurious thing for GCC to warn about — you wouldn't
typically expect property access to have side effects, but with
getters/setters now in JavaScript, it'll become more and more common.
Cheers,
Andrew
[1] https://github.com/jquery/sizzle/blob/master/sizzle.js#L598
On May 17, 2011, at 11:24 AM, Richard Quadling wrote:
Hi.
Using Google Maps API with Prototype. Playing putting it into Google
Closure Compiler.
Got a message ...
Number of warnings: 1
JSC_USELESS_CODE: Suspicious code. This code lacks side-effects. Is
there a bug? at line 4437 character 3 in prototype.js
elem.parentNode.selectedIndex;
^
which is ...
filters: {
enabled: function(elem){
return elem.disabled === false elem.type !==
hidden;
},
disabled: function(elem){
return elem.disabled === true;
},
checked: function(elem){
return elem.checked === true;
},
selected: function(elem){
elem.parentNode.selectedIndex; // line
4437
return elem.selected === true;
},
parent: function(elem){
return !!elem.firstChild;
},
empty: function(elem){
return !elem.firstChild;
},
It looks like they are right? From what I know, that statement isn't
going to do anything.
To see this in action...
Go to http://closure-compiler.appspot.com/home and enter ...
// ==ClosureCompiler==
// @compilation_level SIMPLE_OPTIMIZATIONS
// @output_file_name default.js
// @code_url
http://ajax.googleapis.com/ajax/libs/prototype/1.7.0.0/prototype.js
// @code_url
http://maps.google.com/maps/api/js?libraries=geometrysensor=false
// ==/ClosureCompiler==
// ADD YOUR CODE HERE
alert(1);
as the code to optimize.
Choose Simple from the list of optimizations.
Click Compile and then look at the warnings tab on the right hand
side.
Regards,
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--
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
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
--
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
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
--
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
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
--
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
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: Element.update on images. Bug or Feature Request?
The thing is that someone who knows Prototype knows that update
changes the innerHTML of an element. If another programmer sees your
code and sees you're updating an image, he'll be a little puzzled :)
If you use image.src = path, or image.setAttribute(src, path) or
image.writeAttribute(src, path) or image.writeAttribute({ src: path
}), the intent will be much clearer. And if you want to use update
because of the chaining that Prototype allows, using
Element#writeAttribute also returns the extended element :)
Best,
-Nicolas
On Jan 24, 2008 11:33 PM, dynamo517 [EMAIL PROTECTED] wrote:
I am using prototype version 1.6.0.
Currently when updating typical (e.g. SPAN, DIV, TD, etc.) DOM
elements, a simple
$('div1').update('new text');
would update the text of the element. That's fine, but what about
images?
If I do that with an image tag, I would hope to be updating the src,
but it currently silently does nothing. No error; nothing.
Temporarily, I extended all images such that when update() is called
on them, I can pass a new src attribute and that will be set. Here's
what I did:
Element.addMethods
(
'IMG',
{
update: function(element, src)
{
element = $(element);
element.setAttribute('src', src);
return element;
}
}
);
$('img1').update('images/newImage1.gif');
By the way, I'm aware that another workaround would be to just
directly set the attribute of any image I want by
$('img1').setAttribute('src', 'images/newImage1.gif'');
but the point is to unify elements using the update function.
Is the original prototype update function doing it wrong for images?
If not, maybe this could be a new feature.
--~--~-~--~~~---~--~~
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: Javascript closures question
On Jan 8, 2008 11:20 PM, Simon Thomas [EMAIL PROTECTED] wrote:
Can anyone explain the difference in the folllowing and when and why
to use each of the methods.
(Or knows a better place to ask this question)
1)
var myVar = function(args){
// inner functions and vars
};
This makes myVar point to that function, so you can later call
myVar(args), it's a normal function declaration and it's almost
equivalent to
doing function myVar(args) { ... }. As functions are first-order
citizens in JavaScript, you can just assign them to a variable.
2)
var myVar = (function(args){
// inner functions and vars
});
This is exactly the same as (1). As any object in JS, a function can
be wrapped in parenthesis with no consequence.
3)
var myVar = (function(args){
return {
//inner functions and vars
}
})();
This will declare an anonymous function that receives args (only one
argument), and *immediately after declaring it* it will call it
passing *no arguments*. So if you depend on args inside the function
that will error out. Since it executes it, myVar will point to
whatever the function returns.
This technique was called The Module Pattern by Douglas Crockford,
and has been described throughly in the interweb:
- http://yuiblog.com/blog/2007/06/12/module-pattern/
- http://wait-till-i.com/2007/07/24/show-love-to-the-module-pattern/
-
http://nefariousdesigns.co.uk/archive/2007/08/javascript-module-pattern-variations/
Best,
-Nicolas
--~--~-~--~~~---~--~~
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: Javascript closures question
On Jan 8, 2008 11:44 PM, Mislav Marohnić [EMAIL PROTECTED] wrote:
Nicolás shouldn't have answered your question because this group is for
discussion of development for Prototype core library.
You can ask general questions on rails-spinoffs group or, if it's only
related to Core JavaScript, on any other JavaScript mailing list.
Thanks!
On Jan 9, 2008 2:36 AM, Nicolás Sanguinetti [EMAIL PROTECTED] wrote:
On Jan 8, 2008 11:20 PM, Simon Thomas [EMAIL PROTECTED] wrote:
Can anyone explain the difference in the folllowing and when and why
to use each of the methods.
(Or knows a better place to ask this question)
1)
var myVar = function(args){
// inner functions and vars
};
This makes myVar point to that function, so you can later call
myVar(args), it's a normal function declaration and it's almost
equivalent to
doing function myVar(args) { ... }. As functions are first-order
citizens in JavaScript, you can just assign them to a variable.
2)
var myVar = (function(args){
// inner functions and vars
});
This is exactly the same as (1). As any object in JS, a function can
be wrapped in parenthesis with no consequence.
3)
var myVar = (function(args){
return {
//inner functions and vars
}
})();
This will declare an anonymous function that receives args (only one
argument), and *immediately after declaring it* it will call it
passing *no arguments*. So if you depend on args inside the function
that will error out. Since it executes it, myVar will point to
whatever the function returns.
This technique was called The Module Pattern by Douglas Crockford,
and has been described throughly in the interweb:
- http://yuiblog.com/blog/2007/06/12/module-pattern/
- http://wait-till-i.com/2007/07/24/show-love-to-the-module-pattern/
-
http://nefariousdesigns.co.uk/archive/2007/08/javascript-module-pattern-variations/
Best,
-Nicolas
Oops, hadn't noticed this was in Proto-core. Sorry, I never notice if
a thread is in core or spinoffs :-\
-N
--~--~-~--~~~---~--~~
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: element.update( document.createTextNode( hello ) ); [object Text]
element.update(hello) Element.update can take a string (in which case it's set as innerHTML), an Element object, or any object that responds to either toElement or toHTML (and which returns accordingly either an element or a string of html :)) (The same goes for Element.replace and Element.update) Best, -Nicolas On Jan 7, 2008 9:02 AM, kinfei [EMAIL PROTECTED] wrote: using Prototype-version: 1.6.0 Currently element.update( document.createElement( div ) ) ---almost equal--- element.appendChild( document.createElement( div ) ); but it should able do, element.update( document.createTextNode( hello ) ) as element.appendChild( document.createTextNode( hello ) ); --~--~-~--~~~---~--~~ 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: Is there an I18N support in prototype
If you need just sprintf functionality, there's a nice wrapper around the Template class in String.interpolate http://www.prototypejs.org/api/string/interpolate Best, -Nicolas On Dec 30, 2007 1:08 PM, Severin Heiniger [EMAIL PROTECTED] wrote: There's already the powerful Template [1] functionality, which covers the replacement feature provided by sprintf(). Happy New Year, Severin [1] http://www.prototypejs.org/api/template On Dec 30, 2007 3:10 PM, Yanick [EMAIL PROTECTED] wrote: .. which brings this thought : why isn't there a sprintf()-like function in Prototype ? On Dec 20, 8:49 pm, Tobie Langel [EMAIL PROTECTED] wrote: Hi, There is no built-in support for I18N. However, implementing it in JavaScript is trivial. For a pointer on how to do this have a look at this articlehttp://24ways.org/2007/javascript-internationalisation Best, Tobie On Dec 21, 2:00 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, i am evaluating Prototype for commercial product at my company and would like to get more details regarding I18N support. Can anyone please show me the way? Thanks, SK --~--~-~--~~~---~--~~ 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] Very weird behavior with event tests
I was trying to figure out the problem of a poster in the spinoffs list (http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thread/4ff06bf903aced80) about Event.observe throwing errors with the element. I saw the code, it was using Event.observe(unextended_node, ...), so I figured to add a test for Event.fire and Event.observe receiving unextended nodes. http://pastie.caboo.se/129854 For what I can gather, the observer method in that test is being called 9 times (console.log in the observer). So that explains the 8 failures and still showing up green. I added the console.log in the first test (testCustomEventFiring) and it only calls it once, so it seems there's some poblem when extending the nodes, but after digging a bit through the source I couldn't find it, and the event handling was never the part of the source I grokked the most, so ... I'll keep looking for the problem, but maybe someone else can find it faster :) Best -Nicolas --~--~-~--~~~---~--~~ 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
Element.injectInside/Element.injectAfter/Element.injectBefore
*/
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,
[Prototype-core] Re: Superclass constructor
I'm not gonna say to you that if you have something complex calling destructors isn't correct. I'm just gonna argue against it being in core, as IMHO it's something that not really many people need, and, since you have to call it manually, the best you can do is defining a naming convention, not a behavior. So do it if you want it, I'm not one to tell you what methods you can or cannot call on your projects :) Best, -Nicolas On 9/28/07, Ryan Gahl [EMAIL PROTECTED] wrote: Alex, javascript has its own garbage collector, sure... but firstly, it's not a consistent implementation across browsers. This is an ancient problem as far as Ajax development goes. Secondly, the apps I develop (and more people are starting to get into) are highly complex, long running single page apps (major applications running in a browser, not enhanced websites), with widgets coming in and out of existence as the user interacts and moves through the flow of the app. The dispose methods handle 1) removing dom event handlers from dom elements before they are removed from the dom, therefore removing that as a memory leak path (which is a very well documented path, look it up), 2) destroying children widgets it may have created during its lifetime, unregistering things like Draggables, Sortables, etc... 3) any other actions required during the dispose cycle, like persisting or hydrating state in cases where it's important. Your trying to tell someone that's been doing Ajax development for 3+ years that he doesn't know what he's talking about... simma down, nah! On 9/28/07, Alex Arnell [EMAIL PROTECTED] wrote: On Sep 24, 1:16 pm, Les Szklanny [EMAIL PROTECTED] wrote: Yes, the destructor needs to be called manually, but calling it eliminates possible memory leaks. See below a destructor for the marker (pin) object that you see on a map. This destructor also destroys the events object, which is a property of marker. You guys are taking this way way too far. Javascript is a language in of itself. It has it's own rules and ways of doing things. The core team has merely added a more convenient way to do OO operations. They aren't re-inventing the wheel, or doing anything that wasn't already possible with the language. Secondly, javascript uses automatic garbage collection. There is no need to create destructor methods, the javascript engine will clean up un-referable objects at some future time. Granted, there are a few caveats especially when dealing with Closures but those are all things that documented and things that are common to other languages that use automatic garbage collection. Have a look here if you don't believe me. http://jibbering.com/faq/faq_notes/closures.html#clAtGb -- Ryan Gahl Manager, Senior Software Engineer Nth Penguin, LLC http://www.nthpenguin.com -- Architect WebWidgetry.com / MashupStudio.com Future Home of the World's First Complete Web Platform -- Inquire: 1-262-951-6727 Blog: http://www.someElement.com LinkedIn Profile: http://www.linkedin.com/in/ryangahl --~--~-~--~~~---~--~~ 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: Superclass constructor
On 9/22/07, Les [EMAIL PROTECTED] wrote: The OpenLayers API 2.5 (a maping API in part based on Prototype) supports multiple inheritance, so why not Prototype? Mislav said: Also, multiple inheritance isn't all that good. There is a reason Java and C++ successors like Objective-C and C# chose not to support it. JavaScript 2.0 looks like it will not support it either. So, it's a design goal not to have multiple inheritance. Besides, we all heard composition is better than inheritance :) Instead of rigidly inheriting from multiple sources, just delegate behavior to other objects. It's *that* simple. And it's effective too ;) Or use dojo, or OpenLayers, or whatever else you fancy :) Best, -Nicolas --~--~-~--~~~---~--~~ 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] Element.wrap
Quick question: why does Element.wrap return the wrapped element instead of the wrapper? I've yet to find somewhere where I use wrap that I don't do .wrap(...).up() Is it just me? -Nicolas --~--~-~--~~~---~--~~ 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] Element.addMethods
How does the core team feel about letting Element.addMethods accept, other than a tagname, a specific node or an array of nodes and extend only those? For example, I want only certain rows of a table to have some methods available, and would love to do something like Element.addMethods(tr.combatant, Combatant.Methods); What do you think? -Nicolas --~--~-~--~~~---~--~~ 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: simulated DOMContentReady event
On 9/1/07, Thomas Fuchs [EMAIL PROTECTED] wrote: IMHO, contentloaded should be fired once, when the DOM of the initial page is completely loaded and parsed by the browser. ... I think making contentloaded too magic breaks POLS. Actually it works the other way around for me. My mind maps the I've just loaded this fragment via ajax to I've just finished loading this dom, but that's me, and I understand this is subjective. Anyway, the custom event solution seems tidy enough. What do the w3c specs say on xmlhttprequests and contentloaded, if anything? -Nicolas --~--~-~--~~~---~--~~ 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: simulated DOMContentReady event
Dan Webb's LowPro[1] solves this kind of issue by registering a global Ajax.Responder that evaluates DOMContentReady behaviors onComplete. Thinking along similar lines, you could wrap Event.observe so that observers set for contentloaded are also stored into a queue that gets processed after every Ajax.onComplete. I'm just spilling my thoughts here, but I think it would work well for most cases. How do you feel about this? (and, does it have any major drawbacks I'm not seeing?) Best, -Nicolas [1]: http://svn.danwebb.net/external/lowpro/trunk/ On 8/30/07, Jeff Watkins [EMAIL PROTECTED] wrote: Having prototype simulate the DOMContentReady event for those browsers that don't support it is wonderful, however, what is the plan for calling late registrants? For example, imagine you have a widget which would like to perform its initialisation only after the DOM is ready. It registers a listener for contentready on the document. All is fine. Now let's add Ajax to the mix. The widget is instantiated via content injected via Ajax. The registration for contentready will never be called. The solution I've been using is based on someone's Event.onDOMReady code: if the event has already been fired, I call the listener after a brief delay (to maintain the implicit contract call this function later) via window.setTimeout(fn, 0). Am I missing something critical about the implementation of the synthesised contentready event? On the other hand, maybe contentready isn't the right answer here, because when browsers _really_ support DOMContentReady, it won't do what I want anyway. --~--~-~--~~~---~--~~ 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: $('my-element').$$('a[href=foo]');
On 1.6.0 this has been aliased to select
$(my-element).select(a[href=foo])
-Nicolas
On 8/29/07, Jacob Rockowitz [EMAIL PROTECTED] wrote:
Hi,
I have been using Element#getElementsBySelector a lot and keep feeling
that the method's name is too verbose, couldn't it just be an Element#$
$.
ex:
instead of
$('my-element').getElementsBySelector('a[href=foo]');
it could be
$('my-element').$$('a[href=foo]');
I understand that the usage of the $ is for utility functions but this
seems like a reasonable idea.
http://dev.rubyonrails.org/ticket/9424
thanks
~jake
--~--~-~--~~~---~--~~
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: Patch review request: #8184 maxFrequency for Ajax.PeriodicalUpdater's decay functionality
+1 for optional function
-Nicolas
On 8/29/07, Tom Gregory [EMAIL PROTECTED] wrote:
I was thinking about this the other day as I was going through
Christophe's book ... I know I'm resurrecting an old thread, but stay
with me.
Instead of adding a maxFrequency option, (really, maxDelay),
perhaps it would be more extensible to allow decay to accept a
function as well as a number. Maybe pass the frequency and last
decay value as parameters, have it return the delay until the next
request.
Thoughts?
TAG
On Aug 21, 2007, at 11:06 AM, Chris Kampmeier wrote:
Hello,
If anybody has a few cycles to spare, I could use some reviewers for a
patch I just submitted. It adds a maximum frequency option to
Ajax.PeriodicalUpdater's decay functionality, so you can do:
new Ajax.PeriodicalUpdater('widgetList', '/widgets.json',
{ frequency: 1, decay: 2, maxFrequency: 5 });
When the response is not modified, the time between requests will only
decay to 5 seconds at the most (after increasing from 1 to 2, and then
to 4). I've needed something like this almost every time I've used
Ajax.PeriodicalUpdater to prevent decayed frequencies on the order of
minutes.
http://dev.rubyonrails.org/ticket/8184
Thanks,
Chris Kampmeier
--~--~-~--~~~---~--~~
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] Suggestion: Form#focusFirstElement accepting an optional selector
I've been using http://pastie.caboo.se/91025 so when a user has errors in the form, the focused element is the first erroneous field (and when there are no errors, it behaves normally, focusing the first element). If the core team thinks it's useful I'll write a patch with proper tests :) Regards, -Nicolas --~--~-~--~~~---~--~~ 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: Date prototype functions [BUMP]
As soon as I get some free time from work, I'll rewrite a lot of active support for js (http://code.google.com/p/active-support-for-javascript), including all necessary adjustments to work well with 1.6 (like removing the interpolation methods, which are now useless :)) Best regards, -Nicolas On 8/23/07, Richard Quadling [EMAIL PROTECTED] wrote: I think many users would be grateful of having additional libraries/plugins like this. Whilst not necessarily part of the core, having them logged and available from prototype.js (with all the usual test cases) would be a nice idea. Libraries/snippets could/would have peer review for conforming to best practice for using prototype. The alternative is that a lot of this sort of stuff is on a hundred different servers and no validation on which version of prototype things work with. I would say that whoever wrote the library has the responsibility of keeping it upto date with the current prototype. Tests can should be run to confirm that the library works and ensures compatibility. On 22/08/07, Mislav Marohnić [EMAIL PROTECTED] wrote: On 8/22/07, Ken Snyder [EMAIL PROTECTED] wrote: What is the feeling on adding functions to Date.prototype? As mentioned in March (see message at bottom), adding Date.prototype.succ() would allow some helpful iterating. I would suggest an optional argument to succ for time period and I also would like to throw out several more possible methods (below). Ken, these are nice and certainly useful, but I don't think most of the people have a need for them. Most of the heavy-duty date/time logic should be kept in your application (server-side). But I'll let other core members speak for themselves. You're encouraged to keep maintaining this extensions and releasing them open-source so people who do need them can benefit. -- - 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 -~--~~~~--~~--~--~---
