[Zope3-dev] Re: wading through zcml...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: > Martin Aspeli wrote: >>> Why can't IView (or whatever it is) just specify that the constructor >>> must accept a request, response and a template instance? >> Because the template may not be passed in, and even if it is, where >> would it be constructed and how would it be found again? > > See my currying comment later in the thread. > >> then you may as well not have a 'template' attribute for > If you have it done in ZCML, though, you can get a template-only view >> without any Python at all, though: >> >> > for="*" >> template="mytemplate.pt" >> name="my_view" >> permission="zope.Public" >> /> > > yeah, but I'm talking about the horrificness that currently makes the > above work. > > I'm asking whether it really needs to be that bad or whether it could be > more sanely implemented. > > I guess I should just make a branch and have a play or stfu... > > The later is likely to win due to lack of time Have a look at how pushpage defines its ZCML page directive: no nasty generated classes required: http://agendaless.com/Members/tseaver/software/pushpage/pushpage-0.3/ Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFfg8I+gerLs4ltQ4RAn3DAKCaJPbgWZFRaTLxcPEeJ274vAx9hQCfaxvI Y6qfGZLKzDv/j+rfYPvIeNE= =2r6Q -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Martin Aspeli wrote: Why can't IView (or whatever it is) just specify that the constructor must accept a request, response and a template instance? Because the template may not be passed in, and even if it is, where would it be constructed and how would it be found again? See my currying comment later in the thread. then you may as well not have a 'template' attribute for If you have it done in ZCML, though, you can get a template-only view without any Python at all, though: yeah, but I'm talking about the horrificness that currently makes the above work. I'm asking whether it really needs to be that bad or whether it could be more sanely implemented. I guess I should just make a branch and have a play or stfu... The later is likely to win due to lack of time *sigh* Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Martijn Faassen wrote: Chris Withers <[EMAIL PROTECTED]> wrote: Martijn Faassen wrote: class TemplateView(grok.View): template = unassociated module_info = module_info_ I'm not sure. Debugging becomes a nightmare with generated classes, which is how I ran into these problems in the first place. Can you explain what the what the above code snippet actually does? It generates a view for a template file that doesn't have its own view. Okay, but isn't this just a currying problem? If so, there's all the usual python currying solutions, here's one... class ViewFactory: implements(IView) def __init__(self,klass): self.template = PageTemplateFile(klass.template_name) self.klass = klass def __call__(self,context,request): return self.klass(template,context,request) class MyView: template_name = '' provideAdapter(ViewFactory(MyView),(IContext,IRequest),IView) Possibly. It's not that bad right now. The difficulty is that I do need to generate a class, not an instance, as I can only initialize the instance when the view is initialized because the context and request are needed. There's something to be said for circumstances where creating an adapter each time it's asked for is sub-optimal, but I don't have a good enough feel for the problem in its generic sense to make any suggestions... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: wading through zcml...
Chris Withers wrote:
Jim Fulton wrote:
If you want to specify the name of a template in ZCML, then you'll
have to invoke some magic.
Why can't IView (or whatever it is) just specify that the constructor
must accept a request, response and a template instance?
Because the template may not be passed in, and even if it is, where
would it be constructed and how would it be found again?
If you have this:
class MyView(object):
def __init__(self, context, request, template):
self.template = template # IView specifices template = a template
...
then you may as well not have a 'template' attribute for /> at all since you have to do so much work; you could just do this
(which you can do now, in fact)
class MyView(object):
template = ViewPageTemplateFile('mytemplate.pt')
def __init__(self, context, request):
self.context = context
self.request = request
If you have it done in ZCML, though, you can get a template-only view
without any Python at all, though:
Martin
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: wading through zcml...
Chris Withers <[EMAIL PROTECTED]> wrote: > Martijn Faassen wrote: >> class TemplateView(grok.View): >> template = unassociated >> module_info = module_info_ > I'm not sure. Debugging becomes a nightmare with generated classes, > which is how I ran into these problems in the first place. > > Can you explain what the what the above code snippet actually does? It generates a view for a template file that doesn't have its own view. >> I've done it too recently in the form support. The *real* formlib-level >> form class is dynamically created for each grok-level form: >> >> class RealEditForm(form.EditForm): >> form_fields = get_form_fields(factory, context) >> actions = actions_ >> >> This one is a bit more scary, as the end-user interacts with an >> *instance* of this class; the form attribute on grok-level forms is one. > > There must be a nicer way :-S Possibly. It's not that bad right now. The difficulty is that I do need to generate a class, not an instance, as I can only initialize the instance when the view is initialized because the context and request are needed. I could probably do some scary hacking to make it an instance after all, but that will make the code far less easy to understand. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Jim Fulton wrote: If you want to specify the name of a template in ZCML, then you'll have to invoke some magic. Why can't IView (or whatever it is) just specify that the constructor must accept a request, response and a template instance? Now I'll go back to ignoring this thread, the desire to do so increased by the sort of extreme over-simplifying remarks made. Not sure what you mean by this... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Martijn Faassen wrote: dynamically generated class for templates that don't have classes of themselves. I know you were there when we created this one. :) class TemplateView(grok.View): template = unassociated module_info = module_info_ of course the instances of this class do nothing the developer has to interact with. As soon as the developer provides a view class of their own, there's no dynamically generated class anymore. I think that this is an acceptable use of the pattern. I'm not sure. Debugging becomes a nightmare with generated classes, which is how I ran into these problems in the first place. Can you explain what the what the above code snippet actually does? I've done it too recently in the form support. The *real* formlib-level form class is dynamically created for each grok-level form: class RealEditForm(form.EditForm): form_fields = get_form_fields(factory, context) actions = actions_ This one is a bit more scary, as the end-user interacts with an *instance* of this class; the form attribute on grok-level forms is one. There must be a nicer way :-S cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Philipp von Weitershausen wrote: ... That said, I can live with most of the crap, but these dynamically generated classes... wtf? why? why did that? why are they still breathing?! *sigh* I don't know who came up with the idea, and I don't really care as I don't want to point fingers at anyone. The reasons are probably historical... I'm mostly ignoring this discussion because it's a repeat of many past discussions. I just noticed this comment in passing. I came up with the idea. Or more importantly, I came up with the implementation in response to a desire to be able to not include template specifications in Python. If you want to specify the name of a template in ZCML, then you'll have to invoke some magic. Either you need to generate a class or you need a magic factory that jams the template on to an instance. I don't see that it makes much difference either way. Now I'll go back to ignoring this thread, the desire to do so increased by the sort of extreme over-simplifying remarks made. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: wading through zcml...
Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: [Chris] >> That said, I can live with most of the crap, but these dynamically >> generated classes... wtf? why? why did that? why are they still breathing?! > > *sigh* I don't know who came up with the idea, and I don't really care > as I don't want to point fingers at anyone. The reasons are probably > historical... Philipp, note that we're dynamically generating some classes in Grok: dynamically generated class for templates that don't have classes of themselves. I know you were there when we created this one. :) class TemplateView(grok.View): template = unassociated module_info = module_info_ of course the instances of this class do nothing the developer has to interact with. As soon as the developer provides a view class of their own, there's no dynamically generated class anymore. I think that this is an acceptable use of the pattern. I've done it too recently in the form support. The *real* formlib-level form class is dynamically created for each grok-level form: class RealEditForm(form.EditForm): form_fields = get_form_fields(factory, context) actions = actions_ This one is a bit more scary, as the end-user interacts with an *instance* of this class; the form attribute on grok-level forms is one. Of course there were good reasons to do this - I wanted to avoid mixing formlib level forms with grok-level forms, as too many method names were the same and making that horrible tangle work would've been a lot more pain indeed, I think. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Chris Withers wrote: Philipp von Weitershausen wrote: browser:view Note: browser:view always creates new classes on the fly. evil browser:page Registers an adapter where the second adapted object defaults to IBrowserDefaltLayer. Always creates a new class on the fly and mixes in functionality that makes the adapter a *publishable view*. evil. I'm sick of ZCML and its magic and its inconsistency. The typing and the pointy brackets I could live with... ME GROK SMASH ZCML. Yeah, ZCML is the new acquisition :-( Well, the ZCML directives we currently have. If we had better and more sensible directives, it might be much better. It's sad that one of it's main selling points (the ability to "turn off" configuration made in another package) was never implemented :-( Not yet. We're getting there. That said, I can live with most of the crap, but these dynamically generated classes... wtf? why? why did that? why are they still breathing?! *sigh* I don't know who came up with the idea, and I don't really care as I don't want to point fingers at anyone. The reasons are probably historical... Whatever happened to explicit is better than implicit et al? Exactly. I'm trying to register an adapter in such a way that I can do the following in a page template: Which of the myriad flavours of view registration should I be using? Inherit from BrowserView Everyone says this, but why is it a good idea? I want these things to be _really_ light, they're going to be used a lot in every page render... BrowserView and BrowserPage *are* really light. Look at them. Note that you would get them mixed into your view component automatically by ZCML anyways (at least when using browser:view / browser:page). -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Philipp von Weitershausen wrote: browser:view Note: browser:view always creates new classes on the fly. evil browser:page Registers an adapter where the second adapted object defaults to IBrowserDefaltLayer. Always creates a new class on the fly and mixes in functionality that makes the adapter a *publishable view*. evil. I'm sick of ZCML and its magic and its inconsistency. The typing and the pointy brackets I could live with... ME GROK SMASH ZCML. Yeah, ZCML is the new acquisition :-( It's sad that one of it's main selling points (the ability to "turn off" configuration made in another package) was never implemented :-( That said, I can live with most of the crap, but these dynamically generated classes... wtf? why? why did that? why are they still breathing?! Whatever happened to explicit is better than implicit et al? I'm trying to register an adapter in such a way that I can do the following in a page template: Which of the myriad flavours of view registration should I be using? Inherit from BrowserView Everyone says this, but why is it a good idea? I want these things to be _really_ light, they're going to be used a lot in every page render... and use either a simple or a /> or a directive to register it. Note that this thing won't be publishable via the URL then (which is probably what you want). Correct. Also, why, when zope:view is described as a synonym for zope:adapter, does zope:view support an allowed_attributes attribute, while zope:adapter does not? zope:adapter assumes the "provides" interface as the "allowed_interface". *sigh* Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: wading through zcml...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Hathaway wrote: > Philipp von Weitershausen wrote: >> Shane Hathaway wrote: >>> However, I'm wondering what browser:page does to make something >>> publishable, that browser:view doesn't do. >> It creates a new class with an extra mix-in class that has a >> browserDefault method which in turn points to the template, method or >> __call__ attribute. > > If you don't mind explaining, I'd like to understand why this design was > chosen. Why does it create a new class instead of creating an instance > of a class? It seems like it's using advanced Python (class generation) > where ordinary Python (a class instance) will do just as well. > > If I'm not missing something important, I may try to rewrite that code. I *think* that the design predated the ability of the security machinery to use an instance-specific attriubute for the checker, and so the only feasible way to get the configuration-specified security settings was to generate code. Either that, or the implementor didn't understand how the checker machinery worked, and just "made it work." 'pushpage' has a view directive which uses instances, rather than generated classes: http://agendaless.com/Members/tseaver/software/pushpage Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFXU6y+gerLs4ltQ4RAmEzAKDDATRzC8AN94myLUBAghrYAUvuQACgoo/5 AF8Yf4uOzdLSv6aYtGzIwEQ= =2tLN -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Philipp von Weitershausen wrote: Shane Hathaway wrote: However, I'm wondering what browser:page does to make something publishable, that browser:view doesn't do. It creates a new class with an extra mix-in class that has a browserDefault method which in turn points to the template, method or __call__ attribute. If you don't mind explaining, I'd like to understand why this design was chosen. Why does it create a new class instead of creating an instance of a class? It seems like it's using advanced Python (class generation) where ordinary Python (a class instance) will do just as well. If I'm not missing something important, I may try to rewrite that code. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Shane Hathaway wrote: Philipp von Weitershausen wrote: Shane Hathaway wrote: Philipp von Weitershausen wrote: browser:view Like zope:view, except: * the request type (second adapted object) defaults to IBrowserDefaultLayer * the "permission" always applies to 'publishTraverse', 'browserDefault' and '__call__' attributes, in addition to the optionally specified "allowed_attributes" or "allowed_interface" So, is a browser:view publishable, like a browser:page? No. That's why you can't open URLs like http://.../anobj/@@absolute_url (like you can in Zope 2) because absolute_url is a view, but one that's not publishable. Well, actually there's a browser:page directive on the Zope 3 trunk that makes @@absolute_url publishable. Shrug! However, I'm wondering what browser:page does to make something publishable, that browser:view doesn't do. It creates a new class with an extra mix-in class that has a browserDefault method which in turn points to the template, method or __call__ attribute. In one of my attempts to sanitize all this stuff, I envisioned making a base class like that (the saner version is BrowserPage) mandatory, so that people know where the magic is... In fact, if you use BrowserPage today, you can actually register it as a publishable view using a standard directive. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Philipp von Weitershausen wrote: Shane Hathaway wrote: Philipp von Weitershausen wrote: browser:view Like zope:view, except: * the request type (second adapted object) defaults to IBrowserDefaultLayer * the "permission" always applies to 'publishTraverse', 'browserDefault' and '__call__' attributes, in addition to the optionally specified "allowed_attributes" or "allowed_interface" So, is a browser:view publishable, like a browser:page? No. That's why you can't open URLs like http://.../anobj/@@absolute_url (like you can in Zope 2) because absolute_url is a view, but one that's not publishable. Well, actually there's a browser:page directive on the Zope 3 trunk that makes @@absolute_url publishable. However, I'm wondering what browser:page does to make something publishable, that browser:view doesn't do. It's pretty hard to wade through zope.app.publisher.browser.viewmeta to figure it out. Is it some magic attribute, some behind-the-scenes registration...? Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Shane Hathaway wrote: Philipp von Weitershausen wrote: browser:view Like zope:view, except: * the request type (second adapted object) defaults to IBrowserDefaultLayer * the "permission" always applies to 'publishTraverse', 'browserDefault' and '__call__' attributes, in addition to the optionally specified "allowed_attributes" or "allowed_interface" So, is a browser:view publishable, like a browser:page? No. That's why you can't open URLs like http://.../anobj/@@absolute_url (like you can in Zope 2) because absolute_url is a view, but one that's not publishable. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: wading through zcml...
Philipp von Weitershausen wrote: browser:view Like zope:view, except: * the request type (second adapted object) defaults to IBrowserDefaultLayer * the "permission" always applies to 'publishTraverse', 'browserDefault' and '__call__' attributes, in addition to the optionally specified "allowed_attributes" or "allowed_interface" So, is a browser:view publishable, like a browser:page? I'm sick of ZCML and its magic and its inconsistency. The typing and the pointy brackets I could live with... ME GROK SMASH ZCML. I hope we're actually making Zope 3 less magical than Zope 2, rather than just pushing the magic around. (It's too early to judge, however, so let's not have another long discussion about magic.) Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: wading through zcml...
Chris Withers wrote: What's the difference between zope:view, browser:view, browser:page and browser:viewlet? It's a mess. Here's the gist: zope:adapter Registers an adapter and optionally applies a permission to the interface that you're adapting to, e.g.:: will cause the adapter's attributes as specified in IFoo to be protected with the 'foo.permission' (everything else will not be accessible). zope:view Registers an adapter and optionally applies a permission to all "allowed_attirbutes" or the "allowed_interface" if the "permission" parameter is given. browser:view Like zope:view, except: * the request type (second adapted object) defaults to IBrowserDefaultLayer * the "permission" always applies to 'publishTraverse', 'browserDefault' and '__call__' attributes, in addition to the optionally specified "allowed_attributes" or "allowed_interface" * support sub-pages that will be available as obj/@@viewname/subpage. Note: browser:view always creates new classes on the fly. browser:page Registers an adapter where the second adapted object defaults to IBrowserDefaltLayer. Always creates a new class on the fly and mixes in functionality that makes the adapter a *publishable view*. browser:viewlet Registers an adapter for (context, request, view). It's out of scope here, I think. I wish we could clean this up some day, but all my earlier attempts to walk this direction have mostly been shot down because people apparently hate deprecation warnings. I'm sick of ZCML and its magic and its inconsistency. The typing and the pointy brackets I could live with... ME GROK SMASH ZCML. I'm trying to register an adapter in such a way that I can do the following in a page template: Which of the myriad flavours of view registration should I be using? Inherit from BrowserView and use either a simple or a /> or a directive to register it. Note that this thing won't be publishable via the URL then (which is probably what you want). If you want it to be published, inherit from BrowserPage and use Also, why, when zope:view is described as a synonym for zope:adapter, does zope:view support an allowed_attributes attribute, while zope:adapter does not? zope:adapter assumes the "provides" interface as the "allowed_interface". -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
