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 smalltalktelevision@gmail.com 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
On 23 July 2012 21:37, Chris Cunnington smalltalktelevision@gmail.com 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 frank.shearar@gmail.com wrote:
On 23 July 2012 21:37, Chris Cunnington smalltalktelevision@gmail.com 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
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.
On 4 September 2012 19:08, Chris Cunnington smalltalktelevision@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
- 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.
- You don't need, with the newer Altitude, to add #initializeHandler in the
ALApplication subclass. As a default it was moved up to ALApplication.
- 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.
The SendersOf class definition needs an instvar #selector
Temporary variable not required in Workspace.
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.
- ParamLocator>>resourceForPath invokes ALPath>>second, which does not
exist. Added one:
ALPath>>second ^ self at: 2
- #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 smalltalktelevision@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
- 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.
- You don't need, with the newer Altitude, to add #initializeHandler in the
ALApplication subclass. As a default it was moved up to ALApplication.
- 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.
The SendersOf class definition needs an instvar #selector
Temporary variable not required in Workspace.
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.
- ParamLocator>>resourceForPath invokes ALPath>>second, which does not
exist. Added one:
ALPath>>second ^ self at: 2
- #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
On 4 September 2012 20:35, Chris Cunnington smalltalktelevision@gmail.com wrote:
On 12-09-04 3:24 PM, Frank Shearar wrote:
On 4 September 2012 19:08, Chris Cunnington smalltalktelevision@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
- 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.
- You don't need, with the newer Altitude, to add #initializeHandler in
the ALApplication subclass. As a default it was moved up to ALApplication.
- 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.
The SendersOf class definition needs an instvar #selector
Temporary variable not required in Workspace.
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.
- ParamLocator>>resourceForPath invokes ALPath>>second, which does not
exist. Added one:
ALPath>>second ^ self at: 2
- #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
On 12-09-04 3:43 PM, Frank Shearar wrote:
On 4 September 2012 20:35, Chris Cunnington smalltalktelevision@gmail.com wrote:
On 12-09-04 3:24 PM, Frank Shearar wrote:
On 4 September 2012 19:08, Chris Cunnington smalltalktelevision@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
- 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.
- You don't need, with the newer Altitude, to add #initializeHandler in
the ALApplication subclass. As a default it was moved up to ALApplication.
- 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.
The SendersOf class definition needs an instvar #selector
Temporary variable not required in Workspace.
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.
- ParamLocator>>resourceForPath invokes ALPath>>second, which does not
exist. Added one:
ALPath>>second ^ self at: 2
- #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
On 4 September 2012 21:25, Chris Cunnington smalltalktelevision@gmail.com wrote:
On 12-09-04 3:43 PM, Frank Shearar wrote:
On 4 September 2012 20:35, Chris Cunnington smalltalktelevision@gmail.com wrote:
On 12-09-04 3:24 PM, Frank Shearar wrote:
On 4 September 2012 19:08, Chris Cunnington smalltalktelevision@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
- 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.
- You don't need, with the newer Altitude, to add #initializeHandler
in the ALApplication subclass. As a default it was moved up to ALApplication.
- 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.
The SendersOf class definition needs an instvar #selector
Temporary variable not required in Workspace.
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.
- ParamLocator>>resourceForPath invokes ALPath>>second, which does not
exist. Added one:
ALPath>>second ^ self at: 2
- #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
On 12-09-06 12:43 PM, Frank Shearar wrote:
On 4 September 2012 21:25, Chris Cunnington smalltalktelevision@gmail.com wrote:
On 12-09-04 3:43 PM, Frank Shearar wrote:
On 4 September 2012 20:35, Chris Cunnington smalltalktelevision@gmail.com wrote:
On 12-09-04 3:24 PM, Frank Shearar wrote:
On 4 September 2012 19:08, Chris Cunnington smalltalktelevision@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
- 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.
- You don't need, with the newer Altitude, to add #initializeHandler
in the ALApplication subclass. As a default it was moved up to ALApplication.
- 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.
The SendersOf class definition needs an instvar #selector
Temporary variable not required in Workspace.
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.
- ParamLocator>>resourceForPath invokes ALPath>>second, which does not
exist. Added one:
ALPath>>second ^ self at: 2
- #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
Delightful. Thanks for this. Your code is helping me map the rooms.
Chris
On 9/4/12, Chris Cunnington smalltalktelevision@gmail.com wrote:
On 12-09-04 3:24 PM, Frank Shearar wrote:
On 4 September 2012 19:08, Chris Cunnington smalltalktelevision@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
- 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.
- You don't need, with the newer Altitude, to add #initializeHandler in
the ALApplication subclass. As a default it was moved up to ALApplication.
- 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.
The SendersOf class definition needs an instvar #selector
Temporary variable not required in Workspace.
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.
- ParamLocator>>resourceForPath invokes ALPath>>second, which does not
exist. Added one:
ALPath>>second ^ self at: 2
- #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
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
On Tue, Sep 4, 2012 at 12:35 PM, Chris Cunnington smalltalktelevision@gmail.com 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
squeak-dev@lists.squeakfoundation.org