Seaside image
Locked
 
|
Hello all,
I have started to resurrect some of my Seaside code (originally written for 2.8) in the Seaside downstream image for Pharo 1.3 (Seaside 3, I think??). I can't do anything with request contexts in the image. I can try loading Seaside myself in a new image, but I was wondering if anyone has seen this. Bill -----------------
I don't understand what you have been doing wrong. "WACurrenrRequestContext value" will always be available if you are inside a callback or rendering - virtually anywhere in Seaside. Wherever you have a WAComponent you can also send #session to it. On 15 March 2012 18:34, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote: > I am trying to create anchors that will "dynamically" serve pdf > documents. The archive in question is way too big for a FileLibrary and a > separate web server is probably overkill since I intend to do all of this > locally and would rather not have to run Apache on the machines in question > (security paranoia or laziness, take your pick<g>) . So, I was hoping to > create mime documents on the fly. > > I found suggestions such as: > > component session requestContext respond:[ :response | > response > document:self getPdfBytes > mimeType: 'application/pdf' > fileName: 'seaside-test.pdf'; > doNotCache > > I don't see #getPdfBytes, but suspect I can wing it given the file names > in anchors. > > The problem is that everything I ask for a requestContext feigns > ignorance. I can't even get #session because of the same error. I am > using Seaside 3 from the Pharo 1.3 image and Seaside downstream project. > > Any suggestions? > > Bill |
|
|
Update: I looked for tests using a request context and found WAInteractionTest; all test pass, and I was able to set a breakpoint and inspect a nice working request context. So
the it's not the downstream seaside image that is at fault.
Confused... I will admit to some creative use of rendering, but it's all done with "components" that have a #basicRenderContentOn:for: where the second argument is the component doing the rendering. The pieces are abstractions of bibtex (hence my interest in Citezen) entries that I didn't want to fully componentize because they can get very numerous with use. But I render (I *think*) by the rules and am asking what should be a valid canvas or component for the context. I'll keep looking. Bill From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]]
Sent: Friday, March 16, 2012 11:37 AM To: [hidden email] Subject: [Pharo-project] Seaside image
Hello all,
I have started to resurrect some of my Seaside code (originally written for 2.8) in the Seaside downstream image for Pharo 1.3 (Seaside 3, I think??). I can't do anything with request contexts in the image. I can try loading Seaside myself in a new image, but I was wondering if anyone has seen this. Bill -----------------
I don't understand what you have been doing wrong. "WACurrenrRequestContext value" will always be available if you are inside a callback or rendering - virtually anywhere in Seaside. Wherever you have a WAComponent you can also send #session to it. On 15 March 2012 18:34, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote: > I am trying to create anchors that will "dynamically" serve pdf > documents. The archive in question is way too big for a FileLibrary and a > separate web server is probably overkill since I intend to do all of this > locally and would rather not have to run Apache on the machines in question > (security paranoia or laziness, take your pick<g>) . So, I was hoping to > create mime documents on the fly. > > I found suggestions such as: > > component session requestContext respond:[ :response | > response > document:self getPdfBytes > mimeType: 'application/pdf' > fileName: 'seaside-test.pdf'; > doNotCache > > I don't see #getPdfBytes, but suspect I can wing it given the file names > in anchors. > > The problem is that everything I ask for a requestContext feigns > ignorance. I can't even get #session because of the same error. I am > using Seaside 3 from the Pharo 1.3 image and Seaside downstream project. > > Any suggestions? > > Bill |
|
|
In reply to this post by Schwab,Wilhelm K
Hello all,
This appears to be some type of Heisenbug. If I set a breakpoint in a callback, I can't do anything with request contexts - "not found" errors happen every time I try to evaluate code that should lead to one. BUT, if I let the code run past something like component requestContext or component session, all is well. I think I see how to proceed, which is to do my debugging "downstream" of the context access. Any ideas why that is necessary? Oddities include that the entire app runs out of a task. Bill From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]]
Sent: Friday, March 16, 2012 11:37 AM To: [hidden email] Subject: [Pharo-project] Seaside image
Hello all,
I have started to resurrect some of my Seaside code (originally written for 2.8) in the Seaside downstream image for Pharo 1.3 (Seaside 3, I think??). I can't do anything with request contexts in the image. I can try loading Seaside myself in a new image, but I was wondering if anyone has seen this. Bill -----------------
I don't understand what you have been doing wrong. "WACurrenrRequestContext value" will always be available if you are inside a callback or rendering - virtually anywhere in Seaside. Wherever you have a WAComponent you can also send #session to it. On 15 March 2012 18:34, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote: > I am trying to create anchors that will "dynamically" serve pdf > documents. The archive in question is way too big for a FileLibrary and a > separate web server is probably overkill since I intend to do all of this > locally and would rather not have to run Apache on the machines in question > (security paranoia or laziness, take your pick<g>) . So, I was hoping to > create mime documents on the fly. > > I found suggestions such as: > > component session requestContext respond:[ :response | > response > document:self getPdfBytes > mimeType: 'application/pdf' > fileName: 'seaside-test.pdf'; > doNotCache > > I don't see #getPdfBytes, but suspect I can wing it given the file names > in anchors. > > The problem is that everything I ask for a requestContext feigns > ignorance. I can't even get #session because of the same error. I am > using Seaside 3 from the Pharo 1.3 image and Seaside downstream project. > > Any suggestions? > > Bill |
|
|
In reply to this post by Schwab,Wilhelm K
Got it!! I am now serving pdfs from my local drive w/o a file library and w/o an external web server. All goes through finding the file, loading the bytes and wrapping it a mime
document.
Like I said, security paranoia or laziness - pick one, but it's what I wanted. There is *something* preventing me from being able to set a breakpoint and evaluating code that should result in a working request context. Setting breakpoints *after* the context is found does work. I was able to use the debugger to good effect in getting the mime document and file naming sorted out. Bill From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]]
Sent: Friday, March 16, 2012 11:37 AM To: [hidden email] Subject: [Pharo-project] Seaside image
Hello all,
I have started to resurrect some of my Seaside code (originally written for 2.8) in the Seaside downstream image for Pharo 1.3 (Seaside 3, I think??). I can't do anything with request contexts in the image. I can try loading Seaside myself in a new image, but I was wondering if anyone has seen this. Bill -----------------
I don't understand what you have been doing wrong. "WACurrenrRequestContext value" will always be available if you are inside a callback or rendering - virtually anywhere in Seaside. Wherever you have a WAComponent you can also send #session to it. On 15 March 2012 18:34, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote: > I am trying to create anchors that will "dynamically" serve pdf > documents. The archive in question is way too big for a FileLibrary and a > separate web server is probably overkill since I intend to do all of this > locally and would rather not have to run Apache on the machines in question > (security paranoia or laziness, take your pick<g>) . So, I was hoping to > create mime documents on the fly. > > I found suggestions such as: > > component session requestContext respond:[ :response | > response > document:self getPdfBytes > mimeType: 'application/pdf' > fileName: 'seaside-test.pdf'; > doNotCache > > I don't see #getPdfBytes, but suspect I can wing it given the file names > in anchors. > > The problem is that everything I ask for a requestContext feigns > ignorance. I can't even get #session because of the same error. I am > using Seaside 3 from the Pharo 1.3 image and Seaside downstream project. > > Any suggestions? > > Bill |
|
In reply to this post by Schwab,Wilhelm K
Hi Bill,
self session self requestContext etc won't work in the debugger as they are dynamic variables which use the exception mechanism to retrieve their value (search for references to WACurrentRequestContext)
If you are in the debugger and you need the session or the request context you can either follow the stack trace until you find a variable holding the session or request context or just add the following code to the method you are debugging and resume the debugger:
| theSession theRequestContext | . . . theSession := self session. theRequestContext := self requestContext. self halt.
--- Hope this helps Nick
|
|
|
In reply to this post by Schwab,Wilhelm K
Philippe, Nick,
Good enough: | theSession theRequestContext |
theSession := self session. theRequestContext := self requestContext. self halt. That's effectively what I did by debugging past the sends. Thanks for the explanation! Bill |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |