On 12-09-04 3:43 PM, Frank Shearar wrote:
> 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!)
This sounds cool. I'd like to participate.
>
> 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?
I'd like to look at them, for sure.
> frank
>
>> Thanks,
>> Chris
>>
>> http://ss3.gemstone.com/ss/Oakville/Reflect-Core-chc.3.mcz
>>