Re: Use Pylons environment from external Python script
On Nov 21, 2007 5:52 AM, Ian Bicking [EMAIL PROTECTED] wrote: Konstantin Alexandrov wrote: Hello all. I need to use my Pylons project's environment (config, models etc) from external script launched by cron. How to do that? If you use PasteScript trunk, you can do paster request config.ini /cron, which runs a request to /cron. If you are not using PasteScript trunk you can still use paster paste.paster_command extensions point. Quite verbose but it works. Max. -- Max Ischenko http://www.developers.org.ua/ -- Ukrainian software developers community http://maxischenko.in.ua/ -- my blog (Russian) --~--~-~--~~~---~--~~ 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: Multiple controller calls
def test(self, var):
id = var
if int(id) 5:
return 'GREATER THAN'
else:
return 'LESS THAN'
You'll run into trouble here if var is '' or contains non-numeric
characters. Your default value in the routing rule is novar, which
would raise a ValueError exception and ultimately a 500 Internal
Server Error. Since we can't trust users to always put numeric
values, you should trap the case thus:
Yeah, I know. The novar default was left over from passing strings
to the page via querystring. Like I said I'm just throwing stuff at
the framework right now to kind of feel it out and get a grip on how
it handles stuff.
Just to rule out the possibility that I did somthing wierd I created a
new project, added a new controller (changed nothing, its index action
returns 'Hello World', and just add the line to by BaseController to
print out the class name and received almost the same result:
CtestController
TemplateController
ErrorController
TemplateController
ErrorController
TemplateController
ErrorController
TemplateController
ErrorController
Does it make a difference if you omit the trailing slash?
Nope.
You mean the error controller itself is failing to return a page?
Here's my new test BaseController on the old project:
fp = open('dump.txt', 'w')
class BaseController(WSGIController):
def __call__(self, environ, start_response):
Invoke the Controller
# WSGIController.__call__ dispatches to the Controller method
# the request is routed to. This routing information is
# available in environ['pylons.routes_dict']
fp.write(self.__class__.__name__ + ':\n\n')
try:
result = WSGIController.__call__(self, environ,
start_response)
fp.write('\n'.join(result) + '\n\n')
return result
finally:
Session.remove()
And here's the output file (sorry about the length):
HelloController:
GREATER THAN
TemplateController:
html
headtitleNot Found/title/head
body
h1Not Found/h1
pThe resource could not be found.
br/
!-- --/p
hr noshade
div align=rightWSGI Server/div
/body
/html
TemplateController:
html
headtitleNot Found/title/head
body
h1Not Found/h1
pThe resource could not be found.
br/
!-- --/p
hr noshade
div align=rightWSGI Server/div
/body
/html
TemplateController:
html
headtitleNot Found/title/head
body
h1Not Found/h1
pThe resource could not be found.
br/
!-- --/p
hr noshade
div align=rightWSGI Server/div
/body
/html
ErrorController:
!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
titleServer Error 404/title
style type=text/css
body {
font-family: Helvetica, sans-serif;
}
table {
width: 100%;
}
tr.header {
background-color: #006;
color: #fff;
}
tr.even {
background-color: #ddd;
}
table.variables td {
verticle-align: top;
overflow: auto;
}
a.button {
background-color: #ccc;
border: 2px outset #aaa;
color: #000;
text-decoration: none;
}
a.button:hover {
background-color: #ddd;
}
code.source {
color: #006;
}
a.switch_source {
color: #0990;
text-decoration: none;
}
a.switch_source:hover {
background-color: #ddd;
}
.source-highlight {
background-color: #ff9;
}
/style
!-- CSS Imports --
link rel=stylesheet href=/error/style/orange.css type=text/css
media=screen /
!-- Favorite Icons --
link rel=icon href=/error/img/icon-16.png type=image/png /
style type=text/css
.red {
color:#FF;
}
.bold {
font-weight: bold;
}
/style
/head
body id=documentation
!-- We are only using a table to ensure old browsers see the message
correctly --
noscript
div style=border-bottom: 1px solid #808080
div style=border-bottom: 1px solid #404040
table width=100% border=0 cellpadding=0
bgcolor=#E1trtd valign=middleimg src=/error/img/
warning.gif alt=Warning //tdtdnbsp;/tdtdspan
style=padding: 0px; margin: 0px; font-family: Tahoma, sans-serif;
font-size: 11pxWarning, your browser does not support JavaScript so
you will not be able to use the interactive debugging on this page./
span/td/tr/table
/div
/div
/noscript
!-- Top anchor --
a name=top/a
!-- Logo --
h1 id=logoa class=no-underline href=http://
www.pylonshq.comimg class=no-border src=/error/img/logo.gif
alt=Pylons title=Pylons//a/h1
p class=invisiblea href=#contentSkip to content/a/p
!-- Main Content --
div id=nav-bar
!-- Section Navigation --
h4 class=invisibleSection Links/h4
ul id=navlist
li class=activea href=# accesskey=1
class=activeError 404/a/li
/ul
/div
div id=main-content
div class=hrhr class=hr //div
div class=content-padding
div id=main_data
Re: [ANN] ToscaWidgets 0.2 Release candidate available
Mike Orr wrote: On Nov 19, 2007 5:36 AM, Alberto Valverde [EMAIL PROTECTED] wrote: Hi people, I've just registered and uploaded to PyPI (aka cheeseshop) the first release candidate of the first beta of ToscaWidgets and twForms. This means that the API is stable enough to safely build and distribute widgets with it. Furthermore, a little envy from Pylons' new Trove classifier, and Turbogears' old one, has pushed me to request one and it has been conceded ;). Environment :: Web Environment :: ToscaWidgets Widget eggs you make might want to add it to setup.py so their metadata can be pulled from PyPI and listed at toscawidgets.org (a là TG widgets). The PasteScript template inside TW already adds it if you create a widget skeleton with paster create --template toscawidgets. I thought that syntax made a standalone application. But what's a standalone ToscaWidgets application, since it doesn't have its own web framework? And how can you combine this with Pylons? It looks like you'd have to create a TW application, copy what you want into the Pylons application, and then delete the TW application? It's not a ToscaWidgets standalone application but a ToscaWidgets egg. This egg can be the listed in the install_requires of any application that needs it for easier deployment. It is really only useful to create a widget egg if you plan to distribute it or want to reuse it easily in multiple apps, for one-shot widgets you can just declare them inside a module inside your app's package. BTW, I've found PasteScript useful for much more than scaffolding Pylons or TG applications (or widget eggs). In a former job we used it extensively to script the installation, via a web control panel, of PHP applications (among others). Alberto --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
New Program Send Big File Fast and Easy Apply For FREE!!!
WHO WE ARE YouSendIt is the No. 1 digital file delivery company serving business and individuals businesses who want a easy, secured, reliable and faster way to SEND, RECEIVE and TRACK DIGITAL FILES. YOUSENDIT SOLUTION We replace the hassles of dealing with unreliable FTP servers, eliminate the frustrations of bounced email attachments. With YouSendIt you also save time and money not having to burn CDs and using expensive overnight couriers. Get Free Code: Limited Time Only! http://www.tkqlhce.com/click-2667396-10501907 --~--~-~--~~~---~--~~ 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: Integration of TIBCO AJAX Framework
That screencast of TIBCO from way back in 2005 was pretty amazing... http://weblog.infoworld.com/udell/2005/05/25.html Wonder why the limits on the supported browsers. Assume it would be local storage type things. Didn't realize they had opened it up. BSD license. Makes you wonder. Hmmm. According to the docs: TIBCO General Interface Builder TIBCO General Interface Builder runs on the following browsers. Internet Explorer 7.0 and 6.0.x for: Microsoft Windows (x86) Windows 2003 Server Windows XP Professional SP1 and SP2 Windows Vista Firefox 2.0 and 1.5.x for: Microsoft Windows (x86) Windows 2003 Server Windows XP Professional SP1 and SP2 Windows Vista --~--~-~--~~~---~--~~ 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: [ANN] ToscaWidgets 0.2 Release candidate available
On Nov 21, 2007 6:03 AM, Alberto Valverde [EMAIL PROTECTED] wrote: It's not a ToscaWidgets standalone application but a ToscaWidgets egg. This egg can be the listed in the install_requires of any application that needs it for easier deployment. It is really only useful to create a widget egg if you plan to distribute it or want to reuse it easily in multiple apps, for one-shot widgets you can just declare them inside a module inside your app's package. BTW, I've found PasteScript useful for much more than scaffolding Pylons or TG applications (or widget eggs). In a former job we used it extensively to script the installation, via a web control panel, of PHP applications (among others). I thought the only legitimate use for paster create was to make a WSGI application for paster serve. So here it's just copying an arbitrary egg skeleton to a directory? -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Multiple controller calls
On Nov 21, 2007 5:35 AM, Justin [EMAIL PROTECTED] wrote: Just to rule out the possibility that I did somthing wierd I created a new project, added a new controller (changed nothing, its index action returns 'Hello World', and just add the line to by BaseController to print out the class name and received almost the same result: CtestController TemplateController ErrorController TemplateController ErrorController TemplateController ErrorController TemplateController ErrorController And here's the output file (sorry about the length): As far as I can tell, the output looks correct. TemplateController returns a Not Found page which passes through the base controller and is intercepted by the ErrorDocuments middleware, which makes its own request for a fancy error page. But as to your original question, why TemplateController is being invoked at all, I can't tell. There's a TransLogger middleware you can use to get an Apache-style access log. You can enable it in middleware like this: from paste.translogger import TransLogger app = TransLogger(app, setup_console_handler=True) I've only had luck putting this *below* the error middleware, although intuitively it seems it should be above. The problem is that in one position you don't get the original statuses and URLs, you get the ones the error middleware has changed them to, which is not helpful for debugging. Anyway, if you setup the TransLogger and it shows multiple requests for the same successful browser request, that will give a little more light on what Template URL is being requested and why. Alternatively, you could dump environ['PATH_INFO'] to your 'fp' file. It may be worth dumping the entire environment actually, something like: import pprint; fp.write(pprint.pformat(request.environ)) Things to look for are the URL and routing args that were in effect when TemplateController was called. The referer would also prove the previous request called this one. Then the mystery becomes, what in the previous request caused this one? You don't need to dump the output anymore, since it looks correct for the controllers that were called. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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-compatible CMS tools
My reply follows in my next email. -- Forwarded message -- From: Graham Higgins [EMAIL PROTECTED] Date: Nov 21, 2007 4:27 AM Subject: Re Pylons-compatible CMS tools To: Mike Orr [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mike, On Nov 18, 11:46 am, Mike Orr [EMAIL PROTECTED] wrote: Are there any other Pylons-compatible CMS tools around? I had a paddle around in this area at the end of last year. Purely for my own porpoises, I hacked about with Turboblog, adapting the core from TG+Kid to Pylons+Genshi. It was mainly a proof-of-concept exercise designed to give me some direct experience with issues of integrating multiple apps at the top end of the WSGI stack but it did get me a part-usable blog (http://bel-epa.com/weblog/). I'd be happy to dump what I've got but I'm not sure that it's much of a contribution and it's certainly nowhere near what you described. IMHO, Turboblog's history is instructive to those considering developing Pylons apps for general consumption. Originally developed by Eli Yukelzon in early in 2006, Turboblog was largely ignored by the TG community, to the extent that Eli was disinclined to develop it further and offered it up for adoption. Earlier this year, the project was adopted by Florent Aide and moved to dejavu. The mailing list (http://groups.google.com/group/tb-discuss) reveals a similar apparent lack of interest, with the last posting made in mid-May. I don't know the current status of Turboblog. It may be that the lack of interest that Florent is experiencing is simply coincident with a slackening of interest in TG between Kevin taking a Real Job(tm) and Alberto's redefinition of TG as a pre- developed Pylons installation, but that doesn't really explain why it also languished while under Eli's care, TG was receiving quite a lot of interest at that time. It may be that an effective, well-designed framework (e.g. Pylons) gives developers such a wide range of possible approaches to developing an app that the idea of hacking on a pre-published generic app is less appealing than the idea of hacking it up oneself from scratch. Or, it may be that there just isn't enough critical mass in the userbase ATM to sustain the development of a generic app. Or, we're maybe we're trying to work at the wrong level. I've recently added ElixirGenXML to my stack of interesting things to fire up and test, perhaps that's the level at which we should be working. But even so, a simple thought experiment brings a dash of cool rationality: someone produces a spec of a Wordpress-alike blog for Pylons. How many folks are likely to rush to join the development team? I got quite a lot of illumination from Ben's ruminations on how the early adopters of Pylons took it in a different direction to that which the dev team initially anticipated. As Pylons gains more traction and exposure, the ratio between developers-doing-it-for- themselves and, ah, deployers will change and we'll probably see a lot more calls/bleats for deployer-friendly features like TG's DB browser (which people perceive as flattening the learning curve) and ready-built apps that can be deployed out of the box. OTOH, we do seem to be presented with an opportunity to lay down some best practice principles for integrating multiple apps in a single Pylons stack (at arbitrary levels in the cascade), mainly in terms of providing integrated cross-app support for user admin, prefs and privs --- a topic which, up to now, every app developer has felt free to address independently. Unfortunately, it rather requires a stable and commonly-accepted auth'n'auth solution, something which has yet to emerge from the mix, IMO. Cheers, Graham. --- END FORWARD --- -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: [ANN] ToscaWidgets 0.2 Release candidate available
On Nov 21, 2007, at 10:39 AM, Mike Orr wrote: On Nov 21, 2007 6:03 AM, Alberto Valverde [EMAIL PROTECTED] wrote: It's not a ToscaWidgets standalone application but a ToscaWidgets egg. This egg can be the listed in the install_requires of any application that needs it for easier deployment. It is really only useful to create a widget egg if you plan to distribute it or want to reuse it easily in multiple apps, for one-shot widgets you can just declare them inside a module inside your app's package. BTW, I've found PasteScript useful for much more than scaffolding Pylons or TG applications (or widget eggs). In a former job we used it extensively to script the installation, via a web control panel, of PHP applications (among others). I thought the only legitimate use for paster create was to make a WSGI application for paster serve. So here it's just copying an arbitrary egg skeleton to a directory? Sure, it could scaffold anything you want In fact PasteScript comes with a 'basic_package' template which is geared towards a basic python application. I've been using it any time I need to create a normal Python project. -- 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Multiple controller calls
On Nov 21, 2007, at 5:35 AM, Justin wrote: def test(self, var): id = var if int(id) 5: return 'GREATER THAN' else: return 'LESS THAN' You'll run into trouble here if var is '' or contains non-numeric characters. Your default value in the routing rule is novar, which would raise a ValueError exception and ultimately a 500 Internal Server Error. Since we can't trust users to always put numeric values, you should trap the case thus: Yeah, I know. The novar default was left over from passing strings to the page via querystring. Like I said I'm just throwing stuff at the framework right now to kind of feel it out and get a grip on how it handles stuff. Just to rule out the possibility that I did somthing wierd I created a new project, added a new controller (changed nothing, its index action returns 'Hello World', and just add the line to by BaseController to print out the class name and received almost the same result: CtestController TemplateController ErrorController TemplateController ErrorController TemplateController ErrorController TemplateController ErrorController Again, print out the PATH_INFO of the requested URLs and you'll figure out what's being requested from your browser. If you still don't believe me that your browser is making those requests, load live http headers or the like and watch what it's doing. =] Also try hitting the page with a simple HTTP client (curl -O http:// localhost:5000/): you'll see just one request. -- 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Re Pylons-compatible CMS tools
On Nov 21, 2007 4:27 AM, Graham Higgins [EMAIL PROTECTED] wrote: It may be that an effective, well-designed framework (e.g. Pylons) gives developers such a wide range of possible approaches to developing an app that the idea of hacking on a pre-published generic app is less appealing than the idea of hacking it up oneself from scratch. Or, it may be that there just isn't enough critical mass in the userbase ATM to sustain the development of a generic app. Or, we're maybe we're trying to work at the wrong level. I've recently added ElixirGenXML to my stack of interesting things to fire up and test, perhaps that's the level at which we should be working. But even so, a simple thought experiment brings a dash of cool rationality: someone produces a spec of a Wordpress-alike blog for Pylons. How many folks are likely to rush to join the development team? The problem is modularity. I may not be interested in TurboLog, Docudo, Plone, TRAC, pyBlosxom, etc in their entirety, but I'd like to use components from them if they were easily extractable, or even smaller functions to do certain tasks. That is the essence of Paste and Pylons, so it would be nice to extend this to a richer set of tools. For instance, we've talked about embedding wikis or a TRAC-like project manager into our sites eventually. Maybe we don't want all of Plone but that WYSIWYG text area that automatically recognizes formatted Word text would be useful. Things like that. Some users want a complete blog system ready to embed. Others want to take certain features and plug them into their own blog system, or even their not-really-a-blog system. I got quite a lot of illumination from Ben's ruminations on how the early adopters of Pylons took it in a different direction to that which the dev team initially anticipated. I'm curious about this. What do you mean? As Pylons gains more traction and exposure, the ratio between developers-doing-it-for- themselves and, ah, deployers will change and we'll probably see a lot more calls/bleats for deployer-friendly features like TG's DB browser (which people perceive as flattening the learning curve) and ready-built apps that can be deployed out of the box. We've got two or three types of users. One is the hacker type who prefers low-level tools like Paste, but found Pylons too convenient to ignore. These are people who might otherwise build their sites from scratch (SimpleHTTPServer, web.py). At the other extreme is the stereotypical Brian who wants something high-level that works out of the box, with AJAX, authentication, form widgets, DB browser, admin interface, and all the other gee-whiz features. These are the people who might otherwise choose Rails, Django, PHP, Java, etc. These people have generally passed up on Pylons because the features and ease-of-use aren't quite there yet. Then there's people in between who like Pylons' modularity for philosophical reasons, and/or also appreciate the add-ons (auth, internationalization, documentation, a future blog plugin, etc). Probably the majority of users fall into this category. Deployer-friendly features are of interest to both the second two groups, so there will continue to be increasing calls for those, although not in the Pylons core. However, calls for these are not new; they've been rumbling for at least a year. The developers have always responded, That's a great idea but we don't have time to do it right now. It's generally assumed that these will be available in a year or so. The most exciting thing to happen is TG's new interoperability with Pylons because it brings some of these features ready-made. Even more interesting is the @expose decorator added to Pylons-dev, which brings some of TG's output-mode flexibility to Pylons. It's interesting in the sense of, If they can do this, what next? OTOH, we do seem to be presented with an opportunity to lay down some best practice principles for integrating multiple apps in a single Pylons stack (at arbitrary levels in the cascade), mainly in terms of providing integrated cross-app support for user admin, prefs and privs --- a topic which, up to now, every app developer has felt free to address independently. Thus coming back to the question I raised earlier, how to embed a Pylons app in a Pylons app. One can embed at several different levels, so there are multiple answers to this. paste.urlmap, paste.cascade, route to a WSGI controller, have a stub controller that imports a Pylons app and uses make_app as a pseudo-controller. All of these seem viable but none have been well tested among the userbase. Unfortunately, it rather requires a stable and commonly-accepted auth'n'auth solution, something which has yet to emerge from the mix, IMO. AuthKit is trying to be that for Pylons, and for WSGI generally. But some sites also need to span non-WSGI and non-Python components. And ultimately you need a top-level authority for
