Marc Hadley wrote:
> Here are three questions related to UriBuilder[1] we'd like some input on:
>
> (i) Setting automatic encoding status from the UriTemplate.encode property
>
> The fromResource(Class), path(Class) and path(Method) all point
> (indirectly) to a UriTemplate from which the value is extracted. You can
> specify whether a UriTemplate value should be automatically encoded via
> the encode property. Similarly you can control automatic encoding by the
> builder using the encode method. When adding the value of a UriTemplate
> to a UriBuilder it makes sense to use the value of UriTemplate.encode to
> determine whether encoding is required or not. The question is whether
> the value of UriTemplate.encode should stick with the UriBuilder or not.
>
> On the one hand it seems convenient to have the value of the template
> encode stick with the builder - if an application is written in "encoded
> space" (i.e. encode=false) then its likely that other strings will also
> already be encoded so forcing the developer to write the extra
> .encode(false) seems wrong.
>
> On the other hand, if the template encode value sticks with the builder,
> then toggling a UriTemplate.encode value will also require a change to
> all uses of that template within a builder and could lead to unexpected
> bugs if any occurrences are missed.
>
> I'm not sure which is the lesser of the two evils.
>
It is possible that developers may write resources that are designed to
be inherited from or reused. In such cases the application may be
written independently of the "encoded space" of what it is reusing. So,
potentially, application code may break if updating to a new compatible
version of a dependent framework, which is very evil.
Even in cases where there is one application complex (e.g. like Hudson)
with multiple developers hacking away at the code could cause nasty
headaches if changes occur.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109