Yes please Anthony, put me on the right path on github regarding wnd and JS
and I will commit more changes to the pull request.
Regarding your questions:
- Using JS because I am running some native javascript code. I do not
know how to do it differently, or whether this has any undesired side
effect.
- I am using eval here:
global_unique_change = "change_%s" % (self.myid)
setattr(wnd(),global_unique_change,self.change)
# Now bind the change event to the wnd().global_unique_change function,
which is actually self.change
myjs = 'parent.jQuery("#%s").bind("change", function() { parent.%s() });' %
(self.myid, global_unique_change)
wnd().change = self.change
myjs = '%s parent.jQuery("#%s").bind("change", show);' % (show, self.myid)
JS(""" eval(@{{myjs}}) """)
- because as you see my javascript code in the variable myjs has often
python variables (in this case the id of the html element that Select2 must
process). I was advised to use eval whenever the javascript code is not a
constant string (I was getting problems without eval)
- In the above code I am using wnd to make the method self.change
available for jQuery to bind the "change" event to it. Actually, I would
prefer to bind directly to self.change instead of using this double
redirection, but after lots of trying I could only get this working.
- finally I am using setattr because, instead of binding wnd().change
(which would cause conflict if several objects are instantiated) I need to
bind wnd().global_unique_variable. But since global_unique_variable is
taken as literal here, I need to to the setattr trick. Also not very
satisfied with it, but it is working.
Any improvements to my code are very much welcome!
Thanks,
Daniel
On Friday, July 13, 2012 12:16:25 AM UTC+2, peter.bittner wrote:
>
> Anthony,
>
> this is great input!
>
> Can you do us all a favor? Can you turn your knowledge into a code
> review on the pull request that Daniel just made? (actually yesterday)
> E.g. here:
> https://github.com/gonvaled/pyjs/commit/e91448f45ff74e6ebc0f4cd1256d2cac6c9e4879
>
> (You know how: clicking on the "+" speed bubble - and leaving a note -
> that, e.g., uses the "wnd()")
>
> This would make great into greater!
>
> Thanks, Anthony
>
>
> 2012/7/12 C Anthony Risinger <[email protected]>:
> > On Wed, Jul 11, 2012 at 4:08 PM, Daniel Gonzalez <[email protected]>
> wrote:
> >>
> >> Thanks istvan, this is working!
> >
> > i'm glad your getting it all working (and most certainly via the
> > 10,000 m/s crash course :-), as your threads are good testaments of
> > why, should these bidirectional interactions ever be supported, they
> > MUST pass thru a static, pre-defined, and well-established API,
> > residing outside-of-and-immune-to the translator feature settings (eg,
> > __setattr__). the alternatives appear riddled by
> > hard-to-track-and-mutually-exclusive bugs, explosive
> > incompatibilities, headaches, ultimately to the satisfaction of no one
> > (yikes, that came off more pessimistic than intended ... here is
> > another :-)!
> >
> > anyways, i simply noticed some calls to JS eval() in several of your
> > posted snippets -- why? i am quite certain you'll never need it ...
> > (if you do, well, {shudder}) just work with python normally 99% of the
> > time, and when you need to "cross-over", use the
> > @{{python-identifier-goes-here}} mechanism.
> >
> > be leery of wnd() and other quasi-types from __pyjamas__; these are
> > not general purpose python objects. make *every* operation explicit
> > (eg. `setattr` vs. relying on language features) and you will go much
> > further/faster, because most of the translator's `--enable-xyz`
> > options relate to (dis|en)abling various *implicit* language behaviors
> > easily performed by the python.org interpreter (__get__, __set__, etc,
> > etc), but difficult or expensive under pyjs.
> >
> > keep it up ... this time next year you'll be hacking on the core :-)
>
