Re: pylons, genshi and xml
On Feb 16, 2007, at 9:05 PM, Cliff Wells wrote:
Actually, the TG spec is completely superfluous. You can use /
rather than . and it will work just fine. I just removed support
for
dotted path notation from Breve as it causes problems (e.g. paths with
dots in them) and provides nothing in return. If you don't have a
large
userbase of people expecting dot notation to work, I'd get rid of
it now
before you do.
I tried to remove the '.' handling stuff from my Buffet no luck.
Here's the logic performed for all engines except Myghty/Mako:
if not engine_name.startswith('pylons') and not \
engine_name.startswith('mako'):
full_path = os.path.join(engine_config['root'],
template_name)
full_path = full_path.replace(os.path.sep,
'.').lstrip('.')
If I remove that, the Kid test fails. Apparently it needs the '.'
replaced with a '/' and needs the engine's root added. This logic is
carried over from the stand-alone Buffet package. I'm not entirely
sure why Kid and the other engines need this logic performed to
handle the dot notation but they seem to require it.
If someone else who knows more about the Buffet/Template plugin stuff
could shed some light on this, I'm all ears. :)
Cheers,
Ben
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: pylons, genshi and xml
On 2/17/07, Ben Bangert [EMAIL PROTECTED] wrote:
On Feb 16, 2007, at 9:05 PM, Cliff Wells wrote:
Actually, the TG spec is completely superfluous. You can use /
rather than . and it will work just fine. I just removed support
for
dotted path notation from Breve as it causes problems (e.g. paths with
dots in them) and provides nothing in return. If you don't have a
large
userbase of people expecting dot notation to work, I'd get rid of
it now
before you do.
I tried to remove the '.' handling stuff from my Buffet no luck.
Here's the logic performed for all engines except Myghty/Mako:
if not engine_name.startswith('pylons') and not \
engine_name.startswith('mako'):
full_path = os.path.join(engine_config['root'],
template_name)
full_path = full_path.replace(os.path.sep,
'.').lstrip('.')
If I remove that, the Kid test fails. Apparently it needs the '.'
replaced with a '/' and needs the engine's root added. This logic is
carried over from the stand-alone Buffet package. I'm not entirely
sure why Kid and the other engines need this logic performed to
handle the dot notation but they seem to require it.
If someone else who knows more about the Buffet/Template plugin stuff
could shed some light on this, I'm all ears. :)
It's likely that Kid requires this because it compiles templates into
.pyc files and loads them with the normal import machinery? I haven't
used Kid in a while, but I the last time I used it I scratched my head
for at least *three months* on and off trying to figure out why my
pudge templates were rendering incorrectly. It turns out that stale
.pyc files from a previous version of Kid were being used, and that
Kid had no preventative measures for those kinds of things.
-bob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: pylons, genshi and xml
On Tue, 2007-02-13 at 17:00 -0800, Ben Bangert wrote: On Feb 13, 2007, at 2:11 PM, Matt Good wrote: Yes, this was based on the Kid engine provided by TurboGears which uses module-style names to load templates. Last I checked Pylons also expected all template engines besides Myghty and Mako to use this convention. I plan to make the Genshi plugin usable with file paths as well, but of course I need to be sure to allow for backwards compatibility. In the Mako plugin, I've set it up so that if you have a / in the template name, it assumes you're doing full paths. Thus if it sees 'dir.tmpl' it assumes its dot notation template, and if its '/dir/ tmpl.html' it assumes its a path due to the /. If the Genshi template does this toggling as well, I'll add Genshi to the template engines that don't have their path 'touched' before it goes to the template engine. I'm not thrilled to be hacking around the TG spec, clearly a new spec is needed but as there doesn't seem to be any traction or clear leader of that spec and its evolution this should work decently in the meantime. Actually, the TG spec is completely superfluous. You can use / rather than . and it will work just fine. I just removed support for dotted path notation from Breve as it causes problems (e.g. paths with dots in them) and provides nothing in return. If you don't have a large userbase of people expecting dot notation to work, I'd get rid of it now before you do. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons, genshi and xml
On 2/13/07, Ben Bangert [EMAIL PROTECTED] wrote:
On Feb 11, 2007, at 5:26 PM, Bob Ippolito wrote:
That is annoying... but not annoying enough to where I've gone and
tried to figure out where to make that change. I'd be curious as to
what the workaround is for that one.
As Matt mentions, this is intentional behavior due to how TurboGears
expects them to be module's. I'd like to look into a small extension
to the TG plugin so that one could indicate somewhere that they don't
want the template name 'mangled' on the way in (ie, have the template
extension added).
That's a problem with the way Pylons works with buffet. It's
impossible to do it with a render call, because it doesn't give you an
opportunity to pass in a format parameter. You need to basically go
behind the scenes and do what render() is doing. Here's an example of
what I'm using:
def render_atom(template_name, **namespace):
content = pylons.buffet.render(
template_name=template_name,
fragment=False,
namespace=namespace,
format='xml',
)
return Response(content, mimetype='application/atom+xml')
This has been fixed in r1859. You can now do:
return render_response('/some/template.xml', format='xml')
A lot of people want to change the mimetype at the same time they
render a template, so I'm considering adding that option directly to
render_response as well. I'm only slightly hesitant because keyword
options go into the template's namespace, and I'd like to keep it as
obvious as possible which names go to the template engine, and which
to the response object (in the case of mimetype).
It looks like it renders the whole document in memory before
sending it out.
This is a huge problem for templates where the result is large (like
above). The obvious problem is that it blows out memory on the
server side
for no reason. Another problem though is the latency as the
client must
wait until the whole page is generated before it sees any of the
response.
From what I've read it sounds like genshi is very stream oriented,
so it
shouldn't need to build all of it up in memory before it can start
streaming
the results out or did I misunderstand this? Is it the Response
object (or
pylons) that requires a full result prior to sending anything back?
Regardless of what actually causes it, how do I fix it?
As long as the template renderer returns a generator, then it'll
output as its done. I'm not sure how the Genshi plugin is written, or
whether its render output is returned as a string, or a generator.
I'm guessing its returned as a string which means you'd need to go to
raw Genshi itself to get back a generator and set that as the content
for a Response object.
Yep, instead of using render_response which renders the template and
puts it into a response, you should piece together a Response object,
passing a generator for content. Then, in this generator, you can use
Genshi to spit back a piece at a time. I've done this for CSV using
the csv module. A good test to see if you have the generators
working right is to use the following as your generator:
import itertools
def numbers():
for num in itertools.count():
yield %s\n % num
Then, view the page and watch the numbers scroll down. If you use
telnet instead of a browser, you get a remote counting server :-D
Happy Hacking!
-jj
--
http://jjinux.blogspot.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: pylons, genshi and xml
On Feb 14, 2007, at 2:02 PM, Bob Ippolito wrote:
This just seems like a bad API decision. The namespace should really
be a dict argument rather than trying to mince it together with the
other arguments that do entirely different things. The current API is
just really unnatural.
In all of my controllers the namespace is already a separate dict, but
I have to **args it in (and hope that I don't use some name that the
render function cares about).
Agreed, I'd like to change it to take a dict that goes to the
namespace of the template though that'll probably break a few
people's projects. Most people are using the 'c' object to pass
variables so they won't be affected. I'll take a look at making it
able to take a dict as the first arg which it'd then use as the
namespace, and throw a deprecation warning for 0.9.5 should a full
set of keyword args be passed indicating that it should be switched
to a dict.
Ie:
render_response('/some/template',dict(arg='val'), format='xml')
Or if you want to do it all with keyword args:
render_response('/some/template', namespace=dict(arg='val'),
format='xml')
As none of the Response init args conflict with the Buffet render
args, I don't see any harm in letting you put keyword options like
mimetype in there that go to the Response object created. How's that
look?
Cheers,
Ben
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: pylons, genshi and xml
On 2/14/07, Ben Bangert [EMAIL PROTECTED] wrote:
On Feb 14, 2007, at 2:02 PM, Bob Ippolito wrote:
This just seems like a bad API decision. The namespace should really
be a dict argument rather than trying to mince it together with the
other arguments that do entirely different things. The current API is
just really unnatural.
In all of my controllers the namespace is already a separate dict, but
I have to **args it in (and hope that I don't use some name that the
render function cares about).
Agreed, I'd like to change it to take a dict that goes to the
namespace of the template though that'll probably break a few
people's projects. Most people are using the 'c' object to pass
variables so they won't be affected. I'll take a look at making it
able to take a dict as the first arg which it'd then use as the
namespace, and throw a deprecation warning for 0.9.5 should a full
set of keyword args be passed indicating that it should be switched
to a dict.
Ie:
render_response('/some/template',dict(arg='val'), format='xml')
Or if you want to do it all with keyword args:
render_response('/some/template', namespace=dict(arg='val'),
format='xml')
As none of the Response init args conflict with the Buffet render
args, I don't see any harm in letting you put keyword options like
mimetype in there that go to the Response object created. How's that
look?
+0.5
Anyway, the docs tell you to use c.
Happy Hacking,
-jj
--
http://jjinux.blogspot.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: pylons, genshi and xml
On 2/14/07, Shannon -jj Behrens [EMAIL PROTECTED] wrote:
On 2/14/07, Ben Bangert [EMAIL PROTECTED] wrote:
On Feb 14, 2007, at 2:02 PM, Bob Ippolito wrote:
This just seems like a bad API decision. The namespace should really
be a dict argument rather than trying to mince it together with the
other arguments that do entirely different things. The current API is
just really unnatural.
In all of my controllers the namespace is already a separate dict, but
I have to **args it in (and hope that I don't use some name that the
render function cares about).
Agreed, I'd like to change it to take a dict that goes to the
namespace of the template though that'll probably break a few
people's projects. Most people are using the 'c' object to pass
variables so they won't be affected. I'll take a look at making it
able to take a dict as the first arg which it'd then use as the
namespace, and throw a deprecation warning for 0.9.5 should a full
set of keyword args be passed indicating that it should be switched
to a dict.
Ie:
render_response('/some/template',dict(arg='val'), format='xml')
Or if you want to do it all with keyword args:
render_response('/some/template', namespace=dict(arg='val'),
format='xml')
As none of the Response init args conflict with the Buffet render
args, I don't see any harm in letting you put keyword options like
mimetype in there that go to the Response object created. How's that
look?
+0.5
Anyway, the docs tell you to use c.
They do, but my templates are all ported over from TurboGears, which
uses a flat namespace. I'm not using c at all.
-bob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: pylons, genshi and xml
On Feb 11, 2007, at 5:26 PM, Bob Ippolito wrote:
That is annoying... but not annoying enough to where I've gone and
tried to figure out where to make that change. I'd be curious as to
what the workaround is for that one.
As Matt mentions, this is intentional behavior due to how TurboGears
expects them to be module's. I'd like to look into a small extension
to the TG plugin so that one could indicate somewhere that they don't
want the template name 'mangled' on the way in (ie, have the template
extension added).
That's a problem with the way Pylons works with buffet. It's
impossible to do it with a render call, because it doesn't give you an
opportunity to pass in a format parameter. You need to basically go
behind the scenes and do what render() is doing. Here's an example of
what I'm using:
def render_atom(template_name, **namespace):
content = pylons.buffet.render(
template_name=template_name,
fragment=False,
namespace=namespace,
format='xml',
)
return Response(content, mimetype='application/atom+xml')
This has been fixed in r1859. You can now do:
return render_response('/some/template.xml', format='xml')
A lot of people want to change the mimetype at the same time they
render a template, so I'm considering adding that option directly to
render_response as well. I'm only slightly hesitant because keyword
options go into the template's namespace, and I'd like to keep it as
obvious as possible which names go to the template engine, and which
to the response object (in the case of mimetype).
It looks like it renders the whole document in memory before
sending it out.
This is a huge problem for templates where the result is large (like
above). The obvious problem is that it blows out memory on the
server side
for no reason. Another problem though is the latency as the
client must
wait until the whole page is generated before it sees any of the
response.
From what I've read it sounds like genshi is very stream oriented,
so it
shouldn't need to build all of it up in memory before it can start
streaming
the results out or did I misunderstand this? Is it the Response
object (or
pylons) that requires a full result prior to sending anything back?
Regardless of what actually causes it, how do I fix it?
As long as the template renderer returns a generator, then it'll
output as its done. I'm not sure how the Genshi plugin is written, or
whether its render output is returned as a string, or a generator.
I'm guessing its returned as a string which means you'd need to go to
raw Genshi itself to get back a generator and set that as the content
for a Response object.
Cheers,
Ben
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
pylons, genshi and xml
I've been using genshi with pylons for a bit now and generally love it, but
have some questions and problems.
I'm confused why I have to write render_response('someTemplate') but the
template must be named someTemplate.html. I'm sorry to say that it
actually took me a while to figure that out. Why can't I pass the actual
file name to the render_response method like you would with myghty -
render_response('someTemplate.myt') for example? This is a problem because
I can't use other extensions (.htm, .xhtml, .gen, etc) for my files and/or
have the same file name with different extensions represent different
formats of the same data, etc, etc, etc...
This leads to one of my current problems. I want to use a genshi template
to send back XML, not HTML. Clearly genshi supports this, but I can't just
put a someTemplate.xml file in the templates directory because
render_response('someTemplate') doesn't find it. I'm also guessing that the
output format passed into genshi is kind hard coded in the same way, as is
the mime-type. So I guess my (newbie) question is how do I render an XML
template with genshi in pylons?
The other problem I'm having deals with performance. For example, lets say
I use return render_response('bigTemplate') where bigTemplate looks like
?xml version=1.0 encoding=UTF-8?
foo xmlns:py=http://genshi.edgewall.org/; lang=en
bar py:for=item in xrange([someRealyReallyBigNumber])${item}/bar
/foo
It looks like it renders the whole document in memory before sending it
out. This is a huge problem for templates where the result is large (like
above). The obvious problem is that it blows out memory on the server side
for no reason. Another problem though is the latency as the client must
wait until the whole page is generated before it sees any of the response.
From what I've read it sounds like genshi is very stream oriented, so it
shouldn't need to build all of it up in memory before it can start streaming
the results out or did I misunderstand this? Is it the Response object (or
pylons) that requires a full result prior to sending anything back?
Regardless of what actually causes it, how do I fix it?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
