On 14 December 2012 23:20, Chris Cunnington
<smalltalktelevision at gmail.com> wrote:
> On 2012-12-14 4:43 PM, Frank Shearar wrote:
>>
>> Should ALPath decode a request's path?
>>
>> In particular, I'm mucking around again with reflecting images with
>> Altitude, and send a GET to
>> http://127.0.0.1:9090/organization/classes-in/Graphics-Display%20Objects
>>
>> I'd expected the resulting ALPath such that path third =
>> 'Graphics-Display Objects', but it's actually path third =
>> 'Graphics-Display%20Objects'.
>
> You're first string cannot be used as a url. The %20 gets added to fill the
> space. It's there because 'as is' your string cannot be used in a url. Added
> to which, if you are presenting classes from an image, you have an unusual
> resource. Perhaps you should create a new kind of resource for that (i.e.
> ALImageClassResource  as opposed to ALFormResource, ALHtmlResource,
> ALCallbackResource, ALJSONResource)?

I know why the %20 appears - because I (have to) URL encode things
that go into a URL. My point is that I'd expected the parser to
un-escape percent-encoded URL parts, because that encoding is part of
how HTTP works, not part of how the application works. (But I suppose
that the current behaviour is symmetrical: you have to encode strings
yourself, and you have to decode strings yourself.)

I use ALJsonResource instances, actually. I don't surface the classes
directly: I'm basically (re-)implementing SystemOrganizer's and
ClassOrganizer's APIs locally, and serving up chunks of strings
remotely. For instance,

ReflectedSystemCategories >> renderSystemCategoriesOn: json
	json object: [
		json name: 'type' value: 'system-categories'.
		json name: 'category-names' array: [
			SystemOrganizer default categories do: [:cat |
				json value: cat]]]

(I'm trying out the idea of faking these APIs to turn a Browser
(subclass) into a RemoteBrowser. Sort've a follow-on/extension of
Reflect-Core's experiment. First thing to note: you really want to
memoize the calls, because Browser makes A LOT of calls to the
organizers - every time it renders itself, in fact.)

frank

> At any rate, I sort of think that what you want to change should be before
> things go 'into the pipe' or afterwards. In your application, as opposed to
> the framework.
>
> Just a thought,
> Chris
>
>
>>
>> >From my reading of RFC 3986 [1], especially sections 2.5 and 7.3, it
>> seems like (a) it's up to the scheme definition as to how to encode
>> things (beyond encoding reserved characters) and that (b) usually
>> that's string -> utf-8 -> %-encoding.
>>
>> What do you think? Should ALPath (or ALHttpParser during construction
>> of same) be responsible for shielding the application from the
>> vagaries of HTTP's encoding rules?
>>
>> frank
>>
>> [1] http://tools.ietf.org/html/rfc3986
>>
>
>