help with simple Pylons and Mako script
I'm following the book at pylonsbook.com. I've created a project
called TemplateDemo and when I create a template greeting.html and
call it with render(), instead of replacing {$name} with the value of
the variable I've passed, it simply shows greeting.html with the
{$name} in it. Its has if I'm viewing the html file statically.
Here is my controller code:
import logging
from pylons import request, response, session, tmpl_context as c
from pylons.controllers.util import abort, redirect_to
from templatedemo.lib.base import BaseController, render
log = logging.getLogger(__name__)
class GreetingController(BaseController):
def index(self):
name = 'Pylons Developer'
return render('/greeting.html', extra_vars={'name' : name})
and here is my greeting.html code:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://
www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
head
titleGreetings/title
/head
body
h1Greetings/h1
pHello {$name}!/p
/body
/html
What gives?
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: help with simple Pylons and Mako script
You have to use ${ name } and not { $name }
nolsen01 wrote:
I'm following the book at pylonsbook.com. I've created a project
called TemplateDemo and when I create a template greeting.html and
call it with render(), instead of replacing {$name} with the value of
the variable I've passed, it simply shows greeting.html with the
{$name} in it. Its has if I'm viewing the html file statically.
Here is my controller code:
import logging
from pylons import request, response, session, tmpl_context as c
from pylons.controllers.util import abort, redirect_to
from templatedemo.lib.base import BaseController, render
log = logging.getLogger(__name__)
class GreetingController(BaseController):
def index(self):
name = 'Pylons Developer'
return render('/greeting.html', extra_vars={'name' : name})
and here is my greeting.html code:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://
www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
head
titleGreetings/title
/head
body
h1Greetings/h1
pHello {$name}!/p
/body
/html
What gives?
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: help with simple Pylons and Mako script
Thanks!
I knew it was going to be something like that. I can't tell you how
many times dumb things like that have happened to me in the past,
although its been awhile.
On Nov 13, 11:36 am, Nikolai Drozd dniko...@gmail.com wrote:
You have to use ${ name } and not { $name }
nolsen01 wrote:
I'm following the book at pylonsbook.com. I've created a project
called TemplateDemo and when I create a template greeting.html and
call it with render(), instead of replacing {$name} with the value of
the variable I've passed, it simply shows greeting.html with the
{$name} in it. Its has if I'm viewing the html file statically.
Here is my controller code:
import logging
from pylons import request, response, session, tmpl_context as c
from pylons.controllers.util import abort, redirect_to
from templatedemo.lib.base import BaseController, render
log = logging.getLogger(__name__)
class GreetingController(BaseController):
def index(self):
name = 'Pylons Developer'
return render('/greeting.html', extra_vars={'name' : name})
and here is my greeting.html code:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://
www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
head
titleGreetings/title
/head
body
h1Greetings/h1
pHello {$name}!/p
/body
/html
What gives?
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: WebOb API
On Nov 1, 2009, at 5:39 PM, Ian Bicking wrote: On Sun, Nov 1, 2009 at 5:47 PM, Ben Bangert b...@groovie.org wrote: On Oct 29, 2009, at 1:22 PM, Ian Bicking wrote: So, it's about time that WebOb came to 1.0. For 1.0 I'd like to settle the API as much as possible. But I'd also like to move further to getting WebOb used for more frameworks. I don't expect that to happen before 1.0, but if there are API changes that will make that easier later, then maybe we can get those in. What happened to getting all the fixes and improvements Armin had for the Request/Response in Werkzeug into Webob? Is that a 1.1 thing? Could we at least get the API more similar for 1.0 even if the bug fixes from Werkzeug's Request object aren't pulled in? I'm not really aware of what those fixes are, or if they apply to WebOb (I suspect they don't). If there are specific API differences where they could be unified, well... we can discuss them. Talking with Armin, his biggest concerns have been around handling the request body (which is tricky at best; Wekzeug is more naive but less likely to be unperformant; rather it just won't work in these difficult situations). If there are nasty situations, I hope they can be fixed in WebOb, though I'd like to make everything Work, even in cases that aren't a priority for Wekzeug (mostly related to contention for the request body, as with middleware). Another thing Armin specifically mentioned is that he doesn't like that all WebOb requests are mutable. He prefers the Werkzeug setup where the base request object is basically read-only, and there is a subclass that can be written to. First, that would be rather hard to do with WebOb (maybe a read-only flag would be possible, but the functionality would be there regardless, only explicitly disabled via a flag), and secondly I don't particular agree with him on this matter, and I don't think there's a strong justification for removing this functionality (I am of a mind that if you don't want to modify the request, then don't do it). There's at least some good arguments for immutability: o Request object becomes much simpler with way less code (see Werkzeug) o Becomes easier to cache attributes and avoid property overhead (see Werkzeug) o You can still change environ you just have to do it manually o One step towards Werkzeug possibly adopting WebOb (when the aforementioned goal was being adopted by more frameworks) The drawbacks are we lose that sometimes handy functionality and that WebTest relies on it. How much does WebTest really rely on it though (it doesn't really seem like much)? And just to clarify, the Werkzeug wrappers aren't totally immutable, you can still modify their attributes and add your own attributes. Its exposed data structures (like MultiDicts) are immutable and it doesn't write to environ. A middle ground might be what Werkzeug does now but allowing writes to data structures like MultiDicts -- just not propagating the changes to environ. If there are other things I'm not aware of them; you'll have to list them more specifically. Werkzeug also has some pieces of functionality separated out via Mixins, this mainly makes the code cleaner. It doesn't actually have a mutability Mixin, that's just a proposal by Armin to find a middle ground with WebOb. One big difference is it stores file uploads in a different container than the main request.POST multidict, and more importantly doesn't use cgi.FieldStorage for those file objects or for parsing the form. With that alternative form parser you can also easily limit the size of form posts/file uploads. The other API differences are probably mostly naming of attributes, existence of more or less shortcuts, things we probably don't differ very much on. Armin also claimed WebOb doesn't handle invalid cookies as well as Werkzeug. -- Philip Jenvey --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Can I turn proxy-prefix off in a controller/selectively?
i recently learned that...
redirect_to -- looks up in mapper
redirect -- does not
try doing a redirect('/site')
in terms of losing the cookie info, are you sure the cookies are in
the browser ? try making sure you have a correct path and domain
set. its easiest to check that in the browser. also try setting a
cookie from the legacy app, to see how its configuring the path/domain.
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
RE: Can I turn proxy-prefix off in a controller/selectively?
Beauty!
redirect works. Thanks
-Original Message-
From: pylons-discuss@googlegroups.com [mailto:pylons-
disc...@googlegroups.com] On Behalf Of Jonathan Vanasco
Sent: Friday, November 13, 2009 4:04 PM
To: pylons-discuss
Subject: Re: Can I turn proxy-prefix off in a controller/selectively?
i recently learned that...
redirect_to -- looks up in mapper
redirect -- does not
try doing a redirect('/site')
in terms of losing the cookie info, are you sure the cookies are in
the browser ? try making sure you have a correct path and domain
set. its easiest to check that in the browser. also try setting a
cookie from the legacy app, to see how its configuring the path/domain.
--~--~-~--~~~---~--~~
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: [tg-trunk] TurboGears Black Friday Sprint (11/27/2009)
On Nov 13, 2009, at 1:02 PM, percious wrote: If you are from the US, you may be familiar with the custom of racing to your local commercialization hub before the sun rises and beating your fellow man over the head to get that cute little fifi doll your daughter wants for christmas. This endeavor is often fueled by the previous day’s binge on tryptophan-laced poultry. TurboGears wants you to know there _is_ an alternative to this ruckus behavior. While it may not offer a method of transference of the latest flu virus strain, you may come hang out with the leaders of our community on irc://#turboge...@irc.freenode.net . and ask questions and help your fellow man. In the spirit of thanksgiving, you may decide it would be good to return the 1000s of lines of code contributed by helping us document that mess*! November 27, 2009 starting around 9am MST, ending when Chris passes out, we will convene and work on the 134 todo items left in our documentation. If some of you are near Denver/Boulder, CO that day, I would be happy to organize an on-site meetup, please let me know. So, the day after thanksgiving, why not act gluttonous for one more day (with your writing) and lets see if we cant close another 60 todo Items as we did on the last doc push. Be you an advanced super 37173 user, or someone completely new to TG, we have got something for you to do! Lets work together to make the formal 2.1 release of TG the best yet so far, with the highest level of completed documentation evar! Plus I hear those 134 todo items are 20% off and include a free tote bag* * Only to the first 25 customers. Offer not valid in Bavaria. -- Philip Jenvey --~--~-~--~~~---~--~~ 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
