Seaside request contexts and the Pharo debugger - solved wth a slight mystery

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Seaside request contexts and the Pharo debugger - solved wth a slight mystery

Schwab,Wilhelm K
Paul, all,

Thanks for the suggestion, but all appears to be well in Seaside (coming back to it after a while, I'm all the more impressed - it's a wonderful framework!).  Below is what I posted on the Pharo list.  It *has* to be some kind of Heisenbug in the Pharo debugger, or a bad interaction between same and Seaside.

When I first set out to load the files and create mime types to serve them dynamically (it's more than fast enough for what I need, takes no new configuration on target machines, does not bloat a file library (200MB of stuff!!!, but served in smallish pieces, hence dynamic mime is great for it).  End of sales pitch :)  The important thing is that it works!!!

Making a long story short, when I first went to create the mime document, I set a breakpoint at the top of a method called from my callback.  It has access to canvas and component, but inspecting

     component requestContext

would give a not-found error.  Let the code run past that, and all is well =:0  My code looks something like this:

serveFileNamed:fileName for:component canvas:html

    component session requestContext respond:[ :response |
        response
            document:self fullTextAsString
            mimeType:'application/pdf'
            fileName:fileName;
            doNotCache
    ]

which is called inside a callback for a "full text" anchor.  I can freely debug inside of #fullTextAsString, which was what I really needed to do because the paths were tricky to get right.

Success.  Thanks again!

Bill


=================
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.


--------------------------------

Paul DeBruicker [hidden email]
Fri Mar 16 16:26:22 UTC 2012
On 12-03-15 10:34 AM, Schwab,Wilhelm K wrote:
> .  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,


You can serve static files from disk with Comanche if you want.  See:

http://samadhiweb.com/blog/2011.07.10.seaside.comanche.staticfiles.html


for configuration ideas.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Seaside request contexts and the Pharo debugger - solved wth a slight mystery

Philippe Marschall
Am 17. März 2012 04:28 schrieb Schwab,Wilhelm K <[hidden email]>:
> Paul, all,
>
> Thanks for the suggestion, but all appears to be well in Seaside (coming
> back to it after a while, I'm all the more impressed - it's a wonderful
> framework!).  Below is what I posted on the Pharo list.  It *has* to be some
> kind of Heisenbug in the Pharo debugger, or a bad interaction between same
> and Seaside.

No, that's expected. The request context is in a thread local. Pharo
runs debugger evaluations in a different process so the value is not
there. Stepping should work fine though.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside