Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

page arguments don't work with inherited templates #116

Closed
sqlalchemy-bot opened this issue Jun 28, 2009 · 11 comments
Closed

page arguments don't work with inherited templates #116

sqlalchemy-bot opened this issue Jun 28, 2009 · 11 comments

Comments

@sqlalchemy-bot
Copy link

@sqlalchemy-bot sqlalchemy-bot commented Jun 28, 2009

Migrated issue, originally created by Michael Bayer (@zzzeek)

i.e.:

# TEMPLATE "test.tmpl"
<%inherit file="base.tmpl" />
<%page args="variable" />
${variable}


# TEMPLATE "base.tmpl"
<%page args="bar" />
${bar}
${pageargs['foo']}

a proposed fix is:

def _kwargs_for_callable(callable_, data, **kwargs):
    data.update(kwargs)
    if 'context' in data:
        del data['context']
    return data

though I'd like to see if this can be addressed in a more fundamental way.

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Sep 10, 2009

Anonymous wrote:

Mike,

That was my original proposal, but I did something else.

I simply removed the call to '_kwargs_for_callable' in _render.
Now the only place that calls _kwargs_for_callable is in _render_context.

--- a/libraries/Mako-0.2.4/lib/mako/runtime.py Fri Jul 31 13:14:13 2009 -0700
+++ b/libraries/Mako-0.2.4/lib/mako/runtime.py Mon Aug 17 21:06:58 2009 -0700
@@ -344,14 +344,16 @@
buf = util.StringIO()
context = Context(buf, **data)
context._with_template = template

  • render_context(template, callable, context, *args, **kwargs_for_callable(callable, data))
  • render_context(template, callable, context, *args, **data)
    return context._pop_buffer().getvalue()
  • Jae
@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Sep 11, 2009

Anonymous wrote:

The only bug I've found with the above workaround is that <%include ...> will receive the kwargs given to the container.

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Sep 11, 2009

Anonymous wrote:

(unless overridden in the <%include> tag)

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Jan 19, 2010

Michael Bayer (@zzzeek) wrote:

i need to evaluate how the change to <%include> feels and if it seems like it could be confusing and/or break existing code in a difficult way. 0.3 is good here for a modest behavioral change.

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Jan 19, 2010

Changes by Michael Bayer (@zzzeek):

  • set milestone to "0.3"
@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Mar 5, 2010

Michael Bayer (@zzzeek) wrote:

I think _kwargs_for_callable has been moved around since we last looked at this. The patch above is in b295167 and it doesn't change the workings of <%include>, thanks for the patch !

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Mar 5, 2010

Changes by Michael Bayer (@zzzeek):

  • changed status to closed
@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Mar 11, 2010

Michael Bayer (@zzzeek) wrote:

that rev breaks the usage of template.get_def(...).render() with an open ended dictionary. Fix soon.

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Mar 11, 2010

Changes by Michael Bayer (@zzzeek):

  • changed status to reopened
@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Mar 11, 2010

Michael Bayer (@zzzeek) wrote:

2bf553e

@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Mar 11, 2010

Changes by Michael Bayer (@zzzeek):

  • changed status to closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant