Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSObject can't create a document when used with Comet #540

Open
GoogleCodeExporter opened this issue Mar 25, 2015 · 0 comments
Open

JSObject can't create a document when used with Comet #540

GoogleCodeExporter opened this issue Mar 25, 2015 · 0 comments

Comments

@GoogleCodeExporter
Copy link

On Tue, Jan 26, 2010 at 1:42 PM, John Chludzinski
<john.chludzinski@gmail.com> wrote:
> If I receive an external message (not a request from a browser) thru a
> socket telling me that all the presentation apps that share a particular
> Comet pusher need to advance to the next slide.  How should this best be
> done?
> My solution:  I saved a reference to one of the presentation apps and send
> it the message #nextPage (from a Workspace window).  This failed (got a
> walkback) in JSObject>>render:on: at
>       document := JSDocument on: aStream codec: self requestContext codec.
> Since 'codec' is never used in JSDocument I changed the line above to:
>       document := JSDocument on: aStream codec: #useless.
>
> This works BUT is it a reasonable approach?  Or is there a canonical
> solution to the problem of external events?
>
> ---John
>

Hi John,

Good question. Not a reasonable *approach* I'd say, but perhaps a
reasonable workaround. :)

I wouldn't know without looking at it further (which I can't do right
this second) but it seems like there's a general problem here. It may
be that the RenderContext needs to be given the codec (JSObjects hold
onto their RenderContext for later use, I think). Or maybe the
JSObject should cache it. But I'm not sure.

There are some fundamental issues around encodings that we haven't
been able to solve in 3.0 (might be a goal for 3.1?) so you may just
need to work around this for now. Or Lukas may have a better
suggestion...

If you're sticking with the work around, you might want to do
something like what WAUrl>>printOn: does, which will be a little more
robust, I guess (and maybe that should be rolled into Seaside for now
- again Lukas will have an opinion on that).

Julian

Original issue reported on code.google.com by jfitz...@gmail.com on 28 Jan 2010 at 1:35

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant