http://yellow.16r.ca
http://blue.16r.ca http://alt.16r.ca http://www.osrcon.ca/AL-Examples.st http://reversehttp.net/index.html http://reversehttp.net/relay-http-spec.html I have three sites here. The first two are the same class (GNHelloWorld) served from different environments of a single image. I tried to load Altitude into the Environments image and it will not go in no way no how. WebClient and GreenNeon do, though, using Monticello. The third site is a quick Altitude site. The movie appears for me in Chrome and Safari, but not in Firefox or Opera. The gray gradients work and don't work in the same browsers. You will notice the Counter Page link, which when you roll over it creates a suitable url. It does not work. Altitude's relationship between paths and resources is very versatile and I haven't got the hang of it yet. So I can't link to the other page. Works on localhost ... Xtreams from the 2010 ESUG video I watched has this ability to layer/stack streams. This makes encoding trivial. It's impressive. Altitude has things called endpoints and relays (not to be confused with terminals and transforms), which I think point to the main purpose of Altitude - remote messaging. For surgery on an image to pare it down megabyte by megabyte. Or, consider an image as a single object. Then the image/objects send each other messages in the cloud. No polling. Pushing. As described by Tony Garnock Jones. TGJ's pages on the topic is linked above. As well as the code I used for the alt.16r.ca site. From the vantage point of Altitude's main purpose being remote messaging, websites are incidental. Chris |
On 2012-07-23, at 1:38 PM, Chris Cunnington
<[hidden email]> wrote: > The third site is a quick Altitude site Why don't we set up a G+ Hangout and go over creating a simple Altitude app? That would probably be more efficient than trial-and-error over email. Colin |
In reply to this post by Chris Cunnington
On 23 July 2012 21:37, Chris Cunnington <[hidden email]> wrote:
> http://yellow.16r.ca > http://blue.16r.ca > http://alt.16r.ca > > http://www.osrcon.ca/AL-Examples.st > > http://reversehttp.net/index.html > http://reversehttp.net/relay-http-spec.html > > I have three sites here. The first two are the same class (GNHelloWorld) > served from different environments of a single image. I tried to load > Altitude into the Environments image and it will not go in no way no how. > WebClient and GreenNeon do, though, using Monticello. > > The third site is a quick Altitude site. The movie appears for me in Chrome > and Safari, but not in Firefox or Opera. The gray gradients work and don't > work in the same browsers. > > You will notice the Counter Page link, which when you roll over it creates a > suitable url. It does not work. Altitude's relationship between paths and > resources is very versatile and I haven't got the hang of it yet. So I can't > link to the other page. Works on localhost ... > > Xtreams from the 2010 ESUG video I watched has this ability to layer/stack > streams. This makes encoding trivial. It's impressive. > > Altitude has things called endpoints and relays (not to be confused with > terminals and transforms), which I think point to the main purpose of > Altitude - remote messaging. For surgery on an image to pare it down > megabyte by megabyte. Or, consider an image as a single object. Then the > image/objects send each other messages in the cloud. No polling. Pushing. > As described by Tony Garnock Jones. I'm heading this way in my own hacking, so I guess I should plant a flag and say that when I've finished my current hack I'll be trying to provide "remote browser reflection" on an image: permitting external entities to introspect on (and later, to alter) a running image by serving up JSON from a RESTful API. I was originally going to just use JSON and roll a dispatching mechanism myself, but Altitude ought to provide a more standard mechanism for that, and one I don't have to write myself. frank > TGJ's pages on the topic is linked above. As well as the code I used for the > alt.16r.ca site. From the vantage point of Altitude's main purpose being > remote messaging, websites are incidental. > > Chris > > > > > |
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? --Hannes On 7/24/12, Frank Shearar <[hidden email]> wrote: > On 23 July 2012 21:37, Chris Cunnington <[hidden email]> > wrote: >> http://yellow.16r.ca >> http://blue.16r.ca >> http://alt.16r.ca >> >> http://www.osrcon.ca/AL-Examples.st >> >> http://reversehttp.net/index.html >> http://reversehttp.net/relay-http-spec.html >> >> I have three sites here. The first two are the same class (GNHelloWorld) >> served from different environments of a single image. I tried to load >> Altitude into the Environments image and it will not go in no way no how. >> WebClient and GreenNeon do, though, using Monticello. >> >> The third site is a quick Altitude site. The movie appears for me in >> Chrome >> and Safari, but not in Firefox or Opera. The gray gradients work and >> don't >> work in the same browsers. >> >> You will notice the Counter Page link, which when you roll over it creates >> a >> suitable url. It does not work. Altitude's relationship between paths and >> resources is very versatile and I haven't got the hang of it yet. So I >> can't >> link to the other page. Works on localhost ... >> >> Xtreams from the 2010 ESUG video I watched has this ability to >> layer/stack >> streams. This makes encoding trivial. It's impressive. >> >> Altitude has things called endpoints and relays (not to be confused with >> terminals and transforms), which I think point to the main purpose of >> Altitude - remote messaging. For surgery on an image to pare it down >> megabyte by megabyte. Or, consider an image as a single object. Then the >> image/objects send each other messages in the cloud. No polling. >> Pushing. >> As described by Tony Garnock Jones. > > I'm heading this way in my own hacking, so I guess I should plant a > flag and say that when I've finished my current hack I'll be trying to > provide "remote browser reflection" on an image: permitting external > entities to introspect on (and later, to alter) a running image by > serving up JSON from a RESTful API. > > I was originally going to just use JSON and roll a dispatching > mechanism myself, but Altitude ought to provide a more standard > mechanism for that, and one I don't have to write myself. > > frank > >> TGJ's pages on the topic is linked above. As well as the code I used for >> the >> alt.16r.ca site. From the vantage point of Altitude's main purpose being >> remote messaging, websites are incidental. >> >> Chris >> >> >> >> >> > > |
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? > > --Hannes 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. |
On 4 September 2012 19:08, Chris Cunnington
<[hidden email]> 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 |
On 12-09-04 3:24 PM, Frank Shearar wrote:
> On 4 September 2012 19:08, Chris Cunnington > <[hidden email]> 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 |
On 4 September 2012 20:35, Chris Cunnington
<[hidden email]> wrote: > On 12-09-04 3:24 PM, Frank Shearar wrote: >> >> On 4 September 2012 19:08, Chris Cunnington >> <[hidden email]> 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 > |
On 12-09-04 3:43 PM, Frank Shearar wrote:
> On 4 September 2012 20:35, Chris Cunnington > <[hidden email]> wrote: >> On 12-09-04 3:24 PM, Frank Shearar wrote: >>> On 4 September 2012 19:08, Chris Cunnington >>> <[hidden email]> 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? I'd like to look at them, for sure. > frank > >> Thanks, >> Chris >> >> http://ss3.gemstone.com/ss/Oakville/Reflect-Core-chc.3.mcz >> |
In reply to this post by Chris Cunnington
On 9/4/12, Chris Cunnington <[hidden email]> wrote:
> On 12-09-04 3:24 PM, Frank Shearar wrote: >> On 4 September 2012 19:08, Chris Cunnington >> <[hidden email]> 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 > > alltogether (instance and class side in all of the three classes). Elegant. --Hannes |
In reply to this post by Chris Cunnington
On 4 September 2012 21:25, Chris Cunnington
<[hidden email]> wrote: > On 12-09-04 3:43 PM, Frank Shearar wrote: >> >> On 4 September 2012 20:35, Chris Cunnington >> <[hidden email]> wrote: >>> >>> On 12-09-04 3:24 PM, Frank Shearar wrote: >>>> >>>> On 4 September 2012 19:08, Chris Cunnington >>>> <[hidden email]> 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 >> frank >> >>> Thanks, >>> Chris >>> >>> http://ss3.gemstone.com/ss/Oakville/Reflect-Core-chc.3.mcz >>> > > Reflect-Core-fbs.1.mcz (4K) Download Attachment |
On 12-09-06 12:43 PM, Frank Shearar
wrote:
Delightful. Thanks for this. Your code is helping me map the rooms.On 4 September 2012 21:25, Chris Cunnington [hidden email] wrote:On 12-09-04 3:43 PM, Frank Shearar wrote:On 4 September 2012 20:35, Chris Cunnington [hidden email] wrote:On 12-09-04 3:24 PM, Frank Shearar wrote:On 4 September 2012 19:08, Chris Cunnington [hidden email] 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.--HannesThis 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. frankI'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. frankfrankThanks, Chris http://ss3.gemstone.com/ss/Oakville/Reflect-Core-chc.3.mcz Chris |
In reply to this post by Chris Cunnington
On Tue, Sep 4, 2012 at 12:35 PM, Chris Cunnington
<[hidden email]> wrote: > 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. Hi guys, I'm a little late to respond here, as I've been on vacation. :-) I've gone back and forth on this a couple of times. The first iteration had multiple Locator classes, but I didn't bother to have an abstract superclass because only #pathForResource: and #resourceForPath: are actually needed. Then I came up with a away to factor out the commonality into a single class called ALLocator, which would be customized by various strategies. But the very first time I needed to customize the way urls are constructed, I found the strategy patterned didn't give me the flexibility I needed. So now we both options. ALAbstractLocator shows what protocol locators are expected to support. ALDigestLocator provides a default implementation, which can be customized via strategies. In cases where we want more customization than ALDigestLocator allows, we can create an alternate concrete locator class. Colin |
Free forum by Nabble | Edit this page |