On 4 September 2012 21:25, Chris Cunnington
<smalltalktelevision at gmail.com> wrote:
> 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.

Cool! Attached. It's very preliminary stuff, I'll freely confess.

frank

>> frank
>>
>>> Thanks,
>>> Chris
>>>
>>> http://ss3.gemstone.com/ss/Oakville/Reflect-Core-chc.3.mcz
>>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Reflect-Core-fbs.1.mcz
Type: application/octet-stream
Size: 3531 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120906/4cd64a88/Reflect-Core-fbs.1.obj