hi,
can it be that mootools Request.JSON is much slower than simple
Request with "evalScripts:true"?
MooTools uses feature detection for many things, as it should, but the user
agent string is the right thing to look at to provide this information.
If you are browsing the web with a faked user agent string, that's your fault.
Again, MooTools uses feature detection when it provides functionality
Although Fábio M. Costa has given me a reason, I think the way to detect
the broswer should not base on User-Agent
Detecting by the ability is better by the name.for example, when I use
Chrome to explorer the web, I can do it like those:
*chrome.exe --user-agent="Mozilla/5.0 (iPad; U; CP
Hi All,
I have noticed the scroller class works smooth with a container and
lots of child elements in mootools 1.11, but in mootools 1.2, if the
child elements have a margin, the scroller doesn't work when the hover
is on the margin.
I have set up a demo of this.
If you hover the mouse to the ri
Oh ... I was under the impression that it was yours.
:P
On Oct 12, 2010, at 4:28 PM, Christoph Pojer wrote:
> Anyone can edit the upgrading guide and add more information.
You are not passing an array but a string instead. You can't use apply
with anything that is not an array or arguments object. Use
fn.apply(this, Array.from(object)) - in your example the expected
behavior is to call the function with "dir" as first argument, so you
might as well wanna use fn.call(
I <3 the .gsub! and .sort! methods :D
But JavaScript is still the coolest.
On Oct 12, 2010, at 4:08 PM, atom wrote:
> guess i am spoiled by Ruby's destructive method names :p
>
> On Oct 12, 6:02 pm, Sean McArthur wrote:
>> I was caught off guard by the change also. Perhaps the docs should make
I stand corrected.
On 2010-10-13, at 00:05, Sean McArthur wrote:
> I think cause `arguments` is (and was?) supposed to be an array. when switch
> to pass an array in your fiddle, it worked.
>
> On Tue, Oct 12, 2010 at 3:02 PM, Oskar Krawczyk
> wrote:
> The docs state:
>
> Replacement example
guess i am spoiled by Ruby's destructive method names :p
On Oct 12, 6:02 pm, Sean McArthur wrote:
> I was caught off guard by the change also. Perhaps the docs should make more
> of a point that this has different behavior than $merge before it.
>
> On Tue, Oct 12, 2010 at 2:59 PM, Christoph Poje
I think cause `arguments` is (and was?) supposed to be an array. when switch
to pass an array in your fiddle, it worked.
On Tue, Oct 12, 2010 at 3:02 PM, Oskar Krawczyk wrote:
> The docs state:
>
> Replacement example
>
>
> fn.apply(thisArg, arguments); // Old API: fn.run(arguments, thisArg);
>
>
Seems like the second argument can only be an array - perhaps the
documentation could mention this fact (?)
O.
On Oct 13, 12:02 am, Oskar Krawczyk wrote:
> The docs state:
>
> Replacement example
>
> fn.apply(thisArg, arguments); // Old API: fn.run(arguments, thisArg);
> I'm trying this, here:ht
The docs state:
Replacement example
fn.apply(thisArg, arguments); // Old API: fn.run(arguments, thisArg);
I'm trying this, here: http://www.jsfiddle.net/oskar/KWvA3/
But all I get is the following error: "Uncaught TypeError:
Function.prototype.apply: Arguments list has wrong type"
Can someone
I was caught off guard by the change also. Perhaps the docs should make more
of a point that this has different behavior than $merge before it.
On Tue, Oct 12, 2010 at 2:59 PM, Christoph Pojer
wrote:
> It is mentioned in the example, but maybe you are right.
>
> As for upgrading, I had this in t
It is mentioned in the example, but maybe you are right.
As for upgrading, I had this in the guide already:
http://github.com/mootools/mootools-core/wiki/Upgrade-from-1.2-to-1.3
On Oct 12, 11:56 pm, Ryan Florence wrote:
> Might be good to mention in the docs for the next patch release.
>
> On Oc
Might be good to mention in the docs for the next patch release.
On Oct 12, 2010, at 3:54 PM, Christoph Pojer wrote:
> Object.merge({}, a, b, c)
so a reasonable solution to using $merge like it used to (without
altering first) be would be to:
var merged = Object.merge(Object.clone(obj1), obj2)
right?
On Oct 12, 5:49 pm, Sean McArthur wrote:
> No where does it say that $merge == Object.merge
>
> In fact, if you look in the compat script,
That's not exactly true, the docs say under $merge:
"This method has been deprecated. Please use Object.merge instead."
Like I'm going to open the compat script and to decide if they are supposed to
be the same.
The blog post also said: "In order to reduce the number of global variables, we
ha
As Ryan pointed out, the docs imply that this behavior is intended. If
you want to create a clone that is a result of a merge of several
objects, use Object.merge({}, a, b, c) or resort to the $merge
compatibility function.
On Oct 12, 11:46 pm, Perrin Perrin wrote:
> From 1.2 docs:
>
> var obj1 =
No where does it say that $merge == Object.merge
In fact, if you look in the compat script, it's obvious they are meant to be
different.
On Tue, Oct 12, 2010 at 2:46 PM, Perrin Perrin wrote:
> From 1.2 docs:
>
> var obj1 = {a: 0, b: 1};
> var obj2 = {c: 2, d: 3};
> var obj3 = {a: 4, d: 5};
> va
>From 1.2 docs:
var obj1 = {a: 0, b: 1};
var obj2 = {c: 2, d: 3};
var obj3 = {a: 4, d: 5};
var merged = $merge(obj1, obj2, obj3); //returns {a: 4, b: 1, c: 2, d:
5}, (obj1, obj2, and obj3 are unaltered)
var nestedObj1 = {a: {b: 1, c: 1}};
var nestedObj2 = {a: {b: 2}};
var nested = $merge(nestedOb
From the 1.3 docs:
var obj1 = {a: 0, b: 1};
var obj2 = {c: 2, d: 3};
var obj3 = {a: 4, d: 5};
var merged = Object.merge(obj1, obj2, obj3); // returns {a: 4, b: 1, c: 2, d:
5}, (obj2, and obj3 are unaltered)
merged === obj1; // true, obj1 gets altered and returned as merged object
var nestedObj1
Ouch.
Yes, this should not happen.
Can you post a ticket on lighthouse?
On 2010-10-12, at 23:32, atom wrote:
> bit of unexpected behavior (which might be intentional). When using
> Object.merge the objects I pass in are being altered, unlike how
> $merge used to behave.
>
> old way:
>
> var
bit of unexpected behavior (which might be intentional). When using
Object.merge the objects I pass in are being altered, unlike how
$merge used to behave.
old way:
var obj1 = {a: 1, b: 2, c: 3}
var obj2 = {d: 4, e: 5, f: 6}
var merged = $merge(obj1, obj2);
console.log(obj1); // returns {a: 1, b
See Insane :D
Thanks Sean I work in a closed box so i tend to forget such things :)
On Tue, Oct 12, 2010 at 3:46 PM, Sean McArthur wrote:
> @Paul: There is a need for server side validation. One: if user has
> Javascript turned off, then server side is all you. Two: people may try to
> submit ma
@Paul: There is a need for server side validation. One: if user has
Javascript turned off, then server side is all you. Two: people may try to
submit malicious data, sending their own POST requests, which would skip the
client side validation. Server side validation is your last defense.
On Tue,
Cheap one: I do not have an answer I am to lazy to search and just write my
own :D
Harder one: I see no need in the end. Client side is all you should need. If
you are validating it correctly there then the data going in to the server
should be good and not produce an error. If it does then I sup
Hi all,
I'm considering rolling the cool Form.Validator stuff into my generic
form code, and I have two questions, one cheap, and one more in-depth:
Cheap one: I see the default error behavior I get with
Form.Validator.Inline. It's nice, but I was wondering if there was a
catalog out there some
The user agent is the most safe way to detect correctly the browser, the
browser version and it's engine.
Feature detection should be made to detect point inconsistencies (if
elements has the filter style, if tables accept innerHTML correctly, etc.).
The big problem we had with the old version of
The reason is that Mootools transferred from feature detection (what you see
in 1.2) to browser user-agent string parsing (that weird regexp stuff).
On Tue, Oct 12, 2010 at 4:19 PM, HENG wrote:
> Hello everyone:
>
> I am very happy that Mootools 1.3 has released! Thank all the guys in
> Mootools
Yeah!! I like open source language such as PHP, Python and Java
But Mootools is my first selection ...
Oh!! I'm waiting for 1.3 stable ...
On Tue, Oct 12, 2010 at 9:50 PM, Piotr Zalewa wrote:
> I had the same feeling
>
> On 10/12/10 15:35, HENG wrote:
> > Hello:
> >
> > When I read the source c
Oh!!
I just read good news.
I can download 1.3 stable.
Thanks
On Tue, Oct 12, 2010 at 10:45 PM, Sitthykun LY wrote:
> Yeah!! I like open source language such as PHP, Python and Java
> But Mootools is my first selection ...
>
> Oh!! I'm waiting for 1.3 stable ...
>
>
> On Tue, Oct 12, 2010 at 9:
I had the same feeling
On 10/12/10 15:35, HENG wrote:
> Hello:
>
> When I read the source code Mootools 1.3.I found that Mootools just
> like Python
>
> That anyone like Python?? Haha, if you like python, Mootools is the best
> choise.
>
>
> --
> --
Hello:
When I read the source code Mootools 1.3.I found that Mootools just like
Python
That anyone like Python?? Haha, if you like python, Mootools is the best
choise.
--
HengZhou
-
Hello everyone:
I am very happy that Mootools 1.3 has released! Thank all the guys in
Mootools dev Team! Thank you all very much!
I am a Mootools Crazy Boy, because I really like it very much!
Now, I want to ask a question about Mootools. And I hope that Mootools Dev
Team can give me an answer.
Request.DetectLanguage http://bit.ly/dlC8pl => This class allows you
to detect the language of blocks of text within a webpage. It uses
Google AJAX Language API for Detection.
cheers!
Careful, it is not working with 1.3, even with compatibility layer:
http://www.jsfiddle.net/ZNaeY/7/
Funny "dancing" effect, btw.
On Oct 9, 10:10 pm, Robert wrote:
> Sorry was whole day out.
> Is this What You are looking for?
>
> http://www.jsfiddle.net/ZNaeY/3/
>
> On 9 Paź, 14:34, Robert wro
...and new powertools:
http://cpojer.net/PowerTools/
;)
Thanks!
On Oct 12, 12:01 am, Christoph Pojer
wrote:
> http://mootools.net/blog/2010/10/11/mootools-core-1-3-stable-and-moot...
>
> Enjoy!
> thats true.but for anyone who doesn't know why they're
> specifically using the load event should use the domready event.
jQ has its own well-known .ready(); I assume OP knows why he's not
using it, or else the question is signif'ly bigger than
cross-framework tr
thats true. but for anyone who doesn't know why they're specifically using
the load event should use the domready event.
On Tue, Oct 12, 2010 at 12:23 AM, Sanford Whiteman <
sa...@cypressintegrated.com> wrote:
> > $('document').addEvent('domready', function() {
> > //code here...
> > });
>
>
> $('document').addEvent('domready', function() {
> //code here...
> });
domready !== load
Equivalent in Moo is
window.addEvent('load', …
-- Sandy
woah! very usefull :)
bookmarked!
--
Andrea
On Tue, Oct 12, 2010 at 06:06, Aaron Newton wrote:
> Nice work Christoph!
>
>
> On Mon, Oct 11, 2010 at 11:08 PM, Christoph Pojer <
> christoph.po...@gmail.com> wrote:
>
>> I have just released all my latest stuff, labeled PowerTools:
>> http://cpoje
41 matches
Mail list logo
