[Repoze-dev] [issue138] Running BFG with mod_wsgi and ipython installed
Jasper Op de Coul jas...@infrae.com added the comment: I verified, the error is gone, Thanks. -- status: chatting - resolved __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue138 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
New submission from Jasper Op de Coul jas...@infrae.com: I have a single macro with a doctype and the html/head/body structure and some slots that I use in every template. When using Chameleon =1.1.1 the doctype is inserted in the rendered HTML. With Chameleon 1.1.2 the doctype is missing, causing mayhem in IE (quirks mode). I had to add the doctype to each of my templates to get it working again. This is obviously related to issue116. I would think this is a bug, but maybe it isn't and putting the doctype in the templates makes more sense. Maybe we can have best of both worlds, xml/doctype declarations can be made everywhere, but exact duplicates should be removed. -- messages: 374 nosy: JasperOC priority: bug status: unread title: Chameleon - can't create xml and doctype declarations from macro __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue139 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
Shane Hathaway sh...@hathawaymix.org added the comment:
I ran into the same issue. The following code worked with 1.1.1 but fails with
1.1.2:
from chameleon.zpt.template import PageTemplate
master = PageTemplate('''\
!DOCTYPE html
html metal:define-macro=main
body
div metal:define-slot=content
content here
/div
/body
/html
''')
page = PageTemplate('''\
html metal:use-macro=master.macros['main']
div metal:fill-slot=content
Hello, world!
/div
/html
''')
s = page(master=master)
assert 'Hello, world!' in s
assert s.startswith('!DOCTYPE html')
__
Repoze Bugs b...@bugs.repoze.org
http://bugs.repoze.org/issue139
__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
Kevin Kalupson kjk...@psu.edu added the comment: I wouldn't expect the the xml headers in a macro template to be applied to the page template being rendered. It makes no sense to me that an element not contained within a macro definition would be applied to the page calling the macro under any situation. __ Repoze Bugs b...@bugs.repoze.org http://bugs.repoze.org/issue139 __ ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
On 4 March 2010 22:02, Kevin Kalupson b...@bugs.repoze.org wrote: I wouldn't expect the the xml headers in a macro template to be applied to the page template being rendered. It makes no sense to me that an element not contained within a macro definition would be applied to the page calling the macro under any situation. I sort of agree, except how else would we provide this functionality? Or is it actually the case that it doesn't make sense for a macro to control these headers –– I suspect it is. Plone's answer to this is to have its wrapper template manually write out the XML declaration or maybe just the DOCTYPE. That seems kind of crude as well. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
Malthe Borch wrote: On 4 March 2010 22:02, Kevin Kalupson b...@bugs.repoze.org wrote: I wouldn't expect the the xml headers in a macro template to be applied to the page template being rendered. It makes no sense to me that an element not contained within a macro definition would be applied to the page calling the macro under any situation. I sort of agree, except how else would we provide this functionality? Or is it actually the case that it doesn't make sense for a macro to control these headers –– I suspect it is. From a template developer's POV, it's useful to apply the same XML declarations throughout a site using metal. The current syntax is non-obvious and perhaps problematic, but workable. Some other syntax might be better, but let's not break the current syntax in the 1.1 branch. Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
On 3/4/10 2:08 PM, Malthe Borch wrote: On 4 March 2010 22:02, Kevin Kalupson b...@bugs.repoze.org wrote: I wouldn't expect the the xml headers in a macro template to be applied to the page template being rendered. It makes no sense to me that an element not contained within a macro definition would be applied to the page calling the macro under any situation. I sort of agree, except how else would we provide this functionality? Or is it actually the case that it doesn't make sense for a macro to control these headers –– I suspect it is. I think it's the case that it doesn't make sense for the macro to control these headers. I have never had the expectation that a tag or header outside of a macro definition would appear in the final rendered page. Plone's answer to this is to have its wrapper template manually write out the XML declaration or maybe just the DOCTYPE. That seems kind of crude as well. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev -Kevin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
On 3/4/10 2:22 PM, Shane Hathaway wrote: Malthe Borch wrote: On 4 March 2010 22:02, Kevin Kalupson b...@bugs.repoze.org wrote: I wouldn't expect the the xml headers in a macro template to be applied to the page template being rendered. It makes no sense to me that an element not contained within a macro definition would be applied to the page calling the macro under any situation. I sort of agree, except how else would we provide this functionality? Or is it actually the case that it doesn't make sense for a macro to control these headers –– I suspect it is. From a template developer's POV, it's useful to apply the same XML declarations throughout a site using metal. In that case, there should be macro explicitly containing the doctype and other wanted headers. The current syntax is non-obvious and perhaps problematic, but workable. Some other syntax might be better, but let's not break the current syntax in the 1.1 branch. I don't think it's a syntax issue, I think it's a behavioral issue. I think the 1.1 branch exhibits broken behavior. Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev -Kevin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
On 4 March 2010 22:45, Kevin J. Kalupson z...@kevinkal.com wrote: In that case, there should be macro explicitly containing the doctype and other wanted headers. Yes, but that's unfortunately impossible. I don't think it's a syntax issue, I think it's a behavioral issue. I think the 1.1 branch exhibits broken behavior. But keep in mind that we're mimicking ``zope.pagetemplate``. Most people expect high corcordance. I just don't know about this. There's a work-around for you though: if you don't define the macro as the root node, then you won't get the doctype. \malthe ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
Kevin J. Kalupson wrote: On 3/4/10 2:22 PM, Shane Hathaway wrote: The current syntax is non-obvious and perhaps problematic, but workable. Some other syntax might be better, but let's not break the current syntax in the 1.1 branch. I don't think it's a syntax issue, I think it's a behavioral issue. I think the 1.1 branch exhibits broken behavior. I'm pretty sure it was in 1.0 as well. It's a standard ZPT idiom. Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
Am 04.03.2010, 17:38 Uhr, schrieb Jasper Op de Coul b...@bugs.repoze.org: I don't have commit rights to the repoze repository but I attached a patch. Go on, sign up. You know you want to: http://repoze.org/contributing.html But I think the contribution agreement is a bit lightweight and should be beerware at least! ;-) BTW. Where do website bugs go? Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
I just tested in zope2 through the zmi. standard_template.pt !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; html metal:define-macro=page head title tal:content=template/titleThe Title/title /head body Hey - this is a test. /body /html test.pt --- metal:block metal:use-macro=here/standard_template.pt/macros/page /metal:block http://localhost:8080/test.pt - source rendered --- html head title/title /head body Hey - this is a test. /body /html -Kevin On 3/4/10 2:50 PM, Shane Hathaway wrote: Kevin J. Kalupson wrote: On 3/4/10 2:22 PM, Shane Hathaway wrote: The current syntax is non-obvious and perhaps problematic, but workable. Some other syntax might be better, but let's not break the current syntax in the 1.1 branch. I don't think it's a syntax issue, I think it's a behavioral issue. I think the 1.1 branch exhibits broken behavior. I'm pretty sure it was in 1.0 as well. It's a standard ZPT idiom. Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
On 3/4/10 2:50 PM, Malthe Borch wrote: On 4 March 2010 22:45, Kevin J. Kalupson z...@kevinkal.com wrote: In that case, there should be macro explicitly containing the doctype and other wanted headers. Yes, but that's unfortunately impossible. not impossible: standard_template.pt - metal:block metal:define-macro=xml_head !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; /metal:block html metal:define-macro=page head title tal:content=template/titleThe Title/title /head body Hey - this is a test. /body /html test.pt --- metal:block metal:use-macro=here/standard_template.pt/macros/xml_head/ metal:block metal:use-macro=here/standard_template.pt/macros/page / localhost:8080/test.pt - rendered source !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; html head title/title /head body Hey - this is a test. /body /html I don't think it's a syntax issue, I think it's a behavioral issue. I think the 1.1 branch exhibits broken behavior. But keep in mind that we're mimicking ``zope.pagetemplate``. Most people expect high corcordance. I just don't know about this. There's a work-around for you though: if you don't define the macro as the root node, then you won't get the doctype. \malthe -Kevin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
Kevin J. Kalupson wrote: I just tested in zope2 through the zmi. I seem to recall that this syntax works in Plone. I don't care whether it works in plain Zope 2. Is this really important to you? While it's a special case, I think it's a case of practicality beats purity. I use it a lot. Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Question of manipulating URL
I'm writing a helper function for paginating the data, the function needs to append a query string to the url to compose a new url with page number, and I decide to use the request object to get the url and then change it. The function I use to construct the url is route_url, I got an issue of using matchdict in the route_url, in the following syntax: route_url(route_name, self.request, **self.request.matchdict) It said Keyword must be string, So I have to add the following codes to change the keyword to string: for k,v in self.request.matchdict.items(): link_params[str(k)]=v I also need to get the route name: route_name=self.reqeust.environ['bfg.routes.route'].name, Am I making simple things complicated? Well, my target is to generate a url from /a to /a?page=1, why should I go through the process of breaking down then composing again? I finally found the *request.url *is a more straightforward way. My question is, which way should I choose? Is there a best practice guide to manipulating the url? ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Question of manipulating URL
On Fri, Mar 5, 2010 at 10:32 AM, georgehu geo...@gmail.com wrote: I'm writing a helper function for paginating the data, the function needs to append a query string to the url to compose a new url with page number, and I decide to use the request object to get the url and then change it. The function I use to construct the url is route_url, I got an issue of using matchdict in the route_url, in the following syntax: route_url(route_name, self.request, **self.request.matchdict) It said Keyword must be string, So I have to add the following codes to change the keyword to string: for k,v in self.request.matchdict.items(): link_params[str(k)]=v I also need to get the route name: route_name=self.reqeust.environ['bfg.routes.route'].name, Am I making simple things complicated? Well, my target is to generate a url from /a to /a?page=1, why should I go through the process of breaking down then composing again? I finally found the request.url is a more straightforward way. My question is, which way should I choose? Is there a best practice guide to manipulating the url? Hi George, Are you aware of the '_query' parameter to route_url? q = dict(page=1) url =route_url(route_name, request, _query=q) It doesn't answer all your question but may help. Best, Darryl ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Build failed in Hudson: repoze.bfg #17
On Wed, Mar 3, 2010 at 18:04, Chris McDonough chr...@plope.com wrote: Please bear with us... we need to get a separate list set up for this and bug tracker stuff. +1. I've always a apprehension (to send 'spam' here) when I change something on the buildbot. -- Sebastien Douche sdou...@gmail.com Twitter: http://bit.ly/afkrK (agile, python, open source) ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] Build failed in Hudson: repoze.bfg #17
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastien Douche wrote: On Wed, Mar 3, 2010 at 18:04, Chris McDonough chr...@plope.com wrote: Please bear with us... we need to get a separate list set up for this and bug tracker stuff. +1. I've always a apprehension (to send 'spam' here) when I change something on the buildbot. Knowing that the buildbots are alive and working is worth the occasional noise, IMHO. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkuQRjcACgkQ+gerLs4ltQ7K/gCfb8xyHyRLxTSiYfat2mcKj87/ fHwAnjQAeup1C3vqAkAiuXptcJFzv6Sk =SwT7 -END PGP SIGNATURE- ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
Kevin Kalupson wrote: The importance to me is that there isn't a regression to the duplicate xml headers when templates render. I like to validate my templates as I go and not have to hack them to then test my rendered template. Good point. If you're statically validating all templates, then putting the doctype in every template is a good thing. However, if you're not statically validating, then putting the doctype in every template is hazardous, because it's easy to forget, and if you forget, the browser quietly slips into quirks mode, causing insidious little CSS bugs. The moral: I guess static template validation would have saved me those hours I spent debugging CSS this week, and maybe putting the doctype in the main template has more cons than pros. Shane ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
Re: [Repoze-dev] [issue139] Chameleon - can't create xml and doctype declarations from macro
Shane, Sorry about sending from the wrong email address - thanks for grabbing the relevant bit and putting it back in the thread. On 3/4/10 9:47 PM, Shane Hathaway wrote: Kevin Kalupson wrote: The importance to me is that there isn't a regression to the duplicate xml headers when templates render. I like to validate my templates as I go and not have to hack them to then test my rendered template. Good point. If you're statically validating all templates, then putting the doctype in every template is a good thing. I think that this is the way to go with zpt and is the often forgotten beauty of zpt. Because you can do this is what makes it better than a lot of other templating languages out there. However, if you're not statically validating, then putting the doctype in every template is hazardous, because it's easy to forget, and if you forget, the browser quietly slips into quirks mode, causing insidious little CSS bugs. The moral: I guess static template validation would have saved me those hours I spent debugging CSS this week, and maybe putting the doctype in the main template has more cons than pros. Shane -Kevin ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
[Repoze-dev] Presentation at NZPUG, Christchurch, NZ
Live coding session with repoze.bfg: http://darrylcousins.blip.tv/ Best regards and thanks, Darryl Cousins ___ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
