Re: [Prototype-core] Re: Why are all children of an 'update'd element being purged?
Element#replace may be what you are looking for. Allen Madsen http://www.allenmadsen.com On Sat, Jul 3, 2010 at 6:00 AM, Viktor Kojouharov vkojouha...@gmail.com wrote: I understand that. And I was using update to clear the container and add a new element. My problem was, I have a reference to the previous element of the container that was just cleared, and I am saving that reference of the element with the intention of replacing the new container content with that element at some future time. Right now I'm using innerHTML = '', since using Element#update would wipe out the storage of the element I have a reference to, and that is highly undesirable. On Jul 2, 3:16 pm, joe t. thooke...@gmail.com wrote: Most people interpret it to mean update with new content. Think along the lines of a page refresh for just that element: wipe out the existing content, update with new. Some others like yourself expect it to mean append with new content. That approach is handled by Element#insert: preserve existing content, place new content at the desired Position (usually appended, but insertion options are available). http://api.prototypejs.org/dom/element/insert/ This same question came up some months ago. Hopefully that clarification helps. -joe t. On Jul 2, 5:24 am, Viktor Kojouharov vkojouha...@gmail.com wrote: This behaviour is a bit unexpected, and caused some debugging time to figure out why some elements were losing their storage. Why isn't this only done during page unload? -- 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
Re: [Prototype-core] Documentation for second parameter to AJAX callbacks.
Hi Richard, I may be misunderstanding what you are asking, but the documentation doesn't mention a second parameter. Rather, it says the headerJSON is a property on the first parameter passed into your onSuccess/onFailure methods. Hope that helps! Allen Madsen http://www.allenmadsen.com On Wed, Jun 2, 2010 at 11:15 AM, Richard Quadling rquadl...@gmail.com wrote: Hi. I'm pretty sure I'm missing it, but where is the documentation about the second parameter to the AJAX callbacks please? The second parameter contains the headerJSON value (or null). Has this facility been dropped? http://api.prototypejs.org/ajax/ajax/request/ (scroll down to Evaluating JSON headers) doesn't mention it. It is mentioned on http://api.prototypejs.org/ajax/ajax/responders So, for example, what happens for onSuccess() ? As far as I can tell, it works just the same. Regards, Richard. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- 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
Re: [Prototype-core] Re: proposal: function to validate HTML
I agree with T.J.
Allen Madsen
http://www.allenmadsen.com
On Sat, May 8, 2010 at 2:07 AM, T.J. Crowder t...@crowdersoftware.com wrote:
Hi,
Validating HTML against a DOCTYPE is a non-trivial task, and it should
be (IMHO) an authoring-time task (using tools like the W3C
Validator[1]) rather than a runtime task, where Prototype is mostly
focussed on the latter. So I don't see adding this to Prototype. (This
is just my opinion; I'm not a core dev, I don't make decisions for the
project).
If you're receiving HTML from an external source at runtime, I can see
the desire to validate it. For that kind of thing, you may want to
integrate with one of the validation services out there (there's a
short list here[2]) and/or look into mod_validator[3] for Apache.
[1] http://validator.w3.org/
[2] http://validator.w3.org/docs/help.html#others
[3] http://apache.webthing.com/mod_validator/
HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com
On May 6, 12:33 pm, walther diechmann waltherdiechm...@gmail.com
wrote:
on the rebound from a 'tour de force' of W3C specs pertaining to the
DOCTYPE and it's cripling effects on IE's (not) handling improperly
written input tags I was wondering:
Given I have a HTML string
When I call Object.validate( html_string [, doc_type])
Then I can see whether the HTML string is valid
{ errors_count: 2, warnings_count: 1, errors: { 1: { line: 5, short:
'short description', help: URL }, 2: {}}, warnings: { 1: { } } } =
Object.validate( string [, string] )
with URL being a link to the non conformancy related W3C document/
chapter/paragraph
Just a thought :)
BTW: You could - using the validate method - build validation into
methods like Element#replace and #update, when supplying an option or
argument...
Cheers,
Walther
ps. I'm in way pointing my fingers at IE which (in this case) turns
out to be the exemplary scholar in class, sticking to the standards
entirely!
--
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
athttp://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
Re: [Prototype-core] Any intention of providing a function.throttle?
I have used something like this in a project as well. I wouldn't mind seeing it in core. I don't particularly care what its called. Allen Madsen http://www.allenmadsen.com On Fri, Apr 23, 2010 at 9:00 AM, Titi Alailima tigreti...@gmail.com wrote: On Fri, Apr 23, 2010 at 6:28 AM, Mislav Marohnić mislav.maroh...@gmail.com wrote: I use it primarily for keyup events (where this is absolutely essential), but it has other uses. The feedback I wanted to get here is naming. The jQuery community calls this function debounce, because throttling means letting through a function execution at regular intervals. I agree about the last part, but I simply don't like debounce since it's completely non-descriptive to me. debounce is a technical term, and it refers to the very case that you are trying to handle. Physical controls tend to bounce and thus produce multiple events that you want to consolidate into a single event. It may not be intuitive out of context, but it has a long history from the hardware world. Coming from an electrical engineering background myself, I would be totally on board with using that terminology, but I could certainly be persuaded that something more intuitive would be in order. However, throttle definitely seems to be the wrong way to go as it has a different meaning that is very intuitive. Titi -- 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
Re: [Prototype-core] Roadmap
I agree that a road map would be helpful. In addition to the reasons gf3 mentioned, I think it would make it easier to contribute. Allen Madsen http://www.allenmadsen.com On Wed, Apr 7, 2010 at 4:53 PM, gf3 giannichiappe...@gmail.com wrote: This is a continuation of the discussion started here: http://github.com/sstephenson/prototype/commit/2f9bde3ad5a2e3dd104c812b6c81f4077fe0aa1e#all_commit_comments It would be very helpful to see some sort of Prototype roadmap or at least be able to see internal discussion about the development of the library. Not only from a personal interest standpoint but I also receive a lot of questions on IRC regarding what Prototype is doing, what's happening with development, c. Unfortunately, right now, I don't really have an information that I can pass on. Tobie mentioned a public read-only interface to internal discussions – this would satisfy my needs. Although a formal roadmap may be beneficial to core devs as well. -- 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 To unsubscribe, reply using remove me as the subject. -- 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
Re: [Prototype-core] DOM Events Mutation event types
I wouldn't mind if this made it into core either. Allen Madsen http://www.allenmadsen.com On Tue, Jan 12, 2010 at 3:21 PM, matti matti.t.jarvi...@gmail.com wrote: Is there a reason why Prototypejs doesn't fire mutation events ( http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mutationevents-h3 ) as custom events (like dom:subtreemodified) when using Element.update and Element.insert? I know that browser support for those events are lacking but I'd believe that DOMSubtreeModified, DOMNodeInsertedIntoDocument and DOMAttrModified would be easy to implement as custom events (or simulated as such if browser has support for them) and could add value preventing memory leaks on AJAX heavy UIs. Point in all this would be that it would be easier to handle Event.stopObserving. -- 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
Re: [Prototype-core] Re: Ajax.Request Interface
+1 for static methods. Not sure about the implications of the rest yet.
Allen Madsen
http://www.allenmadsen.com
On Tue, Dec 29, 2009 at 7:13 AM, Joran Greef jorangr...@gmail.com wrote:
Propose:
Http.get(uri, options) and Http.post(uri, options).
Where:
options = {
headers: {},
parameters: {},
body: '',
onSuccess: function(response) {},
onFailure: function(response) {},
onTimeout: function(response) {}
}
And:
response = {
status: Integer,
headers: {},
body: ''
}
Static methods: 'Http.get(uri, options)' as opposed to 'new Http.Get
(uri, options)'. The developer must explicitly set 'X-HTTP-Method-
Override' header or '_method' parameters or whatever he or she wants
to use to signal an unsupported method such as 'PUT' and
'DELETE' (depending on the capability of the server). The developer
must explicitly parse response.body. The Http object must be merely a
cross-browser wrapper for XMLHttpRequest and must not take on too much
responsibility or make assumptions on behalf of the developer, e.g.
with respect to JSON parsing etc.
--
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
Re: [Prototype-core] Re: Class inheritance by reference
Yea, addMethods is what you want. You can't just add them directly to the klass object. Allen Madsen http://www.allenmadsen.com On Wed, Dec 23, 2009 at 4:27 AM, T.J. Crowder t...@crowdersoftware.comwrote: Hi, I ran into problems when I tried to change a class that another class was extending. The changes did not inherit. Can you post a small, self-contained example? If you use Class.create and addMethods, changes should show up. That kind of dynamism is designed into Prototype's inheritance mechanism and covered by unit tests. -- T.J. Crowder Independent Software Consultant tj / crowder software / com www.crowdersoftware.com On Dec 22, 1:08 pm, Sakari Tuominen saka...@gmail.com wrote: Hello guys! I've been working with Javascript classes for a while now. I have been using Prototype's class inheritance. I ran into problems when I tried to change a class that another class was extending. The changes did not inherit. I found out that the extending is done when the extending class is defined. I think it's kinda bad, so I made my own version where the extending is done with a reference. I even made an article about it. Here it is: http://www.sakarituominen.com/blog/javascript-class-inheritance-madne... Please tell your thoughts! -- 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
Re: [Prototype-core] Re: For() loops, ++i, i++, i+=1
I tried running your test on IE8 and it just kept prompting me with script
unresponsive.
Allen Madsen
http://www.allenmadsen.com
On Wed, Dec 16, 2009 at 7:01 AM, Robert Kieffer bro...@gmail.com wrote:
I whipped up a quick JSLitmus test to try out a handful of empty loops
(using i++, ++i, i+=1, and a while loop:
http://www.broofa.com/Tools/JSLitmus/tests/loop_operators.html
View the [very short] source of the page to see the actual test code. When
running the test for yourself, be sure to uncheck the normalize box. Also,
you'll probably want to run each test a few times to make sure you're
getting consistent results (CPU load elsewhere in the OS can skew resutls).
For more on JSLitmus, read http://www.broofa.com/Tools/JSLitmus )
Here are the results I got on my MacBook (sorry, don't have IE results
handy)
FF: http://tinyurl.com/ykdutyk
Safari: http://tinyurl.com/yzusg7e
Opera: http://tinyurl.com/yjamzwc
Chrome: http://tinyurl.com/ylylyw5
Executive summary: On the above browsers, performance does vary. i++ or ++i
are the best all-round performers, while the while() loop is generally not
as good. However on all of these systems ('cept Opera), looping code runs
so fast that performance is negligable compared to whatever code you put
inside the loop. I.e. it's unlikely to matter in all but the most trivial
of loops.
- rwk
On Wed, Dec 16, 2009 at 2:28 AM, Yaffle vic99...@yandex.ru wrote:
++i; is a little more efficient in C language,
in javascript difference in performance of all these operators is tiny
On Dec 16, 3:21 pm, RQuadling rquadl...@googlemail.com wrote:
Hi.
Is there any consensus on which is more efficient in a for() loop?
I was taught that for ++i being the most efficient.
I've created 2 patches (++ and a +1) in case anyone is interested.
http://pastie.org/private/3rgonpsn90yjd17q9zwa
andhttp://pastie.org/private/qufy3rwmaevxc1sysvq
From what I've read, this could be a little pointless, but I'm not the
expert in this area.
Regards,
Richard.
--
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
Re: [Prototype-core] Re: parameters Encoding differents in Ajax Request
Does it break if you use htmlentities($searchParameter,ENT_COMPAT,'UTF-8');
for all browsers?
Allen Madsen
http://www.allenmadsen.com
On Fri, Dec 11, 2009 at 2:42 PM, John john@gmail.com wrote:
the page has this meta-tag
meta http-equiv=Content-Type content=text/html;
charset=utf-8 /
but I get the same bug :(
On 3 dic, 07:24, Allen Madsen bla...@gmail.com wrote:
Try setting the page encoding. For example, for html use:
meta http-equiv=Content-Type content=text/html; charset=utf-8
or for xhtml use:
?xml version=1.0 encoding=utf-8?
Though, I'm not sure this will fix your problem. It's just a guess.
Allen Madsenhttp://www.allenmadsen.com
On Wed, Dec 2, 2009 at 5:33 PM, John john@gmail.com wrote:
If I sent a parameter with bogotá value over this code
new Ajax.Request(url, {
onSuccess: function(response) {
//code
}
,parameters:'search=bogotá'
});
When this arrived to php script through Mozilla I need use
htmlentities($searchParameter,ENT_COMPAT,'UTF-8');
php function to get the acute;entity.
but in Internet explorer I need use htmlentities($searchParameter);
without 'UT8-Charset' ,
to get the acute;entity.
I think this doesn't have to be different between browsers.
I tried with enconding parameter set to UTF-8 in the Ajax Request,
but I got the same results.
--
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 athttp://
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
Re: [Prototype-core] parameters Encoding differents in Ajax Request
Try setting the page encoding. For example, for html use:
meta http-equiv=Content-Type content=text/html; charset=utf-8
or for xhtml use:
?xml version=1.0 encoding=utf-8?
Though, I'm not sure this will fix your problem. It's just a guess.
Allen Madsen
http://www.allenmadsen.com
On Wed, Dec 2, 2009 at 5:33 PM, John john@gmail.com wrote:
If I sent a parameter with bogotá value over this code
new Ajax.Request(url, {
onSuccess: function(response) {
//code
}
,parameters:'search=bogotá'
});
When this arrived to php script through Mozilla I need use
htmlentities($searchParameter,ENT_COMPAT,'UTF-8');
php function to get the acute;entity.
but in Internet explorer I need use htmlentities($searchParameter);
without 'UT8-Charset' ,
to get the acute;entity.
I think this doesn't have to be different between browsers.
I tried with enconding parameter set to UTF-8 in the Ajax Request,
but I got the same results.
--
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
Re: [Prototype-core] Server push capabilities
IMO, this does not belong in core. Firstly, the technology to enable push resides largely on the server side. Secondly, there is no standard way to interact with these server side applications, which suggests these would be better as plugins to support the best comet implementation for your project. Allen Madsen http://www.allenmadsen.com On Thu, Nov 26, 2009 at 8:16 AM, Sebastien sebastien.and...@gmail.com wrote: Hi everybody. First of all, I want to congratulate your great work on this framework. I'm writing this to propose you a great improvement for the framework : the server push. server push is also known as Ajax push or reverse Ajax. It's in fact a kind of data streaming. I searched onto the web a way to do that. I found APE : http://www.ape-project.org/fr/home.html And an another one better : DWR : http://directwebremoting.org/dwr/ The problem of APE is that it's keep a Ajax connection until server give an answer... Then have to make a request for each data that he's waiting. The problem of DWR is that the server part is Java, then no session... But much proper. I tried to understant how it works on google docs, but I didn't find anything interesting. Thanks for your time and your great work. Keep going :) -- 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
Re: [Prototype-core] Genereic Function Benchmark
You could try unittest_js'[1] benchmark function. It's at the very end of the file. It'll help with the timing. Other than that, you may like the page speed extension for firebug. [1] http://github.com/tobie/unittest_js/blob/master/assets/unittest.js Allen Madsen http://www.allenmadsen.com On Thu, Nov 19, 2009 at 9:48 AM, Jean-Philippe Encausse jp.encau...@gmail.com wrote: Hi, I'm looking for a way to analyse all my javascript code to: - Count function call - Check time spend in each function - Understand bottlenecks = Is there existing libs to do this ? (Seems firebug do not do that). = Is there a way to proxy Functions.prototype to performs bench on function calls ? Best Regards, Jp -- 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: Multiple eventName's for Event observe?
I would prefer something more like this: http://gist.github.com/166475 I think it is a rare use case that you would apply the same action to many events on the same object. However, I think it is much more common to apply multiple actions to events on the same object at one time. Of the two solutions you mention though, I would prefer the first. Allen Madsen http://www.allenmadsen.com On Thu, Oct 22, 2009 at 1:50 PM, Ngan Pham nganp...@gmail.com wrote: It would be nice if Event#observe's eventName argument was able to take an array, or perhaps a comma delimited string so that it can attach to multiple events in one call: Event.observe(something, 'keyup,mouseup', this.blah.bind(this)); or Event.observe(something, ['keyup', 'mouseup'], this.blah.bind(this)); --~--~-~--~~~---~--~~ 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: Suggestion: Prototype.Compatibility (was Units of Measurement...)
I have to agree with T.J. In addition to complexity, there is also a concern for size. If I am using the newest version of the code, why would I want the added weight of compatibility stuff I will never use? Allen Madsen http://www.allenmadsen.com On Sun, Oct 11, 2009 at 3:25 AM, T.J. Crowder t...@crowdersoftware.com wrote: Hi Robert, It's a cool idea, but the complexity starts getting explosive (particularly for unit testing). If 2.0 is going to have substantial API changes (and I think it is -- Element wrappers, for one), I'd say we should save up the list of things that -- like Joran's units thing, Enumerable.includes vs. Enumerable.include -- probably should change, and then do them wholescale at that point. My two pence... -- T.J. :-) On Oct 10, 4:36 pm, Robert Kieffer bro...@gmail.com wrote: I'd like to get everyone's opinion on an idea for simplifying the backward compatibility issues in Prototype. This comes in reaction to Joran Greef's suggestion that the Prototype API should standardize on milliseconds as the unit of time passed to methods like Function#delay () (which currently take seconds): http://groups.google.com/group/prototype-core/browse_thread/thread/54... Joran's arguments have merit, but as T.J., says I don't see changing ... barring a wholescale Prototype API rewrite. This position is understandable, given how much upheaval API changes cause in the Prototype community nowadays. But, boy, it sure would be nice if there were a good compromise! To address this issue, I propose adding a Prototype.Compatibility property. It is similar to Prototype.Version, but has a semantic of, the desired version of compatibility. By default, this would be set to the current version: Prototype.Compatibility = Prototype.Version; Users could set this after importing Prototype to control the behavior of any API that honored this setting. E.g. To indicate you would like compatibility with version 1.6 (to the extent possible), you would do this: Prototype.Compatibility = 1.6; Internally, methods like delay() could be tweaked to honor this as follows: // Old code: // timeout = timeout * 1000 // New code: timeout *= (Prototype.Compatibility 2.0 ? 1000 : 1;) Please note that I'm being very careful not to imply that Prototype 2.0 should have a way to achieve across-the-board compatibility with 1.6. Rather, I'm saying only that there are certain cases where supporting this property is trivial, and this has the dual benefit of making it easier to clean up and evolve the Prototype API, while minimizing compatibility issues for users that upgrade. --~--~-~--~~~---~--~~ 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: Units Of Measurement Options Stated Using Lowest Common Denominator Unit Practical
Joran, The type of number extensions you described aren't part of prototype. Therefore, it is simpler for developers who aren't using such an extension to use seconds. I'm not opposed to the switch, but I wanted to throw out a possible explanation for the way it is today. Allen Madsen http://www.allenmadsen.com On Fri, Oct 9, 2009 at 9:18 AM, Joran Greef jorangr...@gmail.com wrote: I've been using some Number extensions of my own for some time: Number.seconds, Number.minutes, Number.hours etc. where (2).minutes() would return the 2 minutes expressed as milliseconds e.g. 12, (2).seconds() would return 2000 etc. It's been great for defining config files e.g.: Config.Database.recentThreshold = (2).minutes(); Config.Http.timeout = (60).seconds(); I think Rails does the same and that may be where I got the idea from. I've also added Number.kilobytes, Number.megabytes, etc. It would be great if interfaces which receive a time or quantity value as an option, such as PeriodicalExecuter, could expect the value to be expressed in the lowest common denominator unit practical, i.e. milliseconds rather than seconds. Java does it, and so does Javascript's own setInterval, setTimeout etc. It would follow the principle of least surprise and make units of measurement easier to compare. --~--~-~--~~~---~--~~ 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: Observing objects
Jim,
Check this modification of Tobie's code out.
http://gist.github.com/203978
The problem you're describing is fixed by using a unique element to
fire the events from.
Allen Madsen
http://www.allenmadsen.com
On Wed, Oct 7, 2009 at 5:59 AM, Tobie Langel tobie.lan...@gmail.com wrote:
Hi again,
For the record, custom events need to be namespaced ('foo:changed',
not 'changed').
The way you handle namespacing is entirely up to you. It can be
instance based, class based or arbitrary.
It just needs to be provided by the class / instance itself, and the
Observable mixin has to take it into account.
Best,
Tobie
On Oct 7, 9:50 am, Jim Higson j...@wikizzle.org wrote:
In another thread I wrote:
The biggest problem with events at the moment is only Elements can fire
them. This makes MVC difficult because the Model (javascript objects) not
the view (HTML elements) would ideally fire the events.
For Prototype2, maybe there should be an observable mixin. When mixed in,
any object can fire events.
To which Toby replied:
This is already possible with our current event system using the
`document` object as broker.
Please see a basic, untested implementation here:
http://gist.github.com/203193
The implementation linked here is good, but isn't there a problem with:
//Foo mixes in Observable
var a = new Foo();
var b = new Foo();
a.observe( 'change', function(){alert( 'a changed' )};
b.observe( 'change', function(){alert( 'b changed' )};
a.fire('change');
// both listeners are now notified even though only object a fired.
One fix might be to do:
line22:
document.fire( this.somethingUnique + eventName, data);
line 26:
document.observe( this.somethingUnique + eventName, callback);
But I don't know where the somethingUnique would come from.
Jim
--
Jim
my wiki ajaxification thing:http://wikizzle.org
my blog:http://jimhigson.blogspot.com/
--~--~-~--~~~---~--~~
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: Suggestion: String#isEmpty instead String#empty
I'd prefer isEmpty as well. Allen Madsen http://www.allenmadsen.com On Fri, Oct 2, 2009 at 3:34 PM, joneff jon...@gmail.com wrote: I've been pondering on this one for quite a long time -- why is it String#empty instead of String#isEmpty? To me String.empty should be a field equal / referencing the empty string and not a method. I was gonna hold this to my self, but the last few days there's been some discussion about semantics (Element#destroy and Function.empty per say) and I though may be it about time to ask this question. So is there any particular reason, besides #empty being shorter than #isEmpty and does my suggestion make sense to you? --~--~-~--~~~---~--~~ 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: Function.EMPTY and Function.K
I think Function.identity is fine. If somebody is unsure of what it it
they can check the docs.
Allen Madsen
http://www.allenmadsen.com
On Fri, Sep 25, 2009 at 6:22 AM, T.J. Crowder t...@crowdersoftware.com wrote:
Hmm, whilst technically correct, the term identity may not be what
people are used to.
Good point about it being an identity function, but agreed about
confusion.
passThrough?
-- T.J.
On Sep 25, 8:47 am, Richard Quadling rquadl...@googlemail.com wrote:
2009/9/25 T.J. Crowder t...@crowdersoftware.com:
Andrew,
Make sense. Shouldn't that be Function.empty and Function.k, though,
to follow our naming rules? And perhaps Function.k should have a more
meaningful name.
-- T.J.
On Sep 25, 4:20 am, Andrew Dupont goo...@andrewdupont.net wrote:
Unless anyone has serious objections, or has a better idea, I'm going
to add these as aliases of `Prototype.emptyFunction` and
`Prototype.K`, respectively. They belong better there, since in theory
the `Prototype` namespace is for internal stuff, not for stuff that
has value to end-user developers.
Cheers,
Andrew
As f(x) = x, f is an identity function.
So, maybe
Function.identity(x) { return x; }
Hmm, whilst technically correct, the term identity may not be what
people are used to.
Maybe Function.AsIs() ?
--
-
Richard Quadling
Standing on the shoulders of some very clever giants!
EE :http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer :http://zend.com/zce.php?c=ZEND002498r=213474731
ZOPA :http://uk.zopa.com/member/RQuadling
--~--~-~--~~~---~--~~
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: $H({}).get('__proto__') in Firefox =)
kangax, there are no collisions if everything is prefixed like Yaffle suggests. Allen Madsen http://www.allenmadsen.com On Tue, Sep 22, 2009 at 8:03 AM, kangax kan...@gmail.com wrote: On Sep 21, 4:40 pm, Yaffle vic99...@yandex.ru wrote: base2.js uses prefix for it's Map Class Yes, but it uses a 1 char string - '#' - so the chance of collisions is still high (imo). [...] -- 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 prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: True Hashes using objects as keys
Arty, I believe that use case is used by element storage now. Instead of a hash of DOM element to data, you can simply use an array of DOM elements and they will have their storage attached. The speed would probably be faster than a true hash. Allen Madsen http://www.allenmadsen.com On Sat, Sep 12, 2009 at 3:05 AM, artemy tregubenko m...@arty.name wrote: This may used to unobtrusively store in a hash some data associated with dom nodes. On Fri, 11 Sep 2009 19:39:04 +0400, kangax kan...@gmail.com wrote: On Sep 11, 7:08 am, T.J. Crowder t...@crowdersoftware.com wrote: [...] @Jim: Yep, this is Java-esque but that doesn't *always* equal evil! Hardly ever! I'd say hashCode has a place. Let's step back and ask the question: What are the use cases for a hash keyed by non-string objects? Are they compelling? (I'm not saying they aren't, just saying that before running off on an idea, we need to ask the question.) I would actually like to hear about use cases too. Developing web apps for 3 years now I haven't ever needed to use hash with arbitrary keys. It doesn't mean such thing is not useful; I'm just failing to see how (and where) it can be applied in practice (especially in a context of web apps). [...] -- kangax -- arty ( http://arty.name ) --~--~-~--~~~---~--~~ 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: A more efficient $super for Prototype 2
TJ, I don't particularly think this is a problem or even a new problem (wouldn't the current let you do this as well?). This sounds like protecting the developer from themselves. I think as long as you sufficiently state what will happen in a particular instance then it is perfectly reasonable to allow each individual developer to handle it as they see fit. Allen Madsen http://www.allenmadsen.com On Wed, Sep 9, 2009 at 7:29 AM, T.J. Crowdert...@crowdersoftware.com wrote: Hi all, I thought of a wrinkle today: Mixins. This new mechanism modifies function instances if they override base class functions (it leaves them alone if they don't). So if you mix in something that has a function with the same name as a parent class's function, we will set a $super property on the mixin function's instance. That seems wrong to me, mixins should be read-only as far as the mechanism is concerned, IMHO. Now, in _practical_ terms, unless the mixin function calls $super (which seems an odd thing for a mixin to do, but I can come up with an edge case use case for it), it doesn't matter much. But if A) the mixin function does (presumably optionally) call $super, and B) more than one class mixes the mixin in, AND C) the mixin overrides one of the functions in at least one of those classes, you get class crosstalk -- a very bad thing. My first thought for how to deal with this was stupid and I'll spare you. My *second* (hopefully not stupid) thought was to mark mixin functions with a property telling us to leave them alone. I see two ramifications to doing that: 1. An API change: To define a mixin, you'd ideally want to run it through something (something we'd presumably provide) that spins through and marks the functions so we leave them alone. var MyMixIn = Class.createMixin(...); 2. Mixins can't even optionally participate in supercalls, which they can with the current mechanism. Now, for me, #2 is not a problem. I'm not thrilled about introducing #1, although really you only have to do that to protect against an edge case you're probably not going to run into. It's someting a library of mixins would want to be sure to do, but within a non- library project, not sure it really matters. -- T.J. On Sep 9, 9:28 am, Jim Higson j...@wikizzle.org wrote: On Wednesday 09 September 2009 09:02:28 Jim Higson wrote: I see where you're coming from, but FWIW I'm with Allen on this one. Also, there's no standard way to get the name of a function until ECMAScript5 (which standardizes the truly outrageous idea that function instances should have -- gasp! -- a name property), and at the moment although Firefox 3.5, Chrome 2, and Safari 4 all already have that property, IE7 (at least, haven't tested IE8) and Opera10 do not. I have a hunch we could get function names in the same way that we implement Function#argumentNames. A regex on the toString. I should have looked first - this is function decompilation and considered a bad thing. -- Jim my wiki ajaxification thing:http://wikizzle.org my blog:http://jimhigson.blogspot.com/ --~--~-~--~~~---~--~~ 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: Array#intersect and Array#without inconsistency
There seems to be more support for strict equality, so I'll write up a patch with that and modify some test cases around the change. Allen Madsen http://www.allenmadsen.com On Tue, Sep 8, 2009 at 7:33 AM, Tobie Langel tobie.lan...@gmail.com wrote: Tobie, Do you have any input on this? Yes, I'm in favor of strict equality. --~--~-~--~~~---~--~~ 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: A more efficient $super for Prototype 2
Hey TJ,
For your two suggested additions. I don't think I have ever had a use for
either. One thing I would like to suggest though is that Class.create take
an object or a function as an argument. Since it is essentially a
requirement now to use a function to create named functions that can call
super (disregarding callee), it would be nice if defining that was
simplified. So something like:
var A = Class.create({
nifty: function(){}
});
var B = Class.create(A, function(){
function nifty(){
nifty.$super.call(this);
}
return {nifty: nifty};
});
Allen Madsen
http://www.allenmadsen.com
On Tue, Sep 8, 2009 at 8:34 AM, T.J. Crowder t...@crowdersoftware.com wrote:
Hi all,
Just validated Radoslav's steps, and they work (provided you add the
submodules stuff), although it takes a while because you have to
retrieve everything (including submodules). Instead, it's really easy
and very fast to just add my repo as a remote within your existing
local prototype repo, and the pull the supercalls stuff into a branch:
1. Get into your local prototype repo
2. Add mine as a remote source:
git remote add tjcrowder git://github.com/tjcrowder/prototype.git
3. Create and switch to a local supercalls branch
git branch supercalls
git checkout supercalls
4. Pull my stuff into it:
git pull tjcrowder supercalls
5. Build
rake dist
6. Profit!
Alternately, here's[1] a pre-baked copy for anyone who just wants to
grab it and play around, but of course it will go stale fairly
quickly.
[1] http://gist.github.com/182838
-- T.J.
On Sep 8, 1:15 pm, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Radoslav,
There must be a smarter way with this, but I'm still a git newbie.
Hey, you're better at it than I am. :-)
Bw, this worked fine, since $super is attached to function
It only worked because you only had a Parent Child hierarchy. As
soon as you throw a third level into it (the grandchild test), e.g.
Parent Child GrandChild, if any of the middle layers (Child, in
this case) tries to do a supercall, it will *endlessly recurse*.
Really. Again, please read my reply to Allen above[1] for details.
[1]
http://groups.google.com/group/prototype-core/browse_thread/thread/db...
-- T.J.
On Sep 8, 1:03 pm, Radoslav Stankov rstan...@gmail.com wrote:
git pull origin supercalls is needed for getting not only the master
branch. So we have:
git clone git://github.com/tjcrowder/prototype.git
cd prototype
git branch supercalls
git checkout supercalls
git pull origin supercalls
rake dist
There must be a smarter way with this, but I'm still a git newbie.
Bw, this worked fine, since $super is attached to function
pre
var SuperKlass = Class.create({
update: function(){ console.log('super'); }
});
// written also as
var SuperKlass = Class.create((function(){
function update(){ console.log('super'); }
return {update: update};
})());
var SubKlass = Class.create(SuperKlass, {
update: function(){
this.update.$super.call(this);
console.log('sub');
}
});
(new SubKlass()).update()
/pre
p.s. on my MacOX Leopard, it behaves very good
Safari4:
test loops: 10
Old mechanism time: 686ms
New mechanism time: 123ms
Firefox 3.5
test loops: 10
Old mechanism time: 14868ms
New mechanism time: 442ms
--~--~-~--~~~---~--~~
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: A more efficient $super for Prototype 2
Oh, also, you may want to throw something into update helper about your new
method of getting super.
Allen Madsen
http://www.allenmadsen.com
On Tue, Sep 8, 2009 at 9:56 AM, Allen Madsen bla...@gmail.com wrote:
Hey TJ,
For your two suggested additions. I don't think I have ever had a use for
either. One thing I would like to suggest though is that Class.create take
an object or a function as an argument. Since it is essentially a
requirement now to use a function to create named functions that can call
super (disregarding callee), it would be nice if defining that was
simplified. So something like:
var A = Class.create({
nifty: function(){}
});
var B = Class.create(A, function(){
function nifty(){
nifty.$super.call(this);
}
return {nifty: nifty};
});
Allen Madsen
http://www.allenmadsen.com
On Tue, Sep 8, 2009 at 8:34 AM, T.J. Crowder t...@crowdersoftware.comwrote:
Hi all,
Just validated Radoslav's steps, and they work (provided you add the
submodules stuff), although it takes a while because you have to
retrieve everything (including submodules). Instead, it's really easy
and very fast to just add my repo as a remote within your existing
local prototype repo, and the pull the supercalls stuff into a branch:
1. Get into your local prototype repo
2. Add mine as a remote source:
git remote add tjcrowder git://github.com/tjcrowder/prototype.git
3. Create and switch to a local supercalls branch
git branch supercalls
git checkout supercalls
4. Pull my stuff into it:
git pull tjcrowder supercalls
5. Build
rake dist
6. Profit!
Alternately, here's[1] a pre-baked copy for anyone who just wants to
grab it and play around, but of course it will go stale fairly
quickly.
[1] http://gist.github.com/182838
-- T.J.
On Sep 8, 1:15 pm, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Radoslav,
There must be a smarter way with this, but I'm still a git newbie.
Hey, you're better at it than I am. :-)
Bw, this worked fine, since $super is attached to function
It only worked because you only had a Parent Child hierarchy. As
soon as you throw a third level into it (the grandchild test), e.g.
Parent Child GrandChild, if any of the middle layers (Child, in
this case) tries to do a supercall, it will *endlessly recurse*.
Really. Again, please read my reply to Allen above[1] for details.
[1]
http://groups.google.com/group/prototype-core/browse_thread/thread/db...
-- T.J.
On Sep 8, 1:03 pm, Radoslav Stankov rstan...@gmail.com wrote:
git pull origin supercalls is needed for getting not only the master
branch. So we have:
git clone git://github.com/tjcrowder/prototype.git
cd prototype
git branch supercalls
git checkout supercalls
git pull origin supercalls
rake dist
There must be a smarter way with this, but I'm still a git newbie.
Bw, this worked fine, since $super is attached to function
pre
var SuperKlass = Class.create({
update: function(){ console.log('super'); }
});
// written also as
var SuperKlass = Class.create((function(){
function update(){ console.log('super'); }
return {update: update};
})());
var SubKlass = Class.create(SuperKlass, {
update: function(){
this.update.$super.call(this);
console.log('sub');
}
});
(new SubKlass()).update()
/pre
p.s. on my MacOX Leopard, it behaves very good
Safari4:
test loops: 10
Old mechanism time: 686ms
New mechanism time: 123ms
Firefox 3.5
test loops: 10
Old mechanism time: 14868ms
New mechanism time: 442ms
--~--~-~--~~~---~--~~
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: A more efficient $super for Prototype 2
@TJ
I don't think it would be hard to tell the difference between a base
class construct and a function. You would just need some extra work in
construction of the base class. After the construction of klass, you
could set a property so that it is identifiable. For example:
function klass() {
this.initialize.apply(this, arguments);
}
if( !klass.name ) klass.name = 'klass';
Then you could do:
if(Object.isFunction(value)){
if(value.name === 'klass'){
//Do base class stuff
} else {
//Do function generator
}
}
I hope its clear where these snippets relate to the source.
Allen Madsen
http://www.allenmadsen.com
On Tue, Sep 8, 2009 at 11:18 AM, T.J. Crowder t...@crowdersoftware.com wrote:
@Allen,
For your two suggested additions. I don't think I have ever had a use for
either.
Thanks.
One thing I would like to suggest though is that Class.create
take an object or a function as an argument.
I _really_ like that idea, not least because it seems to me that by
reducing the *seeming* complexity it makes it much easier for relative
novices to adopt using named functions. But unfortunately it would a
further API change, because otherwise Class.create can't tell whether
the first argument is a base class constructor or a function you want
it to call to retrieve the members object:
var X = Class.create(BaseClass);
var Y = Class.create(function() {
function nifty() { ... }
return {nifty: nifty};
});
You see the problem. The API change wouldn't need to be large, it's
just suddenly we're impacting the API more than we otherwise have to,
and my gut reaction to that is usually caution (not least because
unless I caution myself, I get a bit change-happy).
None of which is meant to say A) That I'd be opposed to it if a bunch
of smart people said it was worth it (quite the opposite, in fact); or
B) That I'm not going to *immediately* steal your idea for my own
projects. :-)
FWIW, and there are 18 ways to skin this cat, but if we did anything
I'd prefer to leave Class.create alone, but I'd be really interested
in the idea of providing a new entry point (Class.define, perhaps)
that provides this new functionality and which solves the problem of
how to specify the base class in some clever way. Perhaps a new
thread for this sub-topic?
@Jim,
Ie, Class.create takes any number of objects of functions or functions. If
functions, the function name is used.
I see where you're coming from, but FWIW I'm with Allen on this one.
Also, there's no standard way to get the name of a function until
ECMAScript5 (which standardizes the truly outrageous idea that
function instances should have -- gasp! -- a name property), and at
the moment although Firefox 3.5, Chrome 2, and Safari 4 all already
have that property, IE7 (at least, haven't tested IE8) and Opera10 do
not.
-- T.J. :-)
On Sep 8, 3:27 pm, Allen Madsen bla...@gmail.com wrote:
Jim,
I like your suggestion, except that there would be no way to create private
variables and functions that could be used in more than one function. For
example, with my suggested method I could do:
Var A = Class.create(function(){
var privateVar = 0;
function privateFunction(){}
function nifty(){
privateFunction();
privateVar = 3;
}
return {nifty: nifty};
});
I'd much rather see it in this form.
Allen Madsenhttp://www.allenmadsen.com
On Tue, Sep 8, 2009 at 10:12 AM, Jim Higson j...@wikizzle.org wrote:
On Tuesday 08 September 2009 14:56:06 Allen Madsen wrote:
Hey TJ,
For your two suggested additions. I don't think I have ever had a use
for
either. One thing I would like to suggest though is that Class.create
take
an object or a function as an argument. Since it is essentially a
requirement now to use a function to create named functions that can
call
super (disregarding callee), it would be nice if defining that was
simplified. So something like:
var A = Class.create({
nifty: function(){}
});
var B = Class.create(A, function(){
function nifty(){
nifty.$super.call(this);
}
return {nifty: nifty};
});
How about simplifying further:
var B = Class.create( A,
function nifty(){
nifty.$super.call(this);
}
, function alsoNifty(){
this.nifty();
}
);
Ie, Class.create takes any number of objects of functions or functions. If
functions, the function name is used.
--
Jim
my wiki ajaxification thing:http://wikizzle.org
my blog:http://jimhigson.blogspot.com/
--~--~-~--~~~---~--~~
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
[Prototype-core] Re: A more efficient $super for Prototype 2
Jim,
I like your suggestion, except that there would be no way to create private
variables and functions that could be used in more than one function. For
example, with my suggested method I could do:
Var A = Class.create(function(){
var privateVar = 0;
function privateFunction(){}
function nifty(){
privateFunction();
privateVar = 3;
}
return {nifty: nifty};
});
I'd much rather see it in this form.
Allen Madsen
http://www.allenmadsen.com
On Tue, Sep 8, 2009 at 10:12 AM, Jim Higson j...@wikizzle.org wrote:
On Tuesday 08 September 2009 14:56:06 Allen Madsen wrote:
Hey TJ,
For your two suggested additions. I don't think I have ever had a use for
either. One thing I would like to suggest though is that Class.create
take
an object or a function as an argument. Since it is essentially a
requirement now to use a function to create named functions that can call
super (disregarding callee), it would be nice if defining that was
simplified. So something like:
var A = Class.create({
nifty: function(){}
});
var B = Class.create(A, function(){
function nifty(){
nifty.$super.call(this);
}
return {nifty: nifty};
});
How about simplifying further:
var B = Class.create( A,
function nifty(){
nifty.$super.call(this);
}
, function alsoNifty(){
this.nifty();
}
);
Ie, Class.create takes any number of objects of functions or functions. If
functions, the function name is used.
--
Jim
my wiki ajaxification thing: http://wikizzle.org
my blog: http://jimhigson.blogspot.com/
--~--~-~--~~~---~--~~
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: A more efficient $super for Prototype 2
TJ,
I guess I don't understand why it wouldn't work. I'll illustrate how I
understand it and you correct me where I'm wrong.
var A = Class.create({
nifty: function(){}
});
var B = Class.create(A, {
nifty: function(){
this.nifty.$super(); // refers to A.nifty()
//this.nifty(); //would cause recursion
}
});
Also, if what I'm thinking is correct, there are some interesting side
effects that weren't possible before. Such as:
var C = Class.create(B, {
nifty: function(){
this.nifty.$super.$super(); //refers to A.nifty() instead of B.nifty()
},
crappy: function(){
this.nifty.$super(); //calls super of another function
}
});
Allen Madsen
http://www.allenmadsen.com
On Sun, Sep 6, 2009 at 5:38 AM, T.J. Crowder t...@crowdersoftware.com wrote:
I think you need this.nifty.$super.call(this, foo);
You don't, although that also works.
Ack! Sorry, too early in the morning, hadn't had enough coffee.
That does *not* work, because you always refer to the bottommost
subclass's nifty (this.nifty is always the bottommost function), so
you end up endlessly recursing. Wow that's an easy trap to fall into.
No, it's either use the function's name unadorned, or use
arguments.callee and pay the performance penalty. Personally, I
prefer using the function's name. :-)
-- T.J. :-)
On Sep 6, 8:48 am, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Allen,
I think you need this.nifty.$super.call(this, foo);
You don't, although that also works. A named function's name is in
scope within the function:
function foo(bar) {
alert(typeof foo); // Alerts function
}
However, I was thinking about anonymous functions this morning while
waking up (pathetic, isn't it?) and realized that even if you don't
use a named function, you can avoid arguments.callee with exactly the
form you describe: this.nifty.$super.call(this, foo); I don't like
the repetition of this, but if you don't have time to switch
everything over to named functions (I'm thinking of retrofitting
efforts), it's a reasonable first step, and I assume (haven't tested
it yet) still gets speed gains over arguments.callee.
Will be posting a sample implementation (it's wonderfully simple, but
there are a couple of edge cases around dynamic updates of classes)
and tests ASAP, but I want to get some of the Prototype documentation
issues sorted out first (transferring the old doc to the new format
and updating), since that's more urgent.
-- T.J. :-)
On Sep 5, 2:46 pm, Allen Madsen bla...@gmail.com wrote:
var Thingy = Class.create({
nifty: function nifty(foo, bar) {
nifty.$super.call(this, foo);
}
});
It just ignores the function name and complains that 'nifty' is not
defined. This works:
I think you need this.nifty.$super.call(this, foo);
Allen Madsenhttp://www.allenmadsen.com
--~--~-~--~~~---~--~~
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: Array#intersect and Array#without inconsistency
From my perspective, I never use arrays to store objects of different types (I think that sort of thing belongs in an object of its own). So in theory I don't particularly care either way. However, == seems to be the standard way since many methods use include, which uses ==, or use == directly. I think === is particularly useful when you are trying to restrict an operation to a type in addition to the value and I don't see array or enumerable operations as needing that restriction. In addition, AFAIK, the only values that could be matched between types are numbers, strings, and booleans, which I don't see as very harmful. Allen Madsen http://www.allenmadsen.com On Thu, Sep 3, 2009 at 6:20 PM, kangax kan...@gmail.com wrote: On Sep 3, 1:55 pm, Allen bla...@gmail.com wrote: Hi all, I was looking into some of the array methods and noticed this inconsistency. [1].without(1); [] [1].intersect([1]); [] Basically, without uses an == comparison, whereas intersect uses an === comparison. IMHO, I think == is more appropriate. As such, I have forked the prototype repo and modified intersect. You can view the diff here: http://github.com/blatyo/prototype/commit/8b9a7b721ef787110f85c03a28c... I also created a test to see how the two methods performed against each other. See that here: http://groups-beta.google.com/group/prototype-core/web/uniontest.tar.gz Here are some of the results I got in milliseconds (running on chromium): Testing New Intersect 4517 4614 4823 4998 4856 Testing Old Intersect 7321 7337 7376 7353 7331 Let me know what you guys think. There's also `uniq`, which relies on `==`: [1, 2, 3, '1'].uniq(); [1, 2, 3] `without` actually relies on `include`, so it is `include` that would need to be changed. I think I'd rather see `===` used instead of `==` where possible, although there are probably cases when `==` is more convenient. Btw, `NaN` inequality to each other might be confusing in context of `uniq`. It might be worth mentioning in the docs that `[NaN, NaN].uniq ()` results in the very same `[NaN, NaN]`. -- 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 prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: change DOM on select option
Hi,
You probably want something more like this:
script type=text/javascript
document.observe(dom:loaded, function() {
$('englisch').observe('change', function() {
$('div').replace('pThis is English/p');
}
});
/script
The first problem is that you used # which is unneeded because $ assumes the
value is an ID. The second is that you were observing the wrong event. You
probably only want to make the change once the select has changed and the
'change' event will do that for you. The last thing I changed is switching
to using observe instead of directly setting the onWhatever property. This
is the preferred way of doing things in prototype.
For future reference, this isn't the place to post questions like this.
Instead, go to http://groups-beta.google.com/group/prototype-scriptaculous
Allen Madsen
http://www.allenmadsen.com
On Thu, Aug 27, 2009 at 8:01 AM, clicforw...@googlemail.com
clicforw...@googlemail.com wrote:
Hello,
I need to change content of a dom element on select a option.
I tried to handel it like this:
script type=text/javascript
document.observe(dom:loaded, function() {
$('#englisch').onfocus = function() {
$('div').replace('pThis is English/p');
}
});
/script
select name=select
optgroup
optionSelect Language/option
option id=englischEnglisch/option
option id=germanGerman/option
/optgroup
But nothing happens.
Can anyone help me out?
Thanks!
--~--~-~--~~~---~--~~
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: Form#serializeElement's 'submit' option, doc could use another pair of eyes
I've looked it over and your description appears to be correct. Allen Madsen On Fri, Aug 21, 2009 at 11:47 AM, T.J. Crowder t...@crowdersoftware.comwrote: Hi folks, I fixed ticket #21 today with this commit (my branch, not core): http://github.com/tjcrowder/prototype/commit/47d82530fe3d8751e5c95d528bf324d2fb450666 I'd appreciate it if someone would look hard at the relevant if statement in Form.serializeElements and check that their interpretation of what the 'submit' option is and how it works matches mine. I'm fairly sure I'm right, but the if statement in question is dense, complex, side-effect-y, and uncommented. Since this is the first time this option has been documented, we want to get it right. Whether this is what the option *should* be doing is a whole different question, and for another time. Thanks in advance, -- T.J. --~--~-~--~~~---~--~~ 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: On demand js load
This seems excessive. Just do:var pathToJS = ...;
var j = new Element('script', {
type: text/javascript,
language: javascript,
src: pathToJS
});
$(document.body).insert(j);
That way the browser does the loading for you.
You're problem is likely that javascript is technically CDATA, so you can't
just insert it into script tags. Also, you shouldn't post this kind of stuff
on Prototype-Core.Try
http://groups-beta.google.com/group/prototype-scriptaculous
Allen Madsen
On Fri, Aug 14, 2009 at 11:07 AM, Fray cilibe...@gmail.com wrote:
People: i had been searching the web to find some way to load a piece
of javascript code on demand. So far the only method thats works is
var ServerObject = Class.create({
initialize: function() {
this.the_script = ;
new Ajax.Request(arguments[0], {
contentType: text/javascript,
asynchronous: false,
onSuccess: function(t) {
var j = new Element('script', {
type: text/javascript,
language: javascript
});
j.innerHTML = this.the_script;
document.body.appendChild(j);
//eval(t.responseText);
},
onFailure: function(t){
alert(t.responseText);
}
});
return eval(this.el_script);
}
});
This works only on mozilla. I can´t find a way to make a method or
function well. (cross browser an clean)
Thanks, and sory about my english is quite forgotted.
Federico Ciliberti.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
