Marc Hadley wrote:
> On Aug 14, 2007, at 2:53 PM, Marc Hadley wrote:
>>
>>>> Is it likely that a developer would mix encoded/decoded space per a
>>>> UriBuilder or would a UriBuilder be used consistently in encoded or
>>>> decoded space?
>>>> This is not an assumption we should force from the framework. How
>>>> about the builder bootstrap itself, something like:
>>>> URIBuilder.create(ENCODED)...
>>>
>>> I was more thinking along the lines that each static method would
>>> have an 'encode' boolean parameter that defaults to true.
>>>
>> That would certainly deliver a simpler API provided the assumption
>> about not mixing encoded and decoded in the same builder is valid.
>> What do other folks think, is this a reasonable assumption ?
>>
> Rather than fixing whether the builder encodes at builder creation time
> we could allow enabling/disabling encoding at any point in the build,
> e.g.: with baseURI=http://example.com/base
>
> URI uri = UriBuilder.fromURI(baseURI).path("a
> b").encode(false).path("c%20d").build()
>
> would make uri
>
> http://example.com/base/a%20b/c%20d
>
> This would allow us to drop the other 9 methods with the encode
> parameter which seems like a worthwhile simplfication.
>
+1
As part of the UriBuilder implementation we will need to write
context-specific (path, query etc) character validation, and encode
methods. This is because there is insufficient public accessible
functionality in java.net.* and URI. How about we expose validation,
encode and decode as general methods?
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109