And I've managed to misspell Starting in the title (as Staring...)
in both posts, ftl.
Tobie - what did you mean (in other thread) about doing the work in a
closure. Which work were you referring to?
On Jan 31, 1:38 am, Tobie Langel [EMAIL PROTECTED] wrote:
Just to clarify, I suggested
[As suggested by Tobie - reposted from
http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thread/a7edd31205e69472]
I've started a path to reimplementing commonly reused global names
with a patch (http://dev.rubyonrails.org/ticket/10958)
This patch is for $ function. I've giving
My driving reason is to let jquery developers use unittest for their
unit tests as I like it a lot as a test suite. Without noConflict, the
jquery app will need to use its noConflict setup, rather than
Prototype using its noConflict setup.
Fixing prototypes critical namespacing conflicts - the
to support inter-
library namespacing happiness, then it seems a suitably minimal
refactoring.
Nic
On Jan 31, 2:17 am, Dr Nic [EMAIL PROTECTED] wrote:
My driving reason is to let jquery developers use unittest for their
unit tests as I like it a lot as a test suite. Without noConflict, the
jquery
PROTECTED] wrote:
On 30 jan, 17:22, Dr Nic [EMAIL PROTECTED] wrote:
Alternately, can I have permission to make unittest independent of
prototype? :P
I did look at it _very briefly_ and realised that I just needed to
cleanup the use of $.
If multi framework unittests is what you want, you
/is thing to be fixed/is something to be fixed/
sorry
On Jan 31, 7:53 am, Dr Nic [EMAIL PROTECTED] wrote:
Lack of namespace management is thing to be fixed, not protected as
sacred.
Whether its unittest or a widget that needs to coshare JavaScript-land
with other widgets built ontop
/ lib / framework,
hasn't extended Function.prototype.bind with something else, something
that would *totally* break Prototype ?
What's the point in handling the global scope issue if we're not
handling that issue too ?
And we all know what that implies.
Best,
Tobie
Dr Nic wrote:
Lack
But it doesn't have to be the $ feature - this can be cleanly
noconflict-proofed; giving some useful benefits.
I'm still keen to see this refactoring as I think its a Good Thing.
On Jan 31, 9:17 am, Tobie Langel [EMAIL PROTECTED] wrote:
Right so there are some frameworks that will never work
of these per library, for
example.
I'll close the ticket.
On Jan 31, 5:13 pm, Dr Nic [EMAIL PROTECTED] wrote:
But it doesn't have to be the $ feature - this can be cleanly
noconflict-proofed; giving some useful benefits.
I'm still keen to see this refactoring as I think its a Good Thing.
On Jan 31
script.aculo.us, it could be
repatch against the prototype versions of unittest.js and the patch
resubmitted if it will be accepted.
Nic
On Feb 4, 4:48 pm, Dr Nic [EMAIL PROTECTED] wrote:
[posted by kangax in Nov 07 with no responses at the time]
Hello team,
I recently needed a cross-browser
On trunk, on both firefox and safari, the testEachSlice method in
enumerable.html is stalling (seemingly indefinitely).
Is reproducible by anyone else? I ran it via rake test_units and by
loading the html directly into browsers.
--~--~-~--~~~---~--~~
You received
Prototype ?
Best,
Tobie
On Feb 13, 12:04 pm, Dr Nic [EMAIL PROTECTED] wrote:
On trunk, on both firefox and safari, the testEachSlice method in
enumerable.html is stalling (seemingly indefinitely).
Is reproducible by anyone else? I ran it via rake test_units and by
loading the html
12 matches
Mail list logo
