Nevermind, I read the pylons.config doc strings and got the answer I needed.
Jose
Jose Galvez wrote:
> Dear Ben,
>
> If you change the default tempalte engine, how do you add back the
> standard myghty engine? Ive tried this code:
> config.template_engine.pop()
> config.add_template_engine('cheetahpylons', 'jtest.chTemplates', {})
> config.add_template_engine('pylonsmyghty', 'jtest.templates', {},
> alias='myghty')
>
> but then when I try to run render_response('myghty', 'serverinfo.myt') I
> get the following error:
> TopLevelNotFound: ComponentNotFound: Cant locate component
> jtest.templates.serverinfo.myt (dhandler)
>
> If I run render_response('myghty', '/serverinfo.myt') I get this error:
>
> TopLevelNotFound: ComponentNotFound: Cant locate component
> /serverinfo.myt (dhandler)
>
> file:
> c:\python24\lib\site-packages\myghty-1.0.2dev_r2062-py2.4.egg\myghty\request.py
> line 448
>
> I've not tried adding any other template engines, my cheetahpylons
> engine is the only one I currently have installed
> Thanks in advance for any and all help
> Jose
>
> Ben Bangert wrote:
>
>> Pylons 0.9 is getting close to a release, I'm estimating a week or two
>> away as I'd like to get it out before EuroPython. There's a few major
>> changes to the core which make the request cycle significantly simpler
>> in 0.9, and a few things to note for those moving a 0.8 project to
>> 0.9. At this point we don't fore-see any big changes happening before
>> 0.9 is finalized, so if there's something in here you're really eager
>> to have, give it a try.
>>
>>
>> New Call-Cycle
>> -----------------------
>>
>> This is the most significant change in 0.9. The request-cycle is
>> substantially simpler. In 0.8, controllers were called inside of
>> Myghty using a custom Myghty resolver class that used Routes.
>>
>> In 0.9, the request is handled in a WSGI call, the URL is looked up
>> with Routes, and the controller is called. It is then expected that a
>> Response object or a plain WSGI body is returned from the controller.
>> (I'll have a pretty diagram showing the simpler request cycle soon)
>>
>> There are no assumptions about what template language is used, just
>> that either a Response object is returned, or WSGI content (an
>> iterable) comes back. To make it easy to render templates and return
>> the response object, there's some convenience functions for templating:
>> http://pylonshq.com/docs/0.9/module-pylons.templating.html
>>
>> So a template render in an index action looks like:
>> def index(self):
>> return render_response('/my/template.myt')
>>
>>
>> New Templating
>> ------------------------
>>
>> All render calls go through our custom Buffet, and you can swap out
>> the default template engine for the one of your choice rather easily.
>> Here's all that's necessary to use Kid templates instead of Myghty
>> templates. Docs for the templating module that has the render calls:
>> http://pylonshq.com/docs/0.9/module-pylons.templating.html
>>
>> In proj/config/middleware.py, right after the 'config.init_app....':
>> # Pull the other engine and put a new one up first
>> config.template_engines.pop()
>> kidopts = {'kid.assume_encoding':'utf-8', 'kid.encoding':'utf-8'}
>> config.add_template_engine('kid', 'proj.templates', kidopts)
>>
>> Now you could render a Kid template 'home.kid' with:
>> def index(self):
>> return render_response('home')
>>
>> If you want to use different configuration of the same template
>> engine, you can also alias a template engine. Perhaps you want another
>> set of Kid templates, you could just add under the above config lines:
>> config.add_template_engine('kid', 'proj.templates', kidopts,
>> alias='kid2')
>>
>> And in an action:
>> def space(self):
>> return render_response('kid2', 'other.template')
>>
>>
>> New Interactive Shell
>> ------------------------------
>>
>> Inspired heavily by TurboGears the other day, I added an interactive
>> shell feature. It also loads up your app under a paste.fixture TestApp
>> so that you can interactively test requests and check out their
>> output. Also, the db uri and information from your config file is
>> loaded up such that SQLObject models using the Hub functionality work.
>>
>> To use it, from inside your projects main dir:
>> paster shell
>>
>>
>> Legacy Mode
>> --------------------
>>
>> To ensure that 0.8 apps work with as little modification (none at all
>> in most cases), Pylons 0.9 has a legacy mode. It's activated when your
>> initialize the main WSGI app in your middleware.py file with:
>> app = pylons.wsgiapp.make_app(config)
>>
>> In new 0.9 projects, the lines that initializes the main WSGI app is:
>> app = pylons.wsgiapp.PylonsApp(config)
>>
>> Legacy mode add's two minor changes to the request cycle which can be
>> seen on line 79 and 103:
>> http://pylonshq.com/project/pylonshq/browser/Pylons/trunk/pylons/wsgiapp.py
>>
>>
>> 103 sets up a 'm' object that acts like the Myghty object in 0.8, and
>> it creates a Response object in a thread-local to buffer the content
>> the m object writes out. Line 79 then pulls that Response object when
>> the controller fails to return anything. That's pretty much all it
>> takes to have 0.8 legacy compatibility.
>>
>>
>> Upgrading a 0.8 App
>> -----------------------------
>>
>> There's two ways you can go about upgrading your app to 0.9. Out of
>> the box, 99% of your 0.8 app should *just work* under 0.9.
>>
>> 1) Stick with 'legacy' mode and slowly convert your actions to return
>> Response objects. This will first require you to update
>> yourprojb/lib/base.py, so that it imports the additional names you
>> need, and your BaseController needs to return the Controller call
>> instead of just calling it. This in your BaseController, this line:
>> Controller.__call__(self, action, **params)
>>
>> Should be:
>> return Controller.__call__(self, **params)
>>
>> And make sure to add the following imports in base.py as well:
>> from pylons import Controller, c, g, h, cache, request, response, session
>> from pylons.decorators import jsonify, rest, validate
>> from pylons.templating import render, render_fragment, render_response, \
>> render_response_fragment
>>
>> You can then slowly convert your actions to return response or return
>> render_response calls.
>>
>> 2) Update your project templates to 0.9, and immediately remove all
>> references to the 'm' object. This step could also be done after Step
>> 1 for a more graceful switch-over. Updating your templates can be done
>> by running paster over your app:
>> paster create --template=pylons yourproj
>>
>> It will prompt you to overwrite, replace, diff, or backup any existing
>> files that have changed in Pylons 0.9. I'd suggest having them backed
>> up, then copying in your changes as needed to the new files.
>>
>> You'll then need to go through and replace m.subexec calls with return
>> render_response('/template....') calls.
>>
>>
>> Most of this information will be refined and put up in the new 0.9
>> docs section that we're working on.
>>
>> 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 [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss
-~----------~----~----~----~------~----~------~--~---
