Re: [pyxpcom] Python Scripting Component/PyXPCOMInterprocessCommunication
by Ryan Sturmer other posts by this author
Jul 10 2007 10:04PM messages near this date
view in the new Beta List Site
Re: [pyxpcom] Python Scripting Component/PyXPCOMInterprocessCommunication
|
Re: [pyxpcom] Python ScriptingComponent/PyXPCOMInterprocessCommunication
I'm new to XPCOM as a whole, and not just PyXPCOM (can you tell?! :)) I
appreciate your patience. I'm going to go at this one more time, for the
sake of it, and then go hide and do some more reading If I still don't get
it. I apologize for the long winded explanations. They're more for me,
than anyone else:
The namespace of the javascript environment from which I create my pyshell
xpcom object is full of variables and methods that I can use to manipulate
the user interface of my program. (This is the whole fun of developing a
XUL based application right?) From the javascript within my XUL code I
have a DOM that I can access to manipulate the UI, I can call alert() to pop
up a javascript message, or say document.getElementById("my_image") and do
as I please (just to name a few examples). I have full access to the
elements that define my interface, and can access and modify them any way I
like.
My user, who is writing python code that is executed by my pyshell object,
has no such access to any of that functionality. He cant, from the python
environment I've provided for him, access any of the javascript functions of
my XUL application. His python script is passed to the exec function, (to
which I can provide global and local variables but currently don't) He can't
call upon the DOM to get elements in an HTML page, or call the javascript
alert() function, or do anything like that. He can only deal with the
globals and locals that I provide for him with the call to exec(), which
currently aren't anything at all.
Is there a mechanism by which I can selectively expose to him (via the
specification of specially crafted locals or globals to exec()) a means of
accessing functionality in that parent javascript environment. An example
might be, I'd like to allow my user code to exercise the javascript alert()
function, or say, change the text of a button in my user interface, or
change the window title, etc...
I understand how to write an XPCOM object, and invoke it from within the
python environment, but what I don't understand is how to "hook it up" so
that an object that I invoke from within the python environment actually
corresponds to the instance of the javascript environment that created it.
What I'm looking to have is a singleton, so that when I create an object,
whether in the javascript within my XUL application, or in the python user
code (which executes in the insulated world within my pyshell xpcom object)
it refers to the *same object*, say a user interface which I can access from
either place.
Again, thanks so much. I'll get this through my thick head eventually.
-R
On 7/10/07, Mark Hammond <mhammond@[...].au> wrote:
>
> > I guess the part that I'm missing is, that when I instantiate an xpcom
> object X
> > from javascript, that object represents an instance of executing python
> code.
> > If I instantiate an xpcom object Y from that python code, how do I
> arrange
> > it such that that object Y has access to variables in the environment
> that
> instantiated X?
>
> I'm not sure what you mean by "environment" here. If you just mean you
> want
> object Y to have the same set of globals as X, then the question is just
> related to Python and not at all related to xpcom. For example, having X
> and Y in the same module would achieve that, or usage of 'exec' will allow
> you to specify globals. Yet another work-around would be to create some
> object called, say, 'environment', and explicitly stash that in the
> globals
> of each module, allowing users to say, eg, 'environment.foo' from either
> module.
>
> Its important to remember that xpcom isn't really pulling any tricks at
> all - it just imports modules and fetches objects from them. So just ask
> how you would do it in "normal" Python, then apply it to this environment.
>
> Cheers,
>
> Mark
>
>
Thread:
Ryan Sturmer
Mark Hammond
Ryan Sturmer
Mark Hammond
Ryan Sturmer
Mark Hammond
Ryan Sturmer
Mark Hammond
Ryan Sturmer
|