On 9/4/12, Chris Cunnington <smalltalktelevision at gmail.com> wrote:
> On 12-09-04 3:24 PM, Frank Shearar wrote:
>> On 4 September 2012 19:08, Chris Cunnington
>> <smalltalktelevision at gmail.com> wrote:
>>> On 12-09-04 10:56 AM, H. Hirzel wrote:
>>>> Frank,
>>>>
>>>> It it correct to assume that you have released the code of your
>>>> Altitude application example
>>>>
>>>>      Serving JSON at Altitude
>>>>
>>>>      http://www.lshift.net/blog/2012/07/31/serving-json-at-altitude
>>>>
>>>> under MIT?
>> Yes, although I haven't mentioned it anywhere.
>>
>>>> --Hannes
>>> This is cool. I think it addresses my question of how do you get data
>>> from
>>> the model to the view. I should be looking at #withLocator:. I needed to
>>> change a few things to make it work for me.
>>>
>>> http://ss3.gemstone.com/ss/Oakville/Reflect-Core-chc.1.mcz
>>>
>>> I made some notes to help me try to puzzle things together. They are sort
>>> of
>>> a shed snake skin, but they may be useful.
>>>
>>> Chris
>>>
>>>
>>>
>>> 1. This uses an older version of Altitude, as it has ALLocator. That was
>>> removed for ALAbstractLocator to switch from using subclassing to the
>>> Strategy pattern. The ALLocator is likely more comprehensible to me
>>> anyway.
>>> To use ALLocator regress the install of the package AL-Application back
>>> to
>>> AL-Application-cwp.17.mcz.
>>>
>>> 2. You don't need, with the newer Altitude, to add #initializeHandler in
>>> the
>>> ALApplication subclass. As a default it was moved up to ALApplication.
>>>
>>> 3. I'm guessing in ParamLocator>>resourceForPath: that this:
>>>
>>> caseOf: {
>>>                  ['senders-of'] ->
>>>                      [(SendersOf reflecting: aPath second asSymbol)
>>> asResource].
>>>              otherwise: [ALNotFound signal: aPath printString].
>>>
>>> might actually be this:
>>>
>>> caseOf: {
>>>                  ['senders-of'] ->
>>>                      [(SendersOf reflecting: aPath second asSymbol)
>>> asResource]}
>>>              otherwise: [ALNotFound signal: aPath printString].
>>>
>>> The period at the end of the #asResource block is stepping on the
>>> #caseOf:otherwise: selector. And a subsequent second $} is missing.
>>>
>>> 4. The SendersOf class definition needs an instvar #selector
>>>
>>> 5. Temporary variable not required in Workspace.
>>>
>>> 6. The destination URL is http://localhost:9090/implementors-of/today but
>>> in
>>> ParamLocator>>resourceForPath: we have 'senders-of' so perhaps the URL
>>> should be http://localhost:9090/senders-of/today.
>>>
>>> 7. ParamLocator>>resourceForPath invokes ALPath>>second, which does not
>>> exist. Added one:
>>>
>>> ALPath>>second
>>>      ^ self at: 2
>>>
>>> 8. #setName in SendersOf>>renderOn: suggests an instvar, but replace it
>>> with
>>> the string 'senders-of', which seems to do the trick.
>> I'm glad someone took the trouble to look so closely at the code, and
>> a bit embarrassed at all the problems. The reason for the problems is
>> simple: the code's hacked out of a fledgling project, and clearly I
>> didn't pay close enough attention to ensure the bits made sense ripped
>> out of their context. (SendersOf and its sibling Implementors of are
>> subclasses of something else that introduces the selector instvar.
>>
>> frank
>>
>
> I'm pleased you're not offended by my picayune observations. This is
> quite a useful demo for me to better understand Altitude and the
> Strategy pattern. I can see now that people are supposed to write
> locator classes as subclasses of ALAbstractLocator as needed, which is
> what the blog post shows. Once I saw what was supposed to happen it was
> simple to change it to work with the latest version of Altitude. Great
> blog post.
>
> Thanks,
> Chris
>
> http://ss3.gemstone.com/ss/Oakville/Reflect-Core-chc.3.mcz
>
>
Amazing how compact the code is. Only three classes with 8 methods
alltogether (instance and class side in all of the three classes).

Elegant.

--Hannes