http://www.zope.org/Wikis/zope-dev/MethodGeddon Just been reading about this and I was wondering how is coming along... Is it in the fishbowl under another name or should it be in the fishbowl? Shane, would the argument list be a management tab for methods? That sounds cool to me :-) I reckon 'self' should always be the equivalent of the python 'self' or not exist to avoid confusion. I guess that means it wouldn't get used much since it would be the actual method-object (and I thought that was an oxymoron ;-) but with the possibility opf things like __render__ and __call__, who knows... The argument list would be great, 'cos you could then be able to specify additional arguments of type 'binding' which might be any of the following from you list: (select by dropdown? ;-)
Bind to the object containing a method,
Bind to the object that acquired a method, and possibly
Bind to the object containing the method in the context of the object that acquired the method, and maybe even
When a method is defined in a ZClass, bind to the instance in such a way that attribute lookup is performed in the baseclasses of the class defining the method (aka bind to "super").
So you could get to any or all of those as you need in your method. Of course, new users wouldn't have to worry about this until they needed to do something that used it. The other option would be to have these automatically bound to certain names (like _ is now) but perhaps that would be more confusing? Thoughts and comments would be great :-) cheers, Chris
Chris Withers wrote:
http://www.zope.org/Wikis/zope-dev/MethodGeddon
Just been reading about this and I was wondering how is coming along...
After more pondering I decided to throw out the idea for typed arguments. I was trying to solve a difficult problem with a roundabout, and in the end more difficult solution.
Is it in the fishbowl under another name or should it be in the fishbowl?
It would actually fall under the the "Current Projects" section. http://dev.zope.org/Wikis/DevSite/Projects/PythonMethods/MethodObjectInterfa... Alright, I didn't put it my comments in exactly the right place, but it's close enough. :-)
Shane, would the argument list be a management tab for methods? That sounds cool to me :-)
What I have done instead (and this is exactly the way Jim envisioned it months ago) is added a "Bindings" tab to Python methods. You just fill in the names to be populated with an object's container, its context, itself, the DTML namespace, and (this just in :-) the traversal subpath. Then I did the same thing with External Methods and combined them into one product. Unless my changes are vetoed, in the future you won't be adding "External Methods" and "Python Methods" anymore, you'll be adding "Python Method (Internal)" and "Python Method (External)" instead. I've checked it all into CVS but I'm not sure it's available to the public. Perhaps it should be; lobby Ken or Brian. It's the module Packages/Products/PythonMethod.
I reckon 'self' should always be the equivalent of the python 'self' or not exist to avoid confusion. I guess that means it wouldn't get used much since it would be the actual method-object (and I thought that was an oxymoron ;-) but with the possibility opf things like __render__ and __call__, who knows...
Jim solved this confusion by letting you invent your own names, then we made it easier to use by providing "recommended names": container, self, m_self (the method object), _, and traverse_subpath. Now, the bindings still aren't available to DTML methods. But it shouldn't be difficult to add.
... So you could get to any or all of those as you need in your method. Of course, new users wouldn't have to worry about this until they needed to do something that used it.
Right. An important feature. Shane
Shane Hathaway wrote:
http://www.zope.org/Wikis/zope-dev/MethodGeddon
Just been reading about this and I was wondering how is coming along...
After more pondering I decided to throw out the idea for typed arguments. I was trying to solve a difficult problem with a roundabout, and in the end more difficult solution.
I thought that's what the following proposal was all about? :S http://dev.zope.org/Wikis/DevSite/Proposals/DTMLExpressionSyntax The idea being to have the form: <dtml-TAGNAME ATTRIBUTE-FORMAT="VALUE"> instead where FORMAT is in effect the type... ...or have I got that wrong?
Is it in the fishbowl under another name or should it be in the fishbowl?
It would actually fall under the the "Current Projects" section.
http://dev.zope.org/Wikis/DevSite/Projects/PythonMethods/MethodObjectInterfa...
Hurm, have I duplicated that with this? http://dev.zope.org/Wikis/DevSite/Proposals/GenericMethodInterface If so, how do we squish the two together?
Shane, would the argument list be a management tab for methods? That sounds cool to me :-)
What I have done instead (and this is exactly the way Jim envisioned it months ago) is added a "Bindings" tab to Python methods. You just fill in the names to be populated with an object's container, its context, itself, the DTML namespace, and (this just in :-) the traversal subpath. Then I did the same thing with External Methods and combined them into one product. Unless my changes are vetoed, in the future you won't be adding "External Methods" and "Python Methods" anymore, you'll be adding "Python Method (Internal)" and "Python Method (External)" instead.
How about having a 'Method' base class for _all_ methods, as I suggested in my proposal, which would provide the calling interface as well as some standard 'Method' management tabs? I like the idea of having a bindings tab and an argument tab. Why is that a bad idea? :-)
I've checked it all into CVS but I'm not sure it's available to the public. Perhaps it should be; lobby Ken or Brian. It's the module Packages/Products/PythonMethod.
I'll do that in a sec :-)
Jim solved this confusion by letting you invent your own names, then we made it easier to use by providing "recommended names": container, self, m_self (the method object), _, and traverse_subpath.
Hmm, might make more sense when I play with it :-)
Now, the bindings still aren't available to DTML methods. But it shouldn't be difficult to add.
Cool, is this going toward what I was saying about Zope having a generic 'Method' interface?
So you could get to any or all of those as you need in your method. Of course, new users wouldn't have to worry about this until they needed to do something that used it.
Right. An important feature.
Hehe :-) cheers, Chris
Chris Withers wrote:
Shane Hathaway wrote:
After more pondering I decided to throw out the idea for typed arguments. I was trying to solve a difficult problem with a roundabout, and in the end more difficult solution.
I thought that's what the following proposal was all about? :S http://dev.zope.org/Wikis/DevSite/Proposals/DTMLExpressionSyntax
The idea being to have the form: <dtml-TAGNAME ATTRIBUTE-FORMAT="VALUE">
instead
where FORMAT is in effect the type...
...or have I got that wrong?
Hmm. No, that's not really related.
Is it in the fishbowl under another name or should it be in the fishbowl?
It would actually fall under the the "Current Projects" section.
http://dev.zope.org/Wikis/DevSite/Projects/PythonMethods/MethodObjectInterfa...
Hurm, have I duplicated that with this? http://dev.zope.org/Wikis/DevSite/Proposals/GenericMethodInterface
If so, how do we squish the two together?
Just make sure they both refer to each other for now.
How about having a 'Method' base class for _all_ methods, as I suggested in my proposal, which would provide the calling interface as well as some standard 'Method' management tabs?
That's the plan. In fact, there is a difference between "templates" and "methods", so the base class might be called "MethodOrTemplate".
I like the idea of having a bindings tab and an argument tab. Why is that a bad idea? :-)
It's not, really, but the current management interface is restrictive on the number of tabs you should use. Shane
Shane Hathaway wrote:
http://dev.zope.org/Wikis/DevSite/Proposals/DTMLExpressionSyntax
Hmm. No, that's not really related.
How so? Can you list the differences and if they're orthogonal try and explain it to me? You 'get' this but I sadly don't :( (yet.. ;-)
http://dev.zope.org/Wikis/DevSite/Projects/PythonMethods/MethodObjectInterfa... Hurm, have I duplicated that with this? http://dev.zope.org/Wikis/DevSite/Proposals/GenericMethodInterface
Just make sure they both refer to each other for now.
Done :-)
That's the plan. In fact, there is a difference between "templates" and "methods", so the base class might be called "MethodOrTemplate".
What is the difference between methods and templates other than the scripting paradigm used? Whether it's template or procedural scripting (or functional or declarative ;-) shoudln't the underlying method structure be the same? I think that's what you're sugesting, so maybe just call it 'CallableObject' rather than "MethodOrTemplate"?
It's not, really, but the current management interface is restrictive on the number of tabs you should use.
Yes, I've noticed that too.. Perhaps management tabs should have the option of a 'second row' of tab? So, for example, you click on security, then the next row of tabs appears just below the first lot (different colour maybe?), in the security example the second row would contain: -'Permissions' (the default), -'Local Roles' -'Proxy Roles' (in the case of CallableObjects) -'User Defined Roles' So, you wouldn't need the varying 'Proxy','Defined Permissions' and 'Security' tabs that currently exist (didn't notice that 'Security chanegs its name to 'Defined Permissions' on methods until now, how confusing :S) which I think would make the interface a lot clearer... What do you think? cheers, Chris
participants (2)
-
Chris Withers -
Shane Hathaway