summaryrefslogtreecommitdiffstats
path: root/tests/auto/corelib/io/qurlquery
Commit message (Collapse)AuthorAgeFilesLines
* Port away from QUrl::MostDecodedThiago Macieira2012-05-221-2/+2
| | | | | | | | | | | Since we're about to introduce QUrl::FullyDecoded, this QUrl::MostDecoded value would be confusing. Replace its uses with what was intended at the point in question. Change-Id: Iefd87bc33d37bace507c5cb0f206fa902e08e2df Reviewed-by: Lars Knoll <lars.knoll@nokia.com> Reviewed-by: David Faure <faure@kde.org> Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
* Change the component formatting enum values so the default is zeroThiago Macieira2012-04-111-5/+8
| | | | | | | | | | | | | | | | | | | | | | By having the default value equal to zero, we follow the principle of least surprise. For example, if we had url.path() and we refactored to url.path(QUrl::DecodeSpaces) Then instead of ensuring spaces are decoded, we make spaces the only thing encoded (unicode, delimiters and reserved characters are encoded). Besides, modifying the default can only be used to encode something that wasn't encoded previously, so having the enums as Encode makes more sense. As a side-effect, toEncoded() does not support any extra encoding options. Change-Id: I2624ec446e65c2d979e9ca2f81bd3db22b00bb13 Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
* Merge QUrl::DecodeAllDelimiters and QUrl::DecodeUnambiguousDelimitersThiago Macieira2012-04-111-4/+4
| | | | | | | | | | | | | | | | | | | There's little value in having the DecodeUnambiguousDelimiters option since neither QUrl nor QUrlQuery can return values that are ambiguous in that particular context, ever. This option could be used to encode a character if, when placed in a URL, it would need to be encoded. Such cases are hash (#) or question marks (?) in the path component, or slashes (/) and at signs (@) in the userinfo. However, we don't need two enums for that, since there are no other characters that can appear in either form. Still, leave two bits for this enum. In the future, if we want to split the gen-delims from the sub-delims, we are able to. Change-Id: If5416b524680eb67dd4abbe7d072ca0ef7218506 Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
* Forward the methods dealing with the break down of query to QUrlQueryThiago Macieira2012-03-301-0/+120
| | | | | | | | | | | | Now that QUrlQuery exists, these methods are no longer necessary in QUrl itself. Manipulation of the items should be done using the new class. They are now implemented using a temporary QUrlQuery. This is hardly efficient but it works. Change-Id: I34820b3101424593d0715841a2057ac3f74d74f0 Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
* Long live QUrlQueryThiago Macieira2012-03-302-0/+700
This class is meant to replace the QUrl functionality that handled key-value pairs in the query part of an URL. We therefore split the URL parsing code from the code dealing with the pairs: QUrl now only needs to deal with one encoded string, without knowing what it is. Since it doesn't know how to decode the query, QUrl also becomes limited in what it can decode. Following the letter of the RFC, queries will not encode "gen-delims" nor "sub-delims" nor the plus sign (+), thus allowing the most common delimiters options to remain unchanged. QUrlQuery has some undefined behaviour when it comes to empty query keys. It may drop them or keep them; it may merge them, etc. Change-Id: Ia61096fe5060b486196ffb8532e7494eff58fec1 Reviewed-by: Lars Knoll <lars.knoll@nokia.com>