So... to stop hijacking Robert's idea for a directive which spells an owrap for
a view... I have a slightly different idea for this.
We could allow a ZCML inner view directive to spell a wrapper view name ala:
view
name=owrap
view=.views.owrap_view
template=templates/owrap.pt
/
Responding to myself, I've actually checked in this feature on the trunk too.
Chris McDonough wrote:
So... to stop hijacking Robert's idea for a directive which spells an
owrap for a view... I have a slightly different idea for this.
We could allow a ZCML inner view directive to spell a
So I've been trying to puzzle out some issues, which might or might not
be related to this topic.
In KARL, we currently write all of our views something in the form of:
def myview(context, request):
[ do stuff ]
api = TemplateAPI(context, request) # a utility class
return
HI Chris
I a way you describing something simliar to what we have in zope2, in
that from a tal expression we have access to
(via acquisition) all of the portal tools etc...
I wonder if a couple of hi level functions could be put into the
namespace, (or the view for instance) that allow you
to
Tim Hoffman wrote:
HI Chris
I a way you describing something simliar to what we have in zope2, in
that from a tal expression we have access to
(via acquisition) all of the portal tools etc...
I wonder if a couple of hi level functions could be put into the
namespace, (or the view for
On Mon, Aug 24, 2009 at 10:11:04PM -0400, Chris McDonough wrote:
I like this.
Some variations:
- Have IOWrap be a multiadapter on context and request, so we can vary the
o-wrap based on request type too (e.g. IManagementRequest vs.
IRetailRequest).
Good idea. I'll go ahead and add this
I like this.
Some variations:
- Have IOWrap be a multiadapter on context and request, so we can vary the
o-wrap based on request type too (e.g. IManagementRequest vs.
IRetailRequest).
- If IOWrap can't be adapted, just return the result of the view (instead of
throwing a component lookup
