From: Rimon B. <ba...@cs...> - 2003-09-24 06:21:59
|
><RANT> >I have one major problem with taglibs in spyce: the context for taglibs >and the context for the page are *different*. What's the reasoning >here? This means if you set a variable in the page you can't access it >in the taglib context. To work around this, you currently have to code >the following: > >[[ taglib.context('x') = 1 ]] ><spy:print val="=x"/> > >New users won't understand what taglib.context() means. In any case, I >think it's less than optimal. I'd rather it be: > >[[ x = 1 ]] ><spy:print val="=x"/> > >I've emailed Rimon about this one, but we haven't reached any >conclusion on it yet. When I (and he) get some time, I'm going to take >it up with him. :) I'd like to see his reasoning in making the two >context's different. I might even change the code to use the same >context and see how it works. To me, this is one of the major >drawbacks of spyce right now. It throws new users to Spyce off when >variables don't carry from one place to another. ></RANT> Hi Conan, As always, I appreciate your comments and support. I actually completely agree with this rant, and would have wanted to design the Spyce tags this way. In fact, I still wish that I could find a way to implement it, but, according to my understanding of Python, it is simply not possible -- unless we come up with a radically different execution model. The reason stems from a fundamental deficiency -- I think -- in Python. Let me explain... When you run a Spyce script, you're actually first compiling it to Python, and then running the Python code. The entire Spyce script becomes a method in a Python module. (The method is called spyceProcess(), FYI). When you write [[ x = 5 ]] in your Spyce script, then that becomes an: x = 5 within this method. In other words, 'x' is a local. Now, here's the catch. You can look at the locals dictionary (using the locals() built-in function), just like you can look at the globals. However, the locals dictionary is read-only. So, I could pass you the "context" of the Spyce script (all the locals), for you to use in the Spyce tag libraries that you write, but you'll never be able modify this context. I know that's it's clumsy, but I have no other choice other than to put the onus on the tag library developer and somewhat on the tag library user by creating an explicit secondary context for the tags. The Python documentation is explicit about the locals() restriction. See: http://www.python.org/doc/2.2.3/lib/built-in-funcs.html#l2h-40 Moreover, I have emailed Guido about this, and he has confirmed that it will most likely remain this way. So, Conan, that's the reasoning behind this kludge. Can we think of some way around it? Perhaps we should compile the entire Spyce script within a class rather than within a function, or straight into a module without any nested structure. That will likely remove the current dependency on locals(), though it might introduce some new problems. I remember going through a similar thought process when I first designed the Spyce compilation. Back then I was quite interested in having start() and finish() code for each request. They don't seem to be used at all. Also, I was very constrained by the need to work within Python 1.5. Perhaps we can relax this constraint as well. All the best, Rimon. |