Equivalent to window
Matt Mower
Just coming back to using JSCocoa after some time and, of course, all
knowledge has evaporated.
I'm looking to provide some jQuery style functions for scripting my
app which I want to be globally available. Taking a look at the jQuery
source code I notice they are using 'window' as a global context for
the browser session.
Is there an equivalent global context object in JSCocoa to which I can
attach functions such as '$' ?
Thanks,
Matt
--
Matt Mower :: http://mattmower.com/
Patrick Geiller
Matt Mower
> Just use 'this' in the global scope. In a webpage's global scope, 'this' and
> 'window' are two different names for the global object (alert(this==window)
> will return true)
Ah, sweet. Thanks Patrick.
Are you aware of any components/frameworks for syntax aware JS editing
that I could embed?
I'm also interested in what kind of debugging support might be
available, any thoughts about that?
Matt Mower
On Thu, Oct 1, 2009 at 12:03 AM, Patrick Geiller <parm...@gmail.com> wrote:
> Just use 'this' in the global scope. In a webpage's global scope, 'this' and
> 'window' are two different names for the global object (alert(this==window)
> will return true)
I've just realised this isn't quite what i want. In a browser each
window provides it's own global context. In my app I have one JSCocoa
sharedController instance but that is creating a global context over a
range of "documents".
This means that my $ function can't make inferences about where to
look for certain things.
It occurs to me that I might be able to do this by creating a scope
for each document within which the $ function is defined related to
that scope. I guess I would then need to use bind to call my
Javascript callback function in the context of the appropriate scope
object.
Looking at my use of callJSFunction it's not clear to me how I'd use
bind to set the scope of the function call.
Does what I'm saying (even broadly) make sense? And, if so, do you
have any advice about how I can implement this?
Ian Beck
Not sure if this is really applicable to your scenario, but for my
Spice plugin for Espresso, I use a Javascript wrapper to load in
individual plugin files that makes handling scope a lot easier.
Basically, the Objective-C code loads up my bootstrapping function
using callJSFunctionNamed:withArguments: and passes specific data
about the current context via the arguments. The bootstrapping
function then configures standard global variables, loads the plugin
file into a generic function to keep it in its own scope, and then
executes the main function of the plugin file (if there is one). You
could presumably do something similar, using the bootstrapping
function to configure the specific scope variables that need to be
available to your plugins. The whole process was inspired by Narwhal
and its Server.js modular approach to handling Javascript, and the
benefit would be that you could then use things like binding and so
forth a lot easier than trying to do it straight from Objective-C.
For reference, here's the specific line where I'm loading in the
plugin file to a generic function (SpiceController is a globally
available object I setup with JSCocoa so I could make use of file I/O
and so forth):
http://github.com/onecrayon/Spice-sugar/blob/master/Support/Library/bootstrap_Spice.js#L71
The rest of the bootstrapping file is probably too specific to my
project to be much use to you, but hopefully that'll give you some
idea of what the heck I'm talking about. :-)
Good luck! I'd be interested to hear if you come up with an
alternative for handling scope in JSCocoa-loaded Javascript plugins.
Ian
Gus Mueller
> Are you aware of any components/frameworks for syntax aware JS editing
> that I could embed?
Feel free to lift the stuff from JSTalk:
http://github.com/ccgus/jstalk
It's got a little editor which does the syntax coloring. Let me know
if you make any improvements :)
-gus
--
August 'Gus' Mueller
Flying Meat Inc.
http://flyingmeat.com/
Matt Mower
> Feel free to lift the stuff from JSTalk:
> http://github.com/ccgus/jstalk
>
> It's got a little editor which does the syntax coloring. Let me know
> if you make any improvements :)
>
Awesome Gus, thank you.
Matt.
Matt Mower
On Thu, Oct 1, 2009 at 1:32 AM, Ian Beck <george...@gmail.com> wrote:
> Not sure if this is really applicable to your scenario, but for my
> Spice plugin for Espresso, I use a Javascript wrapper to load in
> individual plugin files that makes handling scope a lot easier.
> Basically, the Objective-C code loads up my bootstrapping function
> using callJSFunctionNamed:withArguments: and passes specific data
> about the current context via the arguments. The bootstrapping
> function then configures standard global variables, loads the plugin
> file into a generic function to keep it in its own scope, and then
> executes the main function of the plugin file (if there is one). You
I've been thinking it over and I'm concerned that my app is also
multi-document and there is threading involved.
I can't remember now whether JSCocoa supports access from multiple
threads. I recall when I was using MacRuby I had to switch all my
callbacks to the main thread due to crash issues there... not sure if
I switched things back.
It occurs to me that the safest approach might be to use a separate
JSCocoa instance for each document which will also solve the scope
issue.
Alternatively I could rip out multi-document which hasn't turned out
to be very useful in this app.
Thanks for the suggestions. I have some puzzling to do :)
m.
Patrick Geiller
Hi Matt,
* Regarding the scope from multiple instances : do you need to worry
about that ? Why not create your '$' function in each one of your
documents ?
* Threading : JSCocoa isn't thread safe. I don't think it'd crash, but
you might get errors of undefined objects. I need to fix this.
* Sharing js stuff between multiple contexts : starting from Safari 4,
there is the concept of concept groups which I think I must use (use
JSGlobalContextCreateInGroup for each dependant context, in your case
each document context). But then I don't remember what data you need
to share data across contexts ? Maybe Ian's method would be the
simplest ? Have one context, with each document having its own scope.
-Patrick
Matt Mower
> * Regarding the scope from multiple instances : do you need to worry
> about that ? Why not create your '$' function in each one of your
> documents ?
>
Thanks for clarifying these issues Patrick.
But in order for the function to be globally available it needs to be
attached to the global object, no? If I put it in the document then I
will have to reference it via a document instance which is certainly
possible but less succinct. Or am I missing something?
I confess my JS knowledge is rather pedestrian.
> * Threading : JSCocoa isn't thread safe. I don't think it'd crash, but
> you might get errors of undefined objects. I need to fix this.
>
Okay. I suspect I probably didn't go back to multi-threading since
I've not had any crashes. However I've not made much use of it either
because it hasn't turned out to be as convenient as I'd hoped.
That's largely because any errors in the script aren't easily managed
from within the app.
> * Sharing js stuff between multiple contexts : starting from Safari 4,
> there is the concept of concept groups which I think I must use (use
> JSGlobalContextCreateInGroup for each dependant context, in your case
> each document context). But then I don't remember what data you need
> to share data across contexts ? Maybe Ian's method would be the
> simplest ? Have one context, with each document having its own scope.
>
Actually it's the reverse I don't want to share anything between
documents, I want - essentially - the browser case of each document
being entirely independent.
I'm actually thinking about dumping multiple documents altogether.
When I started building Elysium I made it multi-document because my
previous two apps I hadn't and I ended up regretting it and having to
retrofit it.
But multi-document has never, in practice, made much sense in Elysium.
It might considerably simplify things to get rid of it. But it would
be quite a wrench code wise.
I want to take a look at Gus' code this evening and try and steal his
editor (at the moment I use a plain text view). I'd also like to have
some smarter error trapping and debugging facility. Not sure what's
possible there.
Still I now actually need this in earnest so it's time to knuckle down
and figure it all out.
Thanks again.
Matt
Patrick Geiller
> attached to the global object, no? If I put it in the document then I
> will have to reference it via a document instance which is certainly
> possible but less succinct. Or am I missing something?
I meant if you give document its own JSCocoa instance, you can just
load the same '$' function in each. (Just call evalJSFile('$.js') on
each)
> Okay. I suspect I probably didn't go back to multi-threading since
> I've not had any crashes. However I've not made much use of it either
> because it hasn't turned out to be as convenient as I'd hoped.
>
> That's largely because any errors in the script aren't easily managed
> from within the app.
Yes, handling script errors can be a pain, all the more if it's
multithreaded. And right now, don't use multithreading in JSCocoa.
> Actually it's the reverse I don't want to share anything between
> documents, I want - essentially - the browser case of each document
> being entirely independent.
OK, then no problem. Just use a different JSCocoa instance for each
document. This way you don't have to worry about sharing stuff, each
one is independant and has its own global object and data.
> But multi-document has never, in practice, made much sense in Elysium.
> It might considerably simplify things to get rid of it. But it would
> be quite a wrench code wise.
Be careful to not regret it again ! Given that you're building a music
synthesizer, having two documents open - like a tutorial document and
the document you're working on - can be very useful. You should keep
documents around.
> I want to take a look at Gus' code this evening and try and steal his
> editor (at the moment I use a plain text view). I'd also like to have
> some smarter error trapping and debugging facility. Not sure what's
> possible there.
Ok ! Also check out Gus' error handling code : (via a delegate method)
http://github.com/ccgus/jstalk/blob/master/src/JSTDocument.m#L187
Right now there's no debugging support, but you can have the line and
description of last error.
-Patrick