[Prototype-core] Re: Hash.toQueryString changes
On 3/16/07, Colin Mollenhour [EMAIL PROTECTED] wrote:
Here's mine. First, it uses $H(value).findAll, so it isn't safe (try
feeding
it each, for instance).
The new function in 1.5.1_rc1 has the same problem so I figured you
were comfortable with that fact already..
No I'm not comfortable. Copy and paste this object in your test page:
{ _each:1, each:2, findAll:3 }
eval with Prototype 1.5.1 serializes the object correctly.
--~--~-~--~~~---~--~~
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] $$() and :nth psuedo-elements
The new version of $$() is wonderful but doesn't seem to work all that well with the :nth psuedo-elements. It looks to only work correctly when in the formula an+b, a and b are positive and b a. I don't know if anyone has noticed this yet, but I couldn't find a bug id so I filled a new one and added a possible fix for it (as well as test cases). The bug is at: http://dev.rubyonrails.org/ticket/7841. Trevan --~--~-~--~~~---~--~~ 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: $$() and :nth psuedo-elements
Hey Trevan, Trevan Richins a écrit : The new version of $$() is wonderful but doesn't seem to work all that well with the :nth psuedo-elements. It looks to only work correctly when in the formula an+b, a and b are positive and b a. I don't know if anyone has noticed this yet, but I couldn't find a bug id so I filled a new one and added a possible fix for it (as well as test cases). The bug is at: http://dev.rubyonrails.org/ticket/7841. Thanks for the heads up. It's possible, due to the code's freshness, that there are still bugs. The negative values, in particular, are very likely not handled, although I'm surprised about the b a thing. I (and Andrew, no doubt) will look into it ASAP. As a small note, $$ does not implement any pseudo-element, but pseudo-classes. Pseudo-elements, as their name implies, do not select *elements*. They select fragments, or sometimes as-yet-empty locations (:first-letter, :first-line, :before, :after, :selection). -- Christophe Porteneuve a.k.a. TDD [They] did not know it was impossible, so they did it. --Mark Twain Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Hash.toQueryString changes
Andrew Dupont wrote: We *are* trying to implement a serialization method compatible with application/x-www-form-urlencoded I think this makes the situation very simple then. We need Hash.toQueryString to behave *exactly* like a form of type application/x-www-form-urlencoded. Forms *do not* add brackets to inputs so neither should this method. If your backend requires brackets, then you need to add them to your form input names as well as your hash key names. It would be strange if you had to do one and not the other. I think it would be even worse to force users of non-bracketed backends (J2EE, .Net, Perl, Python, etc) to have to change their backend code to remove the brackets just because the client side JS library thinks they should be there. I also think this method is becoming way more complicated than it needs to be. This is not a generic data serialization method. We don't need to deal with nested hashes or arrays inside arrays. If you want to serialize arbitrary structures of arbitrary depths use JSON. It's really good at that. -- Michael Peters Developer Plus Three, LP --~--~-~--~~~---~--~~ 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] Prototype + Ajax + XML
Hello! I am from Brazil and my English is very poor... hehehehe I have a lot of doubts about using the Prototype.Ajax to get information of a XML. Somebody can help me? I don´t understand if a can get the information of XML using JSON... I am lost!!! Thank´s! Vitor --~--~-~--~~~---~--~~ 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: Download 1.5.1_rc2
Thanks. No reason - we simply forgot to update the page ;) On 3/16/07, seb [EMAIL PROTECTED] wrote: Hi I have just noticed that on the website, in the download area, it's still 1.5.1_rc1 and not 1.5.1_rc2. Just for information (or may be there ia reason that I don't see) Seb --~--~-~--~~~---~--~~ 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: Hash.toQueryString changes
Tom Gregory wrote: Take Michael's argument a bit further (_exact_ encoding as a form would do it), and perhaps it might be acceptable that any nested arrays/hashes simply be JSON encoded and passed as a string. It's a simple convention, with no edge cases. I'm ok with this. It's the easiest to explain to someone and fits the POLS. -- Michael Peters Developer Plus Three, LP --~--~-~--~~~---~--~~ 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: Using delegate pattern vs extends in Array
On 16 mar, 12:14, Mislav Marohnić [EMAIL PROTECTED] wrote: Using that structure is treating arrays as hashes, which they are not. Besides, you are not integrating a framework in an existing application, you are porting your existing application to a framework. Get it That means some serious code cleanup and refactoring, during which you can start using Enumerable. For sure, but you know, sometime code is even not easy to modify on existing project (with some obscure versionning tool like Arcad one) with some 5000 jsp... I know it is extreme case but it happens to you, you can't do other thing than to adapt framework to project, no? I used to do this, my mistake! ... but cost me less and make team happy to used prototype for new dev. Anyway, thanks for your reply. --~--~-~--~~~---~--~~ 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: toQueryParams() vs toQueryString()
Michael Peters wrote:
In the process, blank values are being
lost. Here's an example:
var query = 'foo=barfoo=foo=foo=baz';
alert('BEFORE: ' + query + \nAFTER : +
$H(query.toQueryParams()).toQueryString());
The reason this breaks is because toQueryParams() translates
'foo=barfoo=foo=baz' into { foo: ['bar', undefined, 'baz] }. And
toQueryString() translates undefined into non-existant instead of blank.
I also looked at what's in svn and it's having the same problem.
--
Michael Peters
Developer
Plus Three, LP
--~--~-~--~~~---~--~~
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: toQueryParams() vs toQueryString()
Michael Peters wrote:
Michael Peters wrote:
In the process, blank values are being
lost. Here's an example:
var query = 'foo=barfoo=foo=foo=baz';
alert('BEFORE: ' + query + \nAFTER : +
$H(query.toQueryParams()).toQueryString());
The reason this breaks is because toQueryParams() translates
'foo=barfoo=foo=baz' into { foo: ['bar', undefined, 'baz] }. And
toQueryString() translates undefined into non-existant instead of blank.
Sorry to keep answering my own posts, but having re-read this thread -
http://groups.google.com/group/prototype-core/browse_thread/thread/0140fdf88eed057d/86ba728fb611687b#86ba728fb611687b
it seems that undefined is meant to remove the element from the serialization.
So the problem is that String.toQueryParams() is changing an empty element into
undefined instead of either null or . Right? If so should I open a ticket and
attach a patch?
--
Michael Peters
Developer
Plus Three, LP
--~--~-~--~~~---~--~~
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: Hash.toQueryString changes
After seeing all of the server-side inconsistencies with url decoding, I too agree that Hash.toQueryString is getting too complicated. In fact, what was wrong with the old one? The one currently in 1.5.1_rc2 needs to go as it has several problems that the old one didn't have and it is pretty convoluted for what it accomplishes. It'd be nice to be able to encode any data structure but it doesn't look like it is going to work. Also, why can't Ajax.Request leave the parameters option a string if it is passed a string? Converting to a hash and back to a string is completely unnecessary and complicates things. If the user passes a string, let's just assume he knows what he's doing and doesn't want his string broken down and reconstructed. If an object is passed it can still be converted to a string. That way problems like using enumerable method names as keys can be circumvented by the user building the parameters string manually. Colin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
