-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
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 com
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
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
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 proble
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 desi
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
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
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'
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 func
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 t
-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 t
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
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 'publishTrav
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',
'browserD
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,
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
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 adapte
18 matches
Mail list logo
