On Mon, Jul 25, 2011 at 10:30 PM, Christoph Zwerschke <[email protected]> wrote: > Am 25.07.2011 21:31 schrieb Alessandro Molina: >> >> Otherwise there might be cases where the controller reports a >> content-type and the meta tag another one if the users switched >> content type from the controller without making the template content >> type dependent from a variable. > > Actually if you're using templates you can't switch the content type > (charset) in the controller anyway since you would need to also switch the > output encoding of the templating engine which TG2 does not support. >
Correct, Genshi would continue to output utf8 xhtml. Still I find strange the idea of having the same info replicated in two places and not auto-synced. >> Any issue that I'm unable to see? > > One reason for keeping the meta tags is that they are useful when you store > or cache pages for offline reading. Otherwsie, the content-type sent in the > http header always takes precedence, so they will not harm even if they are > wrong. > Most caching systems store the http headers with the cached content, so they should always report the same. HTTP Header precedence was indeed the reason why I was +1 for removing the meta tag, as it was actually useless. But for offline reading it indeed makes sense, so I think that you are right. > Btw, this was one of the things I liked in Kid templates, where the engine > injected the right meta tag in its output automatically. > As we want to keep the meta tag there, I would like to provide a clear way for the user to understand how to change the content type in only one place. I will take for example the "serve xhtml as xml" case, to study the case. Currently genshi rendering method is detected from the response content type in render_genshi, which makes sense. if we add support for application/xhtml+xml to the rendering function to switch to xml mode we are now able to correclty put out xhtml in xml mode. Anyway we would push out a page where the meta tag says text/html which won't cause harm, but at least smells bad. Next step might be to have the quickstart template that sets the meta tag using response.content_type. This seems to solve the problem of serving xhtml as application/xhtml+xml as everything would be in sync and decided only from the response.content_type. Now the other issue... the charset. This seems harder to solve as TG is currently not passing any encoding parameter to genshi. Pylons itself asks to genshi to generate an unicode string, so it should be possible to provide a .encoding to the generated template if the content_type charset is not utf8. Dunno, I'm not really sure about the charset issue. -- You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
