Nathan Van Gheem wrote:
I think Andreas was more referring to the pyramid way of doing various
view discriminators.
Ok, thanks. I agree that those are completely different issue and
offtopic for my configuration issues :) It's hard to see that far with
Plone (I'd guess, it would be possible only after wsgi is the default
way to run Plone).
-Asko
On Sat, Jan 4, 2014 at 11:44 AM, Asko Soukka <[email protected]
<mailto:[email protected]>> wrote:
Hi,
ajung wrote:
Having a similar functionality like
@view_request in Pyramid would be cool...
I had an hour in train to try this out. I hope, I understood this
correctly.
I tried out a zope.configuration directive with venusian decorator
like
@view_configure(name='hello_world', for_='*',
permission='zope2.View')
def hello_world(context, request):
return u"Hello World!"
which would render the returned result, or
@view_configure(name='hello_world', for_='*',
template='templates/hello_world.pt
<http://hello_world.pt>',
permission='zope2.View')
def hello_world(context, request):
return {'content': u"Hello World!"}
which would render hello_world.pt <http://hello_world.pt> with
u"Hello World!" available at view/content.
Technically, my directive creates a dynamic BrowserView-based
class, with decorated function as static method, to be called in
__call__. Quite ok, but the "dynamic class" might be a problem
when debugging errors. However, this approach allowed me to re-use
existing directives and I needed only a few new lines of code for
this feature.
So, I don't think that zope.configuration is our problem.
We could have @view_configure for Plone if we'd like to (or maybe
@page_configure to avoid mixing it with Pyramid's view_configure
or Zope 3's "Views", which are different from BrowserPages). But,
of course, this would not solve our current issue of having
already too many ways to define Views and easy-to-find
documentation for any of them. (Luckily, there's documentation
sprints coming up this year \o/).
-Asko
_______________________________________________
Product-Developers mailing list
[email protected]
<mailto:[email protected]>
https://lists.plone.org/mailman/listinfo/plone-product-developers
--
Nathan Van Gheem
Solutions Architect
Wildcard Corp
_______________________________________________
Product-Developers mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-product-developers