On 4 September 2012 20:35, 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! The code's part of a larger project that will hopefully
eventually allow interesting things like having a browser-based IDE
talking to an image, or having HTML-y inspectors attach to a remote
image for debugging/inspecting running services, etc. The first step
in any of those kinds of applications is permitting reflection of the
image, and JSON seems like a natural fit: many languages have JSON
parsers, it's not terrible to read from a human perspective, and so
on.

I hate announcing vapourware, so I haven't really spoken about it.

If you're interested in image inspection from outside the image, maybe
we can collaborate (as a start of which I should perhaps publish the
rest of the code!)

I really like the name Reflect-Core, so maybe what I should actually
do is just send you the original mczs, and you can fold it into
Reflect-Core?

frank

> Thanks,
> Chris
>
> http://ss3.gemstone.com/ss/Oakville/Reflect-Core-chc.3.mcz
>