Re: Pylons 2 users guide, first draft
Hi,
from pylons.views import action
from ebro.db import DBSession as db
from ebro.sf import SFSession as sf
from pylons.controllers.util import Response
class MyHandler(object):
def __init__(self, request):
self.request = request
def login(self):
login = db.load_form('login.kk') # Pyro
response = Response(login)
response.content_type = 'application/vnd.mozilla.xul+xml'
The remote template is works well.
Thanks
kk
On Sep 30, 8:02 pm, Ben Bangert b...@groovie.org wrote:
On Sep 30, 2010, at 9:43 AM, Mike Orr wrote:
CC'ing pylons-devel because these will be FAQs.
@action
def login(self):
login=(db.load_form('login.kk'))
self.request.response_content_type =
'application/vnd.mozilla.xul+xml'
return login
@action
TypeError: __init__() takes exactly 1 argument (2 given)
The constructor is called with a request argument:
def __init__(self, request):
self.request = request
And @action is a decorator that requires arguments. Using @action is only
needed if you need to tweak the default's, ie, to limit the calling to a
request_method, or to assign a renderer. If you're doing something like:
config.add_handler('home_page', '/', handler=Home, action='index')
Then you don't need to use @action if its going to return its own Response
object.
So the easy way to think of it, the methods in your handler are all actions
still (just like in a Pylons 1 controller!), *but*, if you need to modify how
the action is called, how the return value of it is handled (ie, using
renderer), or how the action is registered (ie, its name), then you use the
@action decorator to modify those parameters.
def login(self):
login=(db.load_form('login.kk'))
self.request.response_content_type =
'application/vnd.mozilla.xul+xml'
return login
from pylons.controllers.util import Response
Then return a response object:
def login(self):
login = db.load_form('login.hh')
response = Response(login)
response.content_type = 'application/vnd.mozilla.xul+xml'
return response
There is also a render_template_to_response() function somewhere,
maybe in pylons.templating. It fills a template and creates a response
and returns it.
Yup.
Cheers,
Ben
--
You received this message because you are subscribed to the Google Groups
pylons-devel group.
To post to this group, send email to pylons-de...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
Re: Pylons 2 users guide, first draft
hi,
Pylons 1.0:
def login(self):
response.content_type = 'application/vnd.mozilla.xul+xml'
login=st.load_form('login.kk')
return login
I would like to try in Pylons 2.0.The template source
(st.load_form('login.kk') ) load from the remote server.
thanks
kk
On Sep 25, 8:21 pm, Chris McDonough chr...@plope.com wrote:
On Sat, 2010-09-25 at 09:27 -0700, Ben Bangert wrote:
On Sep 25, 2010, at 4:43 AM, Santhosh wrote:
I checked the new developing version of pylons .The new version is
entirely different from the older version . How can the developers
follow this ? .The developers compelled to have change the developed
software because if they remain in the older version there may be have
no support .
I don't understand what you mean by How can the developers follow this?.
I posted the entire thread here to try and help any other developers follow
it.
It's quite different, because the current Pylons 1.0 implementation is more
or less frozen, the implementation of most of it can't be changed since
so much of it was directly subclassed by developers in their own apps. This
style of customization was useful, but led to practical limitations on
extensibility, and our own ability to move Pylons forward. Rather than
re-inventing a bunch of code all over again, this new version went forward
to build on other code to allow the new Pylons to be substantially more
extensible, more efficient, and not have developers subclassing objects
from Pylons (which limits our ability to make changes to the framework).
I don't see what the worry is about remaining on the older version, the
Pylons book and the documentation is not going anywhere. The same level of
documentation support is going to remain available for Pylons 1.0, as there
is a large installed base that most likely isn't transitioning all that
quickly. There is no book for the new Pylons paradigms yet, so you'll see a
much higher level of 'support' in the way of blog postings, and
documentation for 1.0 for some time to come I believe.
The trunk is also currently entirely bw compatible with Pylons 1.0. You
don't *need* to use the new features.
--
You received this message because you are subscribed to the Google Groups
pylons-devel group.
To post to this group, send email to pylons-de...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
Re: Pylons 2 users guide, first draft
I need to add content_type. On Sep 20, 5:19 am, Chris McDonough chr...@plope.com wrote: On Sun, 2010-09-19 at 19:11 -0700, Ben Bangert wrote: On Sep 19, 2010, at 7:01 PM, Chris McDonough wrote: My $.02.. if you don't have a threadlocal tmpl_context around for people to jam values onto/into, it'd just confuse people if the dict values they returned from a view weren't passed as top-level names to the template, and instead were made available as the subkey tmpl_context. Well, there is a tmpl_context created on the request, that is available in templates as well. So it is around, created per-request as in Pylons 1.0, for ppl to add things to. So it might seem like a disconnect when someone add's things to tmpl_context in one case, but then it gets dropped in as a template global under the 'renderer=' scenario. Having everything a person wants to pass in, always go in under tmpl_context seems more consistent. Drawing an equivalence between Pylons 1 and 2 by having a request.tmpl_context seems like a bit of lose to me, because what people like about Pylons 1 tmpl_context is that they don't need to pass it around and they can just jam crap on to it from anywhere. Needing to both pass the request around as well as needing to write templates in terms of a tmpl_context seems like the worst of both worlds to me personally. What would the view return value mean in such a world? It just seems like a lot of indirection to document, and it would also mean forks of all the existing BFG templating systems. - C -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Pylons 2 users guide, first draft
self.request.response_content_type = 'application/vnd.mozilla.xul+xml' thanks kk On Sep 20, 2:13 pm, Madhu Alagu alma...@gmail.com wrote: I need to add content_type. On Sep 20, 5:19 am, Chris McDonough chr...@plope.com wrote: On Sun, 2010-09-19 at 19:11 -0700, Ben Bangert wrote: On Sep 19, 2010, at 7:01 PM, Chris McDonough wrote: My $.02.. if you don't have a threadlocal tmpl_context around for people to jam values onto/into, it'd just confuse people if the dict values they returned from a view weren't passed as top-level names to the template, and instead were made available as the subkey tmpl_context. Well, there is a tmpl_context created on the request, that is available in templates as well. So it is around, created per-request as in Pylons 1.0, for ppl to add things to. So it might seem like a disconnect when someone add's things to tmpl_context in one case, but then it gets dropped in as a template global under the 'renderer=' scenario. Having everything a person wants to pass in, always go in under tmpl_context seems more consistent. Drawing an equivalence between Pylons 1 and 2 by having a request.tmpl_context seems like a bit of lose to me, because what people like about Pylons 1 tmpl_context is that they don't need to pass it around and they can just jam crap on to it from anywhere. Needing to both pass the request around as well as needing to write templates in terms of a tmpl_context seems like the worst of both worlds to me personally. What would the view return value mean in such a world? It just seems like a lot of indirection to document, and it would also mean forks of all the existing BFG templating systems. - C -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Feedback on 9.7.1beta1
Hello,
paster create -t pylons kk version=0.144 sqlalchemy=true
template_engine=genshi zip_safe=false
from pylons.templating import render_mako as render
Is it useful for Multi-Template ?
Thanks
Madhu Alagu
On Apr 1, 8:46 am, Madhu Alagu [EMAIL PROTECTED] wrote:
Thanks,Now,It's working fine.
On Apr 1, 6:54 am, Mike Orr [EMAIL PROTECTED] wrote:
On Mon, Mar 31, 2008 at 7:00 AM, Madhu Alagu [EMAIL PROTECTED] wrote:
Hello,
pylons-0.9.7beta3.
login.py
def index(self):
return render('/login.mak')
I receive an error message NameError: global name 'render' is not
defined
You have to import it:
from pylons.templating import render_mako as render
If your controllers import * the base controller, you can put it in
the base controller. Otherwise you'll have to put it in every
controller.
Added to What's new in Pylons
0.9.7?http://wiki.pylonshq.com/pages/viewpage.action?pageId=11174779
--
Mike Orr [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-devel group.
To post to this group, send email to pylons-devel@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-devel?hl=en
-~--~~~~--~~--~--~---
