Re: Pylons vs Tomcat+GWT
Tycon wrote: because it's not ready so it's just a toy at this point, just like pyjamas, while GWT is used by real production websites (ever heard of gmail) Oh, sorry, I forgot you were looking for something serious. The you should definitely consider this: http://brainfuck.progopedia.org/ I've heard from very credible sources that it is what is powering the next generation of Coogl products about to hit the market. 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
[ANN] Rum 0.2 has been released
Hi, I'm proud to announce that we've just made the first public release of Rum and its SQLAlchemy plugin. Rum is an extensible WSGI web application to provide a RESTful interface for your app's model objects. You can think of it as an alternative to Django's admin for the non-django world. It is designed to be pluggable and support several data backends and views/form-generators but currently there are only two implemented: a data backend to handle SQLAlchemy mapped classes (RumAlchemy) and a form generator using tw.forms (tw.rum). You can read more about it at our website: http://python-rum.org and see a live demo here: http://demo.python-rum.org Enjoy, 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: RegistryMiddleware is a major overhead
Tycon wrote: Benchmarks indicate it is taking as much as 20% of request handling time (not including the user action). So, taking into account that 96.7% of the time of a request is inside the user action(empirically proved by the extensive benchmarks I've made which Im not going to publish), then setting up the registry takes than 1% of the total time. Not too bad IMHO. The question is why is it even necessary to use this registry facility ? So several apps can cohabitate the same process. Similarly, other request handling operations such as creating the request object may also be redundant, because the user may not be interested in all the attributes of the request object. So wouldn't it be better to provide those things on-demand (that is using a call interface to get things such as params, etc) instead of creating all that stuff by default even when it may not be needed ? Have you taken the time to study what webob.Request exactly does? I guess not since it actually *does* lazy load all attributes on demand. You're not penalized for attributes you don't access. 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
Tycon wrote: So no one is using this decorator for https ?? I guess it's only required for serious e-commerce websites, maybe there are no such pylons apps Pylons is used for quite a few hip and serious websites (listed at the pylons wiki if you'd care to look it up) though my guess is that you already know that and the provocative innuendo is just a (quite un-original) technique to prompt a quick response. Anyway, a can think of a few causes for the lack of answers so far: 1) No one is using that decorator. 2) Someone is using but not in an action requiring query string parameters. 3) People are achieving the same effect with different techniques 4) People in a position to fix have aren't reading this 'cause they've taken some days off given that new-years' has been on a Thursday (eg: myself. However, my life's so sad that I'm at home on a Friday night, with my girlfirend, my cat, my Citadelle gin tonic, and my laptop; with obviously nothing better to do than feed some random internet troll) 5) People in a position to fix this are out of patience and have decided to ignore your posts. #1 I doubt since people don't usually submit code for the sake of it. #3 wouldn't be a surprise since the Pylons usually targeted to developers who have already a well equipped toolbox around. I'll place my bets on a combination of #3#4 (#3.5?), I believe it's too early for #5 yet, though you're approaching it a good speed... Now seriously. You've found a bug, congratulations and thanks That's already 2 in less than a week which is quire remarkable and it's certainly preferable an out-of-tone bug report than none at all. However, I think you'd be more positively considered around here if instead of bitching around you'd showed at least a little appreciation for the software you're using for free to build a serious e-commerce website which will probably bring you some revenue. Bonus points if you submit a patch for the bug you've found (you've already proved that you're perfectly capable of doing so) through the conventional channels (the bug tracker is usually the best place) and a unit-test for it if you feel extra-generous. Thanks, 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 pylons-discuss+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: pylons.decorators.secure.https throws away the query string ?
Tycon wrote:
that would only work if the web server can determine if a particular
request should be http or https, which it could do only if there was
something in the request URI to indicate that (like the URI begnning
with /secure for example).
But what if I have an arbitrary URI (e.g. /hello/login) that should
redirect to https, but others (e.g. /hello/logout) that should not ?
Regexps are fun! With nginx:
server {
rewrite ^(.*/login) https://example.com$1 permanent;
}
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
pylons-discuss+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Recommended way to build forms
Hi all, Finally I will be getting around to build a proof of concept, for a project I will be working on, in pylons. So after all those mails from me with: I don't know pylons, just python, this might be a real change ;) I have started looking into what I will really need for the project, and as it will include quite a bit of forms, I looked into the FormBuilding stuff. I stumbled upon that sentence: Looking forward it is likely Pylons will soon be able to use the TurboGears widgets system which will probably become the recommended way to build forms in Pylons. The question is: What would be the best practice for building quite a bit of forms? Is there another way than FormBuild which is already stable enough for a production site (or will be stable enough in ~2 months)? Or should I stick to the FormBuild things? I'm using tw.forms (aka: ToscaWidgets, disclaimer: I wrote a great part of it) in several production sites sucesfully. However, it's got a deserved reputation of being badly documented around here since it stood undocumented for over a year. Anyway, this has recently changed. Better take a walk around http://toscawidgtes.org and judge for yourself :) 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 -~--~~~~--~~--~--~---
Re: Debugging failed tests with pylons globals
Justin Tulloss wrote: () In addition, it's very difficult to inspect the object that an SOP refers to since it obfuscates the object's __dict__. This trick can help: req = pylons.request._current_obj() # get current request object wrapped by SOP print dir(req) Again, it's just a matter of documentation IMHO. The alternative would be to make Pylons apps singletons like TurboGears 1, CherryPy 2, Django... are and that would solve the root of the problem. A stacked proxy is only needed when the possibility exists of a WSGI app/middleware dispatching to another application that makes use of the same SOPs (a pylons app that calls another pylons app, or an app that uses pseudo-middleware [1] X that calls an app that also uses X). However, this alternative would be a *huge* step backwards IMO since it would make this pseudo-middleware less interoperable After all, from what I understand, one of Pylons design goals is to let you build your app from all this tiny wsgi pieces that play well together. Alberto [1] By pseudo WSGI middleware I mean middleware that is not really WSGI middleware since middleware should be transparent to the application it wraps, that is, if it's missing from the stack then the application could not care less about it. These are more like a fancy function decorator which usually sets setup some context for some library downstream that needs it, for example: toscawidgets, beaker, etc... --~--~-~--~~~---~--~~ 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: Debugging failed tests with pylons globals
On Mon, Jul 7, 2008 at 10:04 PM, Justin Tulloss [EMAIL PROTECTED] wrote: I have to admit that despite my digging through the source, I do not have a good understanding of the StackedObjectProxy class and am constantly doing battle with it. I don't think there's anybody who doesn't do battle with StackedObjectProxy. Hahaha :) I fully agree. However, I also think they're the necessary evil that makes Pylons so powerful, IMHO. What I *love* about Pylons (opposed to TG1, CP2, Django...) is that applications are not singletons but instances so you can have several of them happily sharing the same process. This has changed the way I design my webapps since I can now compose them out of several smaller, easily testable, apps and route to them with yet another app (thanks to the stacked part). For example, first Pylons app was a control panel for an ISP which I migrated from TG1 and Pylons helped me solve the issue of giving some clients their own panel which they can sublicense very elegantly: just give them a different instance of the whole app pointing to their database schema with their own auth policy, etc... StackedObjectProxy might not be the best implementation (although I can't imagine how to improve it since there are so many edge cases involved..., eg: those that have been tripping people over when testing) but it is clear that something like this is needed as there are other packages implementing similar functionality for other frameworks/systems (ie: PJE's Contextual, and I'm sure Zope has their own SOP thingie somewhere). A way I can think to fix the root of the problem is to remove all stacked object proxies, bind the app globals to the app instance (whose lifecycle is the same as the process) and pass the per-request stuff around as function arguments. Perhaps the app instance as well, or at least bind it to the controllers when they're instantiated. Obviously, this will make the API much less attractive due to the param-passing nightmare (but will make FPers very happy ;) An intermediate solution, which I favor and have been experimenting with lately, is to limit the SOPS to just one: pylons.app (the app instance that holds database connections, cache, etc). Perhaps another SOP at pylons.app.request could be useful so the request is easily accessible from helpers intented to be used inside the context of a request. pylons.c would then become an attribute of the controller (whose lifecycle only spans one request as it does now) as well as the response, the request, the session, etc... (so they don't have to be passed around as controller action's arguments and routing vars can be passed instead). Bonus points if the app that instantiated the controller is also bound to the controller instance since then the controller can refrain form accessing any SOP at all which simplifies the implementation of async apps or apps that stream content which need access to the context from the WSGI iterator. What's the advantage of this: Much easier to understand the whole system and to explain it: pylons.app is magic, it does this and that and you can only access it while a request is in place or when you've mocked it for tests. 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 -~--~~~~--~~--~--~---
Re: tests fail because of g
Jonathan Vanasco wrote:
I have several helper classes that use g from pylons
You have a design problem then :) pylons.g is really a substitute for
module-level singletons so you can have them associated to an app's
instance and have several of these coexisting in the same process
without conflicts (eg: several blog instances each with it's own db
connection to a different database). This is actually the same problem
you would have if you depended on global state: More difficult to
isolate tests, more difficult to set them up, etc...
If you really want to go this route you can either mock it (using the
same pattern as has been suggested to mock pylons.session) or test the
whole stack so PylonsApp takes care of setting up and tearing down the
app context on every request.
app = paste.deploy.loadapp('config:mytestconfig.ini')
app = webtest.TestApp(app)
resp = app.get('/some/test/method')
assert resp.some_test_var == 'foo'
the controller action that responds to the above url can place variables
in environ['paste.testing_variables'] and they'd be bound to the test
response that TestApp.{get,post,put,etc...} returns:
def some_controller_method(self):*
if* *'paste.testing_variables'* *in* request.environ:
request.environ[*'paste.testing_variables'*][*'some_test_var'*]
= 'foo'
However, the right way to do it, IMHO, would be to separate the
functions/classes that depend on g in two. For example, say you needed a
pylons.g.db_connection inside a helper function bar:
def side_effect_free_bar(db_connection):
# do something with db_connection and refrain from accessing global
state
# this should be pretty easy to unit-test since it's output depends
solely on it's arguments.
# You can easily pass a db_connection you've explicitly prepared for
testing
def bar():
# This one you would test inside functional/integration tests, if at
all.
return side_effect_free_bar(pylons.g.db_connection)
HTH,
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
-~--~~~~--~~--~--~---
Re: Setting filename in a response
Pavel Skvazh wrote: Rather basic question. I've got to return a text file. response.headers['Content-Type'] = 'text/plain' return 'Hello, cruel world' The dialog pops out, but the filename is obviously blank and the browser comes up with some random one. How do i set it manually? fname = hello_world.txt response.headers['Content-Disposition'] = \ 'attachment; filename=%s' % fname 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 -~--~~~~--~~--~--~---
Re: Calling a WSGI application from an action
Alberto Valverde wrote: I had a similar problem when mounting Trac inside a Pylons application as a controller. Apparently, at some stage environ['wsgi.input'] was consumed hence POST requests were seen blank by Trac once they reached it. I solved it using this piece of middleware [1] stacked closest to the server [2] to cache input in a regular temporary file so it can be 'rewound' before passing the request to Trac [3]. WebOb had some functions to do this, but after thinking about it I made it a bit easier. With WebOb trunk you can now do: req = Request(environ) req.make_body_seekable() And then at any time you can do req.body_file.seek(0) (or environ['wsgi.input'].seek(0)) before sending the request on to another application. req.copy() also does this, but if the body has been eaten by something like paste.request.parse_formvars (what all but the tip of Pylons uses, I think) then it won't really work, so you have to prep the environment this way. This looks very useful, I'll probably rewrite the code I posted sometime to make use of this feature and make it simpler. It's about the same thing as what you did, but you'd be better off using tempfile, tempfile has actually been one of my most recent discoveries in the standard library :) Just wanted to get rid of the annoying os.tempnam warning so I reinvented the wheel. 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 -~--~~~~--~~--~--~---
[ANN] ToscaWidgets 0.9.2 has been released
Hi all, We've just released ToscaWidgets 0.9.2. Here's the changelog [1]: 0.9.2 (Jun 8, 2008) -- * Template engine plugins are now loaded lazily. * The v=modfied_time query string argument is no longer appended to resources since this method is not reliable with zipped eggs and causes some trouble. As a plus requests should now be faster since there are no disk hits for this reason. * The CP filter in mods.tg now handles staic file serving instead of registering directories with CP's static filter so resources from zipped eggs work properly. * Implemented a setuptools commands to copy all static resources from a series of distributions into a direcory where a fast web-server can serve them. Optionally, if YUICompressor is installed, it can compress CSS and JS in the destination directory. * Removed dependency from Paste, changed to lighter WebOb. * TW's middleware can now serve static resources from zipped eggs. * feeder.py is no longer included. * js_function arguments can now include other js_calls and js_callbacks at any level of nesting. * repetitions and template caches are now LRUCaches to set an upper limit on memory usage. The documentation for this release has been updated and is available at: http://beta.toscawidgets.org/documentation/ToscaWidgets tw.forms 0.9.1 has also been released which takes advantage of new features in TW. Special thanks go to Paul Johnston who has found and fixed some bugs I (Alberto) have introduced in some of the refactorings. Enjoy, Alberto [1] See also http://beta.toscawidgets.org/documentation/ToscaWidgets/changelog.html --~--~-~--~~~---~--~~ 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: Calling a WSGI application from an action
Alex Marandon wrote: 2008/5/30 Ian Bicking [EMAIL PROTECTED]: () However, there is a problem that the POST body can be eaten up. WebOb specifically tries to reconstruct it, but not for file uploads (simply because I didn't get around to it, because it's harder to construct than a simple POST form). And maybe what you are encountering is this same issue. Hi Ian, thanks a lot for answering my message. One thing I don't understand, is why the POST body gets deconstructed in the first place. I don't have a deep understanding of WSGI yet, but I thought one of its advantages was to allow developers to build arbitrary chains of middlewares and applications that are not aware of each others. So how come Pylons is modifying the POST body in such a way that it can't be used by subsequent WSGI component in the chain? I had a similar problem when mounting Trac inside a Pylons application as a controller. Apparently, at some stage environ['wsgi.input'] was consumed hence POST requests were seen blank by Trac once they reached it. I solved it using this piece of middleware [1] stacked closest to the server [2] to cache input in a regular temporary file so it can be 'rewound' before passing the request to Trac [3]. Hope it helps, Alberto [1] http://beta.toscawidgets.org/trac/twWebSite/browser/twwebsite/lib/inputsaver.py [2] http://beta.toscawidgets.org/trac/twWebSite/browser/twwebsite/config/middleware.py#L99 [3] http://beta.toscawidgets.org/trac/twWebSite/browser/twwebsite/controllers/tracdelegate.py#L16 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
paste.registry as a standalone EGG
Hi, Are there any plans to pull paste.registry out of the Paste distribution into a separate one? I've recently removed Paste's dependency from ToscaWidgets in favor of smaller WebOb and ended up copying the registry.py module almost verbatim which is certainly sub-optimal. I believe the registry is useful enough outside of paste and fits with the general trend of breaking Paste up into smaller pieces. As far as I can tell, paste.registry only needs Paste for the threadlocal (is 2.3 support still needed?) and an import from eval_exception inside get_request_id which could be conditional. If I get a pointer into a way to best remove these deps. I'll gladly do the grunt work of creating a new distribution, graft the registry back into the paste namespace (with a setuptools' namespace packages) and contribute it back. Regards, Alberto -- the humbleness of a warrior is not the humbleness of a beggar. The warrior lowers his head to no one, but at the same time, he doesn't permit anyone to lower his head to him. The beggar, on the other hand, falls to his knees at the drop of a hat and scrapes the floor for anyone he deems to be higher; but at the same time, he demands that someone lower than him scrape the floor for him ... I know only the humbleness of a warrior, and that will never permit me to be anyone's master. Carlos Castaneda, Tales of Power --~--~-~--~~~---~--~~ 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.9 has been released
Noah Gift wrote: Alberto, Glad to hear you have an update for ToscaWidgets. I had a Google App Engine related question and suggestion. I talked to Guido at the Google I/O conference and he mentioned that the only thing missing with the default webapp framework included with GAE is form validation. In those cases people could obviously use Django newforms, but I wonder if ToscaWidgets might be a great fit for people who want to use the default set up components included with GAE, and use a library for forms. I think there is a great opportunity for someone to tackle form validation OUTSIDE of a web framework on GAE. Hi Noah, tw.forms uses FormEncode for validation. That would be a better fit IMHO it tackles form validation specifically, TW does more things which might not be needed. Anyway, I'm planning to get TW + tw.forms usable in GAE before 1.0. That should be much easier now since TW no longer has any C based dependencies. If Mako or Genshi and FE can be used on GAE there TW probably can be used too or the fix should be trivial. Cheers, 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 -~--~~~~--~~--~--~---
[ANN] ToscaWidgets 0.9 has been released
Hi all, ToscaWidgets 0.9 has been released a couple of minutes ago. Here's the CHANGELOG: 0.9.1 (Jun, 1 2008): - * made ``inject_resources`` default in middleware since else dynamic js calls wont be included 0.9 (Jun, 1 2008): - * retrieve_css and retrieve_javascript have been deprecated and now return empty lists so resources are not included twice in TG1. * tw.mods.tg now injects resources with resource injector * JSLink and CSSLink now allow to override link to specify external resources. (Closes #7) * Removed hard dependency from PasteScript. * ToscaWidgets no longer has any external dependency with C extensions since dependencies on RuleDispatch and PyProtocols have been dropped * ``display``, ``render``, ``adapt_value`` and ``retrieve_resources`` are no longer generic functions but are still exported so they can be easily extended with PEAK-Rules if neccesary * Removed un-needed dependency from decorator module. An upgrade of tw.forms is recommended too for best results since newest version leverages some improvements made in tw.core:: easy_install -U ToscaWidgets tw.forms Should get you rolling. Special thanks to the sprinters, specially Laureano, Sanjiv and Chris P for their invaluable help in testing this release. Enjoy, 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 -~--~~~~--~~--~--~---
Re: How did you begin your fun with Pylons?
Shannon -jj Behrens wrote: I'm not making any judgments about anyone. However, I did see a great talk yesterday called How Open Source Projects Survive Poisonous People: http://youtube.com/watch?v=ZSFDm3UYkeE It's definitely worth watching ;) Nah, I don't think there has been any bad intentions from any side. Just an unfortunate misunderstanding, we can now all continue to get along ;) Cheers, 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 -~--~~~~--~~--~--~---
Re: How did you begin your fun with Pylons?
On May 22, 6:07 pm, Shannon -jj Behrens [EMAIL PROTECTED] wrote: Ben Bangert and I decided to meet for dinner in Berkeley. I got very lost and ended up in Oakland. I finally got to the restaurant an hour late. Ben had already eaten. We had a good talk about Web development. He told me he wanted to write a new Python Web application framework. I tried to talk him out of it. He didn't listen to me ;) I'm glad he did. The TG2 team is happy too :) I tried to offload some mod_perl appserver bottlenecks onto TurboGears when it first came out ( they were on numeric crunching , not Perl's specialty ). That was a complete nightmare. The specs shifted nonstop, I'm sorry. this is what you get with alpha software which is actively defining itself (which is what TG was when we had the pleasure of reading you) and the developer community was one of the least pleasant groups I've ever had the misfortune of working with ( Kevin excluded ). Perhaps a trip to archives [1] to refresh your memory on the tone of some of your posts can shed a light on the reason you felt treated in this way by TG's dev. community. I usually ignore this kind of crap in public forums but today's there's a nice friday-feeling at the office which invites to procrastinate. Sorry but I can't guarantee it'll remain this way hence me being available for the rest of the piss-fest Yours, Alberto [1] http://groups.google.com/group/turbogears/search?q=author%3Ajvanasco%40gmail.comstart=0scoring=d; --~--~-~--~~~---~--~~ 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: Deployment Question
Jose Galvez wrote: Anyone using mod_wsgi with Apache? how good is that for deployment, better/worse then mod_proxy with paster? I'm using Apache2 + mod_wsgi 2.0 as a process controller and nginx to serve static content and proxy dynamic requests to apache2. Apache2 uses the worker (threaded) MPM and is configured to be pretty lightweight [1] by only loading a minimal set of modules, turning keep-alive off and having a limited amount of threads. This is possible because it runs behind nginx which takes care of spoon-feeding the slow clients over a keep-alive connection making dynamic requests to the Apache backend quite fast since they're local. Since nginx does some caching of the response, these requests are quite fast and don't tie up a heavy python process for too long so a small pool of workers can handle moderately high loads. The reason I use it over paster+supervisord is because I find it *much* easier to set up and maintain and more powerful (mod_wsgi can be configured to spawn wsgi applications into separate processes under their own user/group, restart them if they crash, kill them if they deadlock, isolate them in their own virtualenv, etc...). As you see, It's more or less the typical supervisord + paster + nginx setup but changing paster and supervisord with apache+mod_wsgi because I find the later much easier to configure and maintain. Alberto [1] The master process only eats around 4M resident size on my machine. The slave processes which host the python app take up much more but I guess it's roughly the same they would take using paster or any other python webserver since it is the actual python app. --~--~-~--~~~---~--~~ 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 session in Model unit tests
Pavel Skvazh wrote: I've been searching throught the docs to figure it out but there's no clue. I've got a set up like Using SQLAlchemy with Pylons suggests and my model relies on session, where current user_id is stored. Is there any way to access Pylons session in my model tests? Relying on the HTTP session (if you're not referring to this one please stop reading now :) in the model is very bad coupling IMHO. As a workaround you could try to mock a session with something like: class MyMockSession(dict): def save(*args, **kw): pass etc, ... from pylons import session session._push_object(MyMockSession(user_id=fooo)) You might want to place that in the setUp method and place the followiing in the tearDown this: session._pop_object() 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 -~--~~~~--~~--~--~---
Re: is there a good way to stash a global var, that doesn't use g/app_globals
Jonathan Vanasco wrote:
I need to run an import like such:
model = getattr(__import__(g.APPNAME, {}, {}, ['']), 'model')
the problem is that I get a bunch of errors like this:
TypeError: No object (name: G) has been registered for this thread
because of the import order
can anyone suggest a good way to handle stashing the APPNAME for an
import of this type?
Use g but make sure it is accessed in this way after load_environment is
called.
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
-~--~~~~--~~--~--~---
Re: how can I catch HTTPUnauthorized(401) in my middleware?
Hi, how can I catch HTTPUnauthorized(401) in my middleware and then make a internal request to other controller? just like Authkit, it can redirect abort(401) to 'signinpath' Check out pylons.middleware.StatusCodeRedirect (available since 0.9.7). 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 -~--~~~~--~~--~--~---
Re: localization when part of the code is in different place than pylons project.
Mikael Lepistö wrote:
Hi,
We have a toolkit library that we use in many pylons projects and it
is outside of normal pylons project tree. Now we have problem, that we
cannot get setup tools to extract messages outside of our pylons
source tree to get localization also for toolkit.
our directory structure is basically like this:
pylonsproject/
toolkit/
I tried to make symbolic link to toolkit dir to
pylonsproject/pylonsproject/toolkit
but it didn't work.
Is it possible to read texts for pylons project from different
directory to the same catalog where is pylon project translations? Or
would it be possible to extract messages separately for toolkit and
set pylons to use them in addition to
pylonsproject/pylonsproject/i18n/pylonsproject.po stuff?
We wold not like to do localizations same way that they are done with
validators, by passing strings for message-keys to the functions.
This is how the relevant section of setup.py in a project of mine looks
to extract messages using Babel from FormEncode:
message_extractors = {
'thirdparty/FormEncode/formencode': [
('**.py', 'python', None),
],
'myapp/templates' : ...,
etc...
}
thirdparty/Formencode is a svn-external where I make a checkout of a FE tag.
Although this solution works for me it is suboptimal IMO. Ideally there
would be a way for catalogs from different eggs to be merged together
somehow so that just installing an egg and probably listing it somewhere
would do the job without needing a source checkout. Probably Babel's
competence though.. Any ideas?
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
-~--~~~~--~~--~--~---
Re: Template knowing the path to static files
Matt Haggard wrote:
So what about images in CSS files? I can't use helper functions
there...
Make them relative to the url the CSS file lives in, eg:
.foos { background-image: url(../img/foo-bg.jpeg) }
(assuming this css file is at public/css/style.css and the image at
public/img/foo-bg.jpeg)
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
-~--~~~~--~~--~--~---
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 -~--~~~~--~~--~--~---
Re: separating unit tests and system tests?
Juri Pakaste wrote:
I'm just starting playing with Pylons, and my Python test framework fu
is a bit rusty, so I might be missing something obvious: I'm looking
for a way to have separate unit tests and system tests sets.
I wrote some database independent model code (naturally I'm starting
with CouchDB, not the default of RDBMS + SQLAlchemy every tutorial
talks about...)
playful
Those pesky old-fashioned RDBMS... ;)
/playful
and tests for those. I even got nose to run my tests.
However, running nosetest from setup.py insists on running websetup.py
which sets up my db etc. It's not a big problem yet but for a large
system I'd prefer to have some fast running unit tests that don't
require the environment and have the tests that use db, react to web
requests etc as a separate set that can take a bit longer without
hindering development.
What I do in this case is to use separate config file to run unit-tests
and check for that in websetup.py:
def setup_config(command, filename, section, vars):
Place any commands to setup joborama here
conf = appconfig('config:' + filename)
load_environment(conf.global_conf, conf.local_conf)
# at this point pylons.config is already populated. You could also
# peek in it for test config options...
if 'test' in filename:
# setup environment for tests
elif 'foo' in filename:
# set up environment for fooing
This allows you to have separate configuration for each kind of tests,
for development, production, staging etc.. and setup the environment
accordingly in each case.
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
-~--~~~~--~~--~--~---
Re: separating unit tests and system tests?
Alberto Valverde wrote:
Juri Pakaste wrote:
I'm just starting playing with Pylons, and my Python test framework fu
is a bit rusty, so I might be missing something obvious: I'm looking
for a way to have separate unit tests and system tests sets.
I wrote some database independent model code (naturally I'm starting
with CouchDB, not the default of RDBMS + SQLAlchemy every tutorial
talks about...)
playful
Those pesky old-fashioned RDBMS... ;)
/playful
and tests for those. I even got nose to run my tests.
However, running nosetest from setup.py insists on running websetup.py
which sets up my db etc. It's not a big problem yet but for a large
system I'd prefer to have some fast running unit tests that don't
require the environment and have the tests that use db, react to web
requests etc as a separate set that can take a bit longer without
hindering development.
What I do in this case is to use separate config file to run unit-tests
and check for that in websetup.py:
def setup_config(command, filename, section, vars):
Place any commands to setup joborama here
conf = appconfig('config:' + filename)
load_environment(conf.global_conf, conf.local_conf)
# at this point pylons.config is already populated. You could also
# peek in it for test config options...
if 'test' in filename:
# setup environment for tests
elif 'foo' in filename:
# set up environment for fooing
This allows you to have separate configuration for each kind of tests,
for development, production, staging etc.. and setup the environment
accordingly in each case.
I forgot to add that you'd also need to change app/tests/__init__.py so
the config file 'test.ini' is not hardcoded but retrieved from
os.environ or something so you can choose the testing config dynamically.
Perhaps Pylons could be improved to cater for this need out-of-the-box
by loading the app for testing from the nose plugin (which allows the
config file to be passed from the commmand line or setup.cfg) instead of
hardcoding it in app/tests/__init__.py . I could provide a patch for
this sometime if the committers would like it :)
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
-~--~~~~--~~--~--~---
Re: UNS: Re: cleaner ToscaWidgets
Matt Feifarek wrote: On Oct 24, 2007 5:06 PM, Alberto Valverde [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Yep, was planning to do that when I cover tweaking the layout. Finally didn't have time to start part 2 today but will tomorrow... Hey Alberto -- did a part 2 ever fall out of your brain? No, not yet. I've wish I could spare an afternoon sometime soon to do it but I doubt it because I'm pretty busy at the moment. Sorry. We're eager to learn more about TW, and are having some troubles getting beyond the simple examples to our own custom fields and templates. Your best bet at the moment is to search the archives of toscawidgets-dicuss google group and/or study the templates of twForms' fields and forms. 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 -~--~~~~--~~--~--~---
Re: Classic URL Style
Humberto Diógenes wrote:
Hi!
I'm trying to port an existing mod_python app to Pylons, but had
some trouble with Routes. I'd like to keep using URLs the same
classic URL style:
http://localhost/location/edit?location_id=123
And then have Pylons receive it as arguments for the controller
method:
code
class LocationController(BaseController):
def edit(self, location_id):
return 'Editing %s' % location_id
/code
But I'm getting this exception:
TypeError: edit() takes exactly 2 arguments (1 given)
Do you have any directions on what do I need to do to make it work?
Yes, pull location_id from the request GET parameters:
employment_id = request.GET.get('employment_id')
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
-~--~~~~--~~--~--~---
Re: Path to read a data file shipped within an egg?
Chris Shenton wrote:
I've got an app that needs to read and parse a data file (a RADIUS
dictionary, not a Python dictionary but a flat file). I want to
include this file in my egg so I don't have to depend on the OS having
RADIUS installed.
In the application's top-level setup.py, I add my data/ subdir to the
package_data list:
package_data={'bianca': ['i18n/*/LC_MESSAGES/*.mo', 'data/*']},
and see that the files in data/ get added to my egg. Good so far.
What path do I use to reference that file for reading? Again, I am
trying to avoid hard-coded absolute filesystem paths. But trying paths
like:
freeradius_dictionary
/data/freeradius_dictionary
/bianca/data/freeradius_dictionary
/bianca/freeradius_dictionary
didn't work for me: file not found.
What's the pattern for paths to files that live inside eggs, rather than
on the larger filesystem? Is there some PATH I need to specify to the
app or Pylons? Something else?
from pkg_resources import resource_filename
path = resource_filename('bianca', 'data/freeradius_dictionary')
If data would have been a python package, which I suppose it's not, then:
path = resource_filename('bianca.data', 'freeradius_dictionary')
HTH,
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
-~--~~~~--~~--~--~---
Re: ~Solved~: Reducing pylons app memory usage?
Thanks for the summary Martin! I've copied it to Pylons' wiki [1] so it's easier to find for reference in the future. Alberto [1] http://wiki.pylonshq.com/x/M4Kq --~--~-~--~~~---~--~~ 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: Status codes for user errors
Mike Orr wrote: Sometimes my controllers discover a user error: a URL pointing to a nonexistent database record, or query/form input that doesn't match what the form HTML would have allowed. The Pylons error system isn't quite what I want; I'd rather send back a regular page with the site decorations and a message saying That record doesn't exist, try searching or You don't seem like a real human. -- with a 400-series status. Because just aborting with 500 makes it look like the site is buggy, and a text error message doesn't have the links to get them back on track. I could adjust the error template style but it seems like overkill when I can just do it in the controller. Is there any problem with just changing the status in the controller and returning an alternate template page? There shouldn't be, just do: response.status_code = 500 Inside the controller method so the correct headers are set (I haven't found a way to alter the message though, you might have to drop to bare WSGI to do that) and then render the template you see fit. 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 -~--~~~~--~~--~--~---
Re: Any Pylons freelancers in Europe here?
Alberto Valverde wrote: voltron wrote: Hi all, if you are ready to tale on a Pylons based freelancing project, please let me know. I have something that needs to finished ASAP. Hi Voltron, I'm living in Dublin and available for Pylons contract work. Email me if interested with some more details about the project. Ooops, Now everybody knows :) 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 -~--~~~~--~~--~--~---
Re: Using twForms with Pylons. Part 1
Ben Bangert wrote:
On Oct 30, 2007, at 6:38 AM, Alberto Valverde wrote:
I do believe that this is because FE's UnicodeString.from_python returns
a str instead of unicode. I'm not too sure of the rationale behind this
but, given that most template languages now expect unicode to be used
internally (only encoding when finally rendered), I think FE's
from_python should also return unicode. This came up some time ago in
FE's list, if you google for toscawidgets and unicodestring in it's
archives I'm sure the thread will pop up.
Might be my fault, I think I put the first version of the Unicode
validator in FE, based on the TG one.
If he objects to python functions in templates like webhelpers' then I
don't think he'd like twForms at all either since fields are rendered
this way: ${display_child('name')}.
In this scenario twForms might not be a good solution. twForms is a
higher-level layer on top of plain html. As with all abstractions, some
flexibility is lost in exchange for simplicity.
I thought widgets could have their templates overridden? Wasn't that one
of the main uses for the Widget browser? Ie, to browse available
widgets, their options, and see the templates they come with so you can
customize them if needed.
Yes, they can be customized but in the case of compound widgets (ie:
widgets which display other widgets, like forms) how the rendered
children look like is not immediately obvious by seeing the template.
For example a template could look like this:
form action=$action ...
p${display_child('name')}br / {error_for('name'}}/p
p${display_child('age')}br //p
p${display_child('address')}/p
/form
In this example address is a fieldset with its address fields but you
cannot see it there.
Another problem is that the way html attributes for a field are modified
is not obvious to a designer well versed in html either:
${display_child('name', size=23, maxlength=100)
Keep in mind that tg widgets (twForms' grandma) were originally created
to be used by fastdata which tries to be, or will try to be (really hope
that someday it becomes!) an alternative to django's admin interface.
So, twForms is more geared towards programatically generating forms
(introspecting models, etc...) to quickly generate an interface for lots
of classes than to creating to-the-pixel forms where design is crucal
(ie: a signup form). Mike has articulated this point much better than I
did previously in this thread.
Not only programatically... for dull forms, I find more pleasant to edit
and maintain a form definition twForms' style than by editing html.
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
-~--~~~~--~~--~--~---
Re: Sites within sites
Mike Orr wrote: I have two sites I want to convert to Pylons. Each site is just a collection of independent components which could conceivably be separate WSGI applications. But the sites handle authentication, logging, and sessions for the components. (...) Paste can mount multiple applications at different subdirectories. But I need authentication at the top level, so that doesn't seem feasible. I've managed to share authentication between different WSGI apps by stacking authkit above (closest to server) an URLMap which dispatches to them. Regarding sessions, never done it but I suppose the same concept could apply: stack beaker, just once, above all the other apps. However, I'm not sure who easy Pylons makes this since last time I looked it seemed beaker is hardcoded inside PylonsApp. If Pylons provided (if it doesn't already) a way to make this more granular it should be possible. 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 -~--~~~~--~~--~--~---
Re: Using twForms with Pylons. Part 1
John_Nowlan wrote:
I've patched up my windows box and am trying the tutorial but run into
the same problem as mentioned in the previous msg, i.e.
I reach this stage in the tutorial:
http://wiki.pylonshq.com/display/toscawidgets/Using+twForms+with+Pylons.
+Part+1#try-it-out
and I can't make validation fail, no matter what I do I get a respons
of:
'You must POST to this method, dummy!'
This is strange... by looking at the rendered HTML, is the action
/tutorial/save and the method POST? Are you sure you decorated the
save method with validate()? Are you sure that you're importing the
validate() decorator from toscawidgets?
At the top for your controller module you should have:
from toscawidgets.mods.pylonshf import validate *after* from
twtutorial.lib.base import * (actually, I'm pretty sure now that this is
the problem...)
Is it trying to tell me something? :\
I don't think so :)
Could complete files for the tutorial be posted so I can compare and see
where I'm being a dummy?
Good idea, after all... I did write the tutorial myself before writing
it :) I've attached it at the howto in Pylons' wiki (too fast I believe
since I was planning to move the JS stuff to part2... anyway)
Or put the complete source in the code 'windows' each time.
I'll take note of this
=
Here are a few other misc. notes:
- I upgraded python to 2.5 and had to copy a few 2.4 dependencies over:
./ruledispatch-0.5a0.dev_r2247-py2.4-win32.egg
./pyprotocols-1.0a0dev_r2082-py2.4-win32.egg
Hmm, these shouldn't be neded in 2.5. They're compiled eggs (the win32
at the path) for 2.4 and I don't think they would even link properly in 2.5.
I think this has been mentioned already but myghty is still a
dependency,
when I didn't have it installed, I got:
Starting subprocess with file monitor
14:14:35,075 WARNI [toscawidgets.view] Failed to load 'pylonsmyghty'
template engine: Myghty=1.1
Installing myghty removed that msg.
This is a warning, ignore it for now. I need to make some changes to
make it go away (I explain in another recent thread the reason for this)
- the line post_form = PostForm(post_form) is missing from the 2nd
code window of widgets.py
- in FireFox the line
${post_form(action=h.url_for(controller='tutorial', action='save'))}
below
http://wiki.pylonshq.com/display/toscawidgets/Using+twForms+with+Pylons.
+Part+1#edit-the-template
BTW, I think we should now move this conversation to the comments in
Pylons wiki so others can benefit from it in the future.
Thanks for the feedback!
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
-~--~~~~--~~--~--~---
Re: Using twForms with Pylons. Part 1
John_Nowlan wrote: Thanks for the help Alberto. For the meantime, I've built those troublesome eggs without the C speedups and uploaded them at toscawidgets.org. Can you try installing RuleDispatch before installing twForms/ToscaWidgets like this: easy_install -f _http://toscawidgets.org/download/wo_speedups_ RuleDispatch If it works please report back so I can mention it in the tutorial :) works! Great! Note: easy_install twforms reports its installed, so did not reinstall. On with the tutorial paster serve... gives these deprecation warnings: (...) Should not be a problem for now, if I understand correctly. Not a problem, just me lazy :) I should update TW to DecoratorTools' new API... err, well, I'm actually planing to drop that dependecy so that will surely solve it. Nevermind those warnings for now. So I continue on. At _http://wiki.pylonshq.com/display/toscawidgets/Using+twForms+with+Pylons.+Part+1#id13_ I get this error: File '../lib/python2.5/site-packages/Myghty-1.1-py2.5.egg/myghty/importer.py', line 54 in import_module return builtin_importer(name, globals, locals, fromlist) File '../pylons/TWTutorial/twtutorial/controllers/tutorial.py', line 7 in module class TutorialController(BaseController): File '../pylons/TWTutorial/twtutorial/controllers/tutorial.py', line 16 in TutorialController @validate(form=post_form, error_handler=index) NameError: name 'post_form' is not defined Not sure if this line: @validate(form=post_form, error_handler=index) should have post_form in quotes, or if tutorial.py should have the line from: twtutorial.widgets import post_form You should import post_form from twturial.widgets. Maybe I should reword that part so it is clearer... either works but then whenever I try and save I always get the 'You must POST to this method, dummy!' msg. Hmmm, you did decorate the save method, didn't you? :( Note that I'm running this behind a proxy, using 'proxy-prefix' in development.ini. That shouldn't make a difference. I've deployed apps using TW and ProxyPrefix with no problems. Can't do it on my windows box until I get the sslerror problem figured out. I'm pretty sure that has something to do with Paste's http server. You could try narrowing down the problem by trying it with cherrypy's server, in development.ini change your server config so it looks like: [server:main] use = egg:PasteScript#cherrypy port = 5000 ... If this works then you know it has something to do with Paste's server and your system. Though it's weird since I'm pretty sure many people here must be using it in windows... 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 -~--~~~~--~~--~--~---
Re: cleaner ToscaWidgets
Mike Orr wrote: On 10/23/07, Max Ischenko [EMAIL PROTECTED] wrote: On 10/24/07, Mike Orr [EMAIL PROTECTED] wrote: I've written a summary page introducing Pylons form handling and ToscaWidgets, with links to the existing ToscaWidgets tutorials. Alberto's new tutorial is first, which will hopefully cut down on user confusion until the others are updated, combined, or deleted. http://wiki.pylonshq.com/display/pylonscookbook/Forms I 've tried to checkout Kevin's PDF and it appears that Confluence requires user to login to download the file. Is that why it didn't show up in the search when I tried to make a link to it? I had to use an external URL. Well, maybe Ben knows something about this. Hmmm, seems the same reason why the new page I created with the howto isn't linked properly in the Forms page when I log out of the Wiki. I believe it is because the whole ToscaWidgets space isn't accesible without authentication (both the howto and Kevin's PDF are inside it). I've looked for a way to change this but think I haven't got the necessary rights to do it. Could someone who can promote it take a look at it when they have a chance? Thanks! Alberto P.S. I'm no longer going to update the version at my blog but make a link to Pylons' wiki for the latest version as soon as it can be read by anyone. --~--~-~--~~~---~--~~ 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: UNS: Re: cleaner ToscaWidgets
John_Nowlan wrote: Thanks for this. I fall into the target audience (hand coder?, hmm.. sounds incriminating..) Appreciate the not diving in, but giving context first. Feedback, fwiw, after just reading, haven't had a chance to try yet (minor niggles or typos). - in a tutorial wouldn't the long form of commands be more explanatory? i.e. instead of paster create -t Pylons TWTutorial use paster create --template=TEMPLATE Pylons TWTutorial - 'the kind of form CSS fan-boys usually love' - remove this. I'am all for humor, but this just seems a little jarring. - 'I hope the above hints one' - missing 'at' - 'I hope the above hints at one'... - could you add a bit relating the html to the code here? Not being an expert, I'm curious to know if things such as 'class=even' come from the ListForm class and/or whether this is fixed html output and/or expecting a related css. At the end of the tutorial you mention in the coming next: 'How to tweak the form's template to precisely control its layout.' So maybe just say that here, i.e. add a paragraph above 'Using the form in your application' that says: The layout of the form can be customized. 'How to tweak..' will be the subject of a following tutorial. - 'This is due a limitation' - missing 'to' - 'This is due to a limitation' - I condider - I consider Other than that, this is a great help. Thanks again! Thanks for the feedback! I've removed the typos, grammar errors (thanks for that!) and my ill sense of humor ;). I'll update the blog post soon, along with part 2 which will be an extended fancy widgets part since it has been pointed out to me that it doesn't belong in an introductory part 1. However, will soon stop doing it since I'll be posting updates from now on at Pylons wiki. Sending a link to its new home as soon as an admin makes the toscawidgets space public... 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 -~--~~~~--~~--~--~---
Re: cleaner ToscaWidgets
Ben Bangert wrote: On Oct 24, 2007, at 10:24 AM, Alberto Valverde wrote: P.S. I'm no longer going to update the version at my blog but make a link to Pylons' wiki for the latest version as soon as it can be read by anyone. It appears we made a full ToscaWidgets space, which is prolly better than merely having it in the Pylons Cookbook (it does deserve its own space, no?). I've fixed the permissions so that everyone can view it, users can add to it, and Alberto has admin privs on it. This is where the attachment was located which was why ppl that weren't logged in were unable to d/l it and view that section. Thanks Ben! So here's the definitive location where I'll be uploading TW's howtos: http://wiki.pylonshq.com/x/AwAx 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 -~--~~~~--~~--~--~---
Re: UNS: Re: cleaner ToscaWidgets
Mike Orr wrote: On 10/24/07, John_Nowlan [EMAIL PROTECTED] wrote: - could you add a bit relating the html to the code here? Not being an expert, I'm curious to know if things such as 'class=even' come from the ListForm class and/or whether this is fixed html output and/or expecting a related css. At the end of the tutorial you mention in the coming next: 'How to tweak the form's template to precisely control its layout.' So maybe just say that here, i.e. add a paragraph above 'Using the form in your application' that says: The layout of the form can be customized. 'How to tweak..' will be the subject of a following tutorial. That's an important point that those of us familiar with CSS customizing can easily overlook. Taking a *very* quick look at the article, you might do something like this. (This itself may look ugly but it illustrates the point.) (...) Alberto, can we get a short stylesheet example in the tutorial? Yep, was planning to do that when I cover tweaking the layout. Finally didn't have time to start part 2 today but will tomorrow... 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 -~--~~~~--~~--~--~---
Re: UNS: Re: cleaner ToscaWidgets and descending into pylons version of dll hell
John_Nowlan wrote: Now trying to do the tutorial: (note: I had to update to python25 from 24 on windows because in trying to do the tutorial I was getting an error about a missing python25.dll after updating dependent packages (PasteDeploy-1.3.1, Beaker-0.8, Webhelpers-0.3.2, Routes-1.7). Updating to 25 without changing path fixed that problem.) Hmmm, I'm not sure what might be causing this but at this point it doesn't look TW related. Can't help you much here really since I have no experience with pylons on windows. paster create -t Pylons TWTutorial - should be -paster create -t pylons TWTutorial - lowercase pylons not Pylons - otherwise you get 'LookupError: Template by name 'Pylons' not found' Noticed and fixed that... - make the first few code changes, get to the first paster serve..: ( long traceback ) ImportError: cannot import name sslerror stuck :( Hmmm, looks something related to Paste's httpserver. AFAIK, it's the only place where ssl related stuff is imported in Pylons' dependencies. So I try on a development unix box. (Fits in with the split personality...) Have to update setuptools... and ... $ easy_install twForms (.) ld: fatal: library -lpython2.5: not found ld: fatal: File processing errors. No output written to build/lib.solaris-2.9-sun4u-2.5/dispatch/_d_speedups.so error: Setup script exited with error: command '/import/bin/cc' failed with exit status 1 I have no experience with Solaris but it seems the linker can't locate python's shared library. Setting some environment variable should do the trick... You will also need python's header files somewhere the compiler can find them too. So I'm stuck and maybe should be starting a new thread about what seems to me to be a pylons version of dll hell. But its probably my own inexperience. Don't blame Pylons, it's TW's fault here... TW depends on a third-party library (RuleDispatch) which is not pure python (ie: has C coded modules for performance). You're not the first person being bitten by that :( I plan to fix this some time soon by dropping that dependency altogether... For the meantime, I've built those troublesome eggs without the C speedups and uploaded them at toscawidgets.org. Can you try installing RuleDispatch before installing twForms/ToscaWidgets like this: easy_install -f http://toscawidgets.org/download/wo_speedups RuleDispatch (all in the same line) If it works please report back so I can mention it in the tutorial :) I've just been doing easy_install -U pylons to get to 0.9.6.1 and updating packages as nescessary. Perhaps its better to delete everything and do a 'clean' easy_install pylons to try and make sure all packages are at the required levels? Does anyone have words of wisdom about installing pylons, python packages? I.e. does it make sense to clean out old versions or what are 'best practices'? I'd recommend using virtualenv or workingenv to create a sandbox to install libraries. When it breaks badly I just wipe the sandbox away and start over again (crude but works :) Note that you will not want to do this in a production environment unless you have backups of all eggs with the versions you know that work since it's sometimes hard to find the exact outdated version of a library. Although looking at this again the unix problem is prolly a env problem, i.e. need to solve -lpython2.5: not found The easy_install workaround I gave a few lines back should get you going... however, this is going to bite you again whenever you try to install a library that has C speedups and no pre-compiled library for your platform so I'd recommend taking the time to fix it some time. 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 -~--~~~~--~~--~--~---
Re: cleaner ToscaWidgets
Mike Orr wrote: On 10/22/07, Max Ischenko [EMAIL PROTECTED] wrote: Thanks a lot for your reply; it's very helpful. It looks like I should put aside a few hours and re-evaluate TW to have an up-to-date opinion. Hopefully Mike Orr could write some Pylons HOWTO by then. ;) I printed out the four existing Cookbook articles but haven't read through them yet. One problem is that some of them and the official ToscaWidgets doc are for Pylons 0.9.4, which is now long obsolete. Since I started with 0.9.5, I'll have to infer what 0.9.4 was like and then figure out what the equivalent is in 0.9.6. The Alternative ToscaWidgets with Mako article is fairly recent so it may be a good starting point. The Alternative... one has just been obsoleted (for the good) by 0.1a2dev_r3534 which makes configuring it in Pylons much easier. I'm waiting for my forgotten wiki password (which confluence is refusing to email me) to update it. For the meantime this is the part in Pylons' sample app where it achieves the same effect: http://tinyurl.com/2ts8zs 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 -~--~~~~--~~--~--~---
Re: UNS: Re: cleaner ToscaWidgets
Mike Orr wrote: On 10/22/07, Max Ischenko [EMAIL PROTECTED] wrote: On 10/23/07, Mike Orr [EMAIL PROTECTED] wrote: Glad to hear this. :) So maybe I should reduce the initial scope of the docs I have in mind and not dive directly into custom widgets but concentrate on how existing widgets are used? Yes. Think in terms of somebody who has used another Python form library or has handcoded all their forms, and just wants to use the standard widgets at first. They'll be curious about any special widgets TW provides such as a date picker, WSIWYG editor, combo box, enhanced file uploader, etc -- things they've had to struggle with or do without in their other libraries. They don't want to build custom widgets yet; they just want to build forms that work. I'd say that even tutorial for a simple form (2-5 fields, nothing fancy) would work if it highlights how TW is different from other approaches, like handcoding, and what it can give you. Good point. Level 1: what Max said. Level 2: TW's megawidgets. Level 3: making your own widgets. Level 4: making your own composite widgets (if that is different). Ok, sounds good... I'll post in this thread a draft level 12 [1] tutorial later today. Alberto [1] Since using megawidgets, which I suppose refers to the WYSIWYG editor et al, is no different from a user's POV than using a simple text field. --~--~-~--~~~---~--~~ 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: Scheduling and monitoring
voltron wrote: I read a lot about people using Cron to schedule the clearing out of dead sessions in Pylons apps, is there any reason why one cannot use the sched(http://docs.python.org/lib/module-sched.html) module to do the same and start if from pylons itself? Pylons has some kind of monitoring system, are there hooks or events that one could use to execute a few Pylons related tasks? I've ported Turbogears' scheduler for use in a project using Pylons, I've uploaded it here: http://toscat.net/~alberto/scheduler.py Sorry, no docs. You'll have to look at the source and at TG's docs but it's pretty easy to grok. HTH, 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 -~--~~~~--~~--~--~---
Re: UNS: Re: cleaner ToscaWidgets
Alberto Valverde wrote: Mike Orr wrote: On 10/22/07, Max Ischenko [EMAIL PROTECTED] wrote: On 10/23/07, Mike Orr [EMAIL PROTECTED] wrote: Glad to hear this. :) So maybe I should reduce the initial scope of the docs I have in mind and not dive directly into custom widgets but concentrate on how existing widgets are used? Yes. Think in terms of somebody who has used another Python form library or has handcoded all their forms, and just wants to use the standard widgets at first. They'll be curious about any special widgets TW provides such as a date picker, WSIWYG editor, combo box, enhanced file uploader, etc -- things they've had to struggle with or do without in their other libraries. They don't want to build custom widgets yet; they just want to build forms that work. I'd say that even tutorial for a simple form (2-5 fields, nothing fancy) would work if it highlights how TW is different from other approaches, like handcoding, and what it can give you. Good point. Level 1: what Max said. Level 2: TW's megawidgets. Level 3: making your own widgets. Level 4: making your own composite widgets (if that is different). Ok, sounds good... I'll post in this thread a draft level 12 [1] tutorial later today. Until I can log on to the wiki I've posted the tutorial at my blog: http://albertovalverde.es/twforms_tutorial1.html Feedback welcomed! :) 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 -~--~~~~--~~--~--~---
Re: Pylons without Myghty
Mike Orr wrote: On 10/21/07, Stou Sandalski [EMAIL PROTECTED] wrote: I am running 0.9.6, after some tinkering I found out it was ToscaWidgets that was causing the dependency, sorry. Is there something out there a bit 'newer' or 'cleaner' than tw that someone can recommend? At least something that doesn't depend on all those packages from PEAK that are 3 years old (PyProtocols, etc.) Out of curiosity, is there any inherent problems in packages 3 years old? The non-ToscaWidgets way is plain ol' FormEncode but then you're going lower level. ToscaWidgets has been positioning itself as the high-end solution; I don't know of any other that works with Pylons. So the real question is, when will ToscaWidgets modernize its dependencies? Yeah, I've been planning to drop the ruledispatch dependency long ago since it has caused more problems than it has solved (specially due to its C speedups). I've just comitted a TODO file [1] as a kind of roadmap for things I'd like to get done before releasing a final stable 1.0. Looking at TW's setup.py, the only ancient dependency is RuleDispatch. http://svn.turbogears.org/projects/ToscaWidgets/trunk/setup.py I recall a discussion about wanting to improve RuleDispatch and spin it off, but apparently this has not been done yet and there are insufficient volunteers for it. I'm stunned that ToscaWidgets would depend on Myghty by default, especially since it's spun off from TurboGears which prefers Genshi/Kid. Maybe they did this as a courtesy to Pylons 0.9.4 and they could change it fairly easily? TW doesn't depend on Mighty. However, I've nailed the problem and worked around it in newest trunk: Apparently Pylons declares a python.templating.engines entry point, pylonsmighty, which TW tries to load when initialized [2]. This will cause a DistributionError if Myghty is not installed. Though looking at setup.py, I don't see how Mako is strictly required unless you invoke the Mako extra. Though I'm not sure how you'd install an extra with easy_install anyway. Alberto [1] http://trac.turbogears.org/browser/projects/ToscaWidgets/trunk/TODO.txt [2] Actually, it tries to load all entrypoints by default on init time. This should be fixed so they're loaded JIT to prevent this kind of errors. --~--~-~--~~~---~--~~ 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: cleaner ToscaWidgets
Max Ischenko wrote: Hello Mike, On 10/22/07, *Mike Orr* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: So, to toscawidget or not to toscawidget? I'm about to write some forms soon. I was going to learn TW because I assumed it would be better in the long term when I add more Javascript features, and better to start with it now than to rewrite my forms in it later. Is TW really that bad? I don't care about a few extra dependencies as long as I know who's using them. I'm obviously biased in regards to this so I hope a happy user chimes in instead of giving my opinion. :) You 've got to use it for a while to make a judgement. It was a fine idea and I don't want to spread FUD. My problems with TW were: - rough (random bugs) I'd really appreciate some tickets at TG's trac to nail them. - hard to use (basically no docs) Fair enough. This is something I would really have liked to solve long ago but seems like some sort of mental blockade of mine. I've tried my best to personally give support in TW's mailing list to anyone needing help (secretly hoping users would fill the docs gap :) but experience has shown it's no substitute for real documentation. I hope to have time to change this soon. - too complicated an implementation. Ironically enough one of the reasons I spun TW out of TG's widgets was to simplify the implementation. I suspect the use of RuleDispatch greatly contributes to this perception, this is something I plan to change too. [1] - development stalled ?? [2] Regards, Alberto [1] http://tinyurl.com/263mfy [2] http://tinyurl.com/ysk68z --~--~-~--~~~---~--~~ 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: cleaner ToscaWidgets
Mike Orr wrote: On 10/22/07, Alberto Valverde [EMAIL PROTECTED] wrote: - hard to use (basically no docs) Fair enough. This is something I would really have liked to solve long ago but seems like some sort of mental blockade of mine. I've tried my best to personally give support in TW's mailing list to anyone needing help (secretly hoping users would fill the docs gap :) but experience has shown it's no substitute for real documentation. I hope to have time to change this soon. The lack of documentation has been the main reason I haven't stepped into the the ToscaWidgets learning curve yet. If you know me, you know that documentation is my forte, so I'll be writing at least a Pylons-ToscaWidgets howto and a FormEncode-ToscaWidgets comparision once I know enough to do it. Your SQLAlchemy 0.4 tutorial made me brave enough to make the jump from 0.3 :) I'd really appreciate any effort in the docs area. Thanks! Alberto, is the ToscaWidgets trunk kept reasonably stable? Meaning, Cheetah has a rule that all changes have to pass the unittests before being checked in, and backward compatibility is generally maintained, so that the trunk is almost always more usable and less buggy than the last release. Pylons, SQLAlchemy, and Supervisor seem to have a similar attitude because I've had good luck with their trunks. Does ToscaWidgets keep a clean trunk too? I try my best to keep it that way. Unit tests always pass before anything is committed and there haven't been any major API changes since I first released it. Keep in mind TW didn't start from scratch but evolved from TG's widgets. trying to mimic their API as much as possible (except some small improvements and new functionallity, namely being able to mix and match templating engines). What I'm trying to say with this is that most API experiments already took place before TW was born. Is it safe enough for application development, knowing that we may have to change our API calls occasionally? Yes. TW hasn't even got a stable release yet so the trunk is as stable as it can be. All eggs that have been packaged are really snapshots of the trunk and experiments take place in separate branches before being merged and announced in the mailing list. Today I merged a breaking change which aims to reduce all the boiler plate needed to configure TW in Pylons as described by James' An Alternative ToscaWidgets Setup with Mako [1] (which, BTW, I should update, as soon as confluence mails me my lost passwd, to reflect the changes...). However, this change will not affect existing widgets, only the way TW's middleware is initialized. Are there any anticipated changes which will change the API? I expect a little breakage in the public API to take place before 1.0 is out since I want to remove the RuleDispatch dependency. However, I don't think it will affect many users (if any at all) since it uses an obscure feature (adapt_value()) involving generic functions which I haven't seen in the wild. I might also rename the package name to tw and move the widget packages inside the tw namespace (ie: tw.forms, tw.mochikit, etc...) to avoid the redundant from toscawidgets.widgets import foo. This should be easily aliased and DeprecationWarned though... Alberto [1] http://wiki.pylonshq.com/x/B4A1 --~--~-~--~~~---~--~~ 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: UNS: Re: cleaner ToscaWidgets
Philip Cooper wrote: Alberto Valverde at about 10/22/07 2:07 PM said: Max Ischenko wrote: Hello Mike, On 10/22/07, *Mike Orr* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: So, to toscawidget or not to toscawidget? I'm about to write some forms soon. I'm obviously biased in regards to this so I hope a happy user chimes in instead of giving my opinion. :) Wrks 4 me. Turbogears is not great on documentation of widgets but it's a not better than starting from scratch. Things like date picker and tinyMCE are not things I really want to recreate. I've started http://www.openvest.com/trac/wiki/ToscawidgetsInPylons for my own edification. More to come later. - hard to use (basically no docs) Pretty easy to use. Everytime someone writes a doc, it seems they are already super-users so they jump right into creating a custom widget. Too advanced if you don't know what magic is behind a basic widget. Understanding how DataGrid works makes the whole tw world make sense IMHO. Glad to hear this. :) So maybe I should reduce the initial scope of the docs I have in mind and not dive directly into custom widgets but concentrate on how existing widgets are used? 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 -~--~~~~--~~--~--~---
Re: ToscaWidgets Tabber
Philip Cooper wrote:
I've started using some Toscawidgets and everything looks fine so far.
OT: I've used them in TG and think that pylons should have some form
of the widgetbroser.
I have a prototype lying around somewhere which haven't released. This
is something in my TODO list...
I even easy_installed twTinyMCE and it ran fine (haven't found docs or
examples on attributes or options thought).
Has anyone used twTabber? It looks like an MIA widget.
MIA?
I found the
project on the turbogears trac but was wondering if there is a reason
it's not released like twForms twTinyMCE twMochikit et. al.
No good reason really... I just haven't taken the time to do it.
On a related issue, I use Mochikit for some asnyc stuff. Mochikit is
built on Prototype and ${h.javascript_include_tag(builtins=True)} brings
in both prototype and scritaculous. Anyone have practical experience on
how to limit all the reduddant js that starts flying around?
TW takes care of making sure js is not duplicated as long as all js is
wrapped in JSLinks. If you manually include script tags it can't
detect it yet. An experimental way I'm trying out using lxml to inject
script and style tags (as described in Ian's blog) could easily
check for dupes. However, it's not implemented yet.
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
-~--~~~~--~~--~--~---
Re: i18n, FormEncode, Genshi
On Aug 28, 2007, at 5:32 AM, Max Ischenko wrote: Hi Alberto, On 8/27/07, Alberto Valverde [EMAIL PROTECTED] wrote: You'll then have to add FormEncode's messages to your app's message catalog, compile it, etc... and that should do it. BTW, I'd love to hear of a way to configure Pylons's _ function to use the message catalog inside FormEncode's egg instead of copying it inside my app's catalog, is there any? I submitted a patch that does roughly this, see http://pylonshq.com/project/pylonshq/ticket/296 Yeah, this is more or less what I was talking about. However, my thoughts were more on the direction of the domain kw. that TG's gettext had (and that formencode is built around) which lets you choose which egg's catalog to use for translations. OTOH, Ben's suggestion of an utility that consolidated all the messge catalogs used by the application into one sounds like the best idea to me since it gives you full control of the final catalog (eg: to override ceratin strings) and would scale better when using various eggs each with their own catalog (although none implemented yet, widget packages come to mind...) I haven't used Babel yet so I don't feel I'm in the best position to open a feature request for this at their tracker just now... perhaps someone that also thinks it's a good idea can do it? :) Albert --~--~-~--~~~---~--~~ 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: i18n, FormEncode, Genshi
On Aug 27, 2007, at 10:44 PM, Daniel Haus wrote:
Now there's still this Genshi translation-filter issue. The Pylons
i18n tutorial does cover message extraction from Genshi, but there are
no hints on configuration of that filter, which i think would be
necessary. Is this a common problem, or am I missing something
obvious?
Take a look at http://genshi.edgewall.org/wiki/Documentation/
i18n.html#translation and the source of genshi's Buffet plugin.
Apparently (haven't tried, so tell us how it goes...:) you should be
able to do something like:
from genshi.filters import Translator
from pylons.i18n import _
def template_loaded(template):
template.filters.insert(0, Translator(_))
Then you would need to pass this callback when initializing genshi's
buffet plugin:
inside middleware.py (or load_environment):
options = {genshi.loader_callback: template_loaded}
# options.update(options_from_config_file)
config.add_template_engine(genshi, yourapp.templates, options)
HTH,
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
-~--~~~~--~~--~--~---
Re: i18n, FormEncode, Genshi
On Aug 27, 2007, at 3:14 PM, Daniel Haus wrote: Hi! Being fairly new to Pylons, I'm working on an Pylons-based (0.9.6rc3) website that utilizes Genshi, Babel, ToscaWidgets and FormEncode. So far everything is working fine except for the translations. I was able to extract and compile language catalogs as described in http://wiki.pylonshq.com/display/pylonsdocs/Internationalization+and +Localization . Problem #1: FormEncode's error messages are not translated at all. What are the required steps? You can use the new state argument to pylons' validate decorator (in trunk only since r2347) and set its _ attribute: from pylons.i18n import _ from pylons.decorators import validate class State: _ = _ class AController(BaseController): @validate(state=State(), ...) def my_meth(self): ... If you're using ToscaWidgets, its validate decorator (in toscawidgets.mods.pylonshf) accepts a state_factory argument with similar semantics to Pylons' state but accepts a callable instead that returns the state: from toscawidgets.mods.pylonshf import validate class AController(BaseController): @validate(state_factory= lambda: State(), ...) def my_meth(self) ... You'll then have to add FormEncode's messages to your app's message catalog, compile it, etc... and that should do it. BTW, I'd love to hear of a way to configure Pylons's _ function to use the message catalog inside FormEncode's egg instead of copying it inside my app's catalog, is there any? HTH, 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 -~--~~~~--~~--~--~---
Re: Javascript in Pylons for ToscaWidgets with Mako
On Aug 15, 2007, at 8:11 AM, emery_c wrote:
I have been trying to get the CalendarDatePicker to work in pylons as
well, using http://wiki.pylonshq.com/display/pylonscookbook/An
+Alternative+ToscaWidgets+Setup+with+Mako.
Are you sure you're using the render_response function provided in
toscawidgets.mods.pylonshf and passing all widgets to the template in
the c.w attribute?
I believe I am. Both those steps are covered in the how-to I
referenced above. It seems the necessary js files are being included,
but the onclick function isn't being added to the button - apparently
I missed a step someplace.
The output html looks like this:
div
input id=form_date class=required calendardatetimepicker
type=text value=2007/08/10 20:48 name=date/
input id=form_date_trigger class=date_field_button type=button
value=Choose/
/div
The relevant controller code is:
def index(self):
c.title = Add User Form
c.w = WidgetBunch()
c.w.form = form
c.value = Person() # Testing class from example above
c.action = h.url_for(action='save')
return render_response('widget') # Mako
I am using the AddUserForm from samples.py and the following code in
widget template:
% if c.input_values:
h1Validated data:/h1
dl
% for k,v in c.input_values.iteritems():
dt${k}/dt
ddpre${repr(v)}/pre/dd
% endfor
/dl
% elif c.w and c.w.form and c.action:
${c.w.form.display(c.value, action=c.action)}
% endif
Any assistance would be appreciated.
A line like this should be rendered at the bottom of body:
Calendar.setup({ifFormat: %Y/%m/%d %H:%M, button:
form_date_trigger, showsTime: true, inputField: form_date});
If it is missing, maybe you forgot to add something like this in
templates/base.tmpl?:
html
head
% for rsrc in c.resources.get('head', []):
${rsrc.display()}
% endfor
/head
body
% for rsrc in c.resources.get('bodytop', []):
${rsrc.display()}
% endfor
${next.body()}
% for rsrc in c.resources.get('bodybottom', []):
${rsrc.display()}
% endfor
/body
/html
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
-~--~~~~--~~--~--~---
Re: Toscawidgets and Pylons0.9.6rc1
On Jul 27, 2007, at 12:25 PM, Dominik Neumann wrote: Hello, i'm trying to get the Toscawidgets example running with pylons 0.9.6rc1. The only part not working for me is in middleware: def extra_vars(): return dict( py_c=pylons.c._current_obj(), g=pylons.g._current_obj(), ... where the pylons-object doesn't exist: exceptions.NameError: global name 'pylons' is not defined any ideas? do i miss something? import pylons :) 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 -~--~~~~--~~--~--~---
Re: Javascript in Pylons for ToscaWidgets with Mako
On Jul 17, 2007, at 1:13 AM, BruceC wrote: Hi all...I posted this in the ToscaWidget discussion board, (http:// groups.google.com/group/toscawidgets-discuss/browse_thread/thread/ c2250165e832c1a?hl=en) but in some ways it's more of a Pylons question, so I thought I'd ask the question here as well... I'm trying to work out how to ensure that Javascripts get loaded into a Pylons page when using ToscaWidget forms that use the Mako templating engineThe forms display properly, data validation works. I'm using the approach documented here: http://wiki.pylonshq.com/display/pylonscookbook/ToscaWidgets+and +Mako+-+example+app . The one thing missing is that the JS libraries needed for the toscawidgets calendar date picker aren't being loaded into the page header, I'm not sure of the general approach for loading JS into a Pylons app. So if anyone can shed some light on this for me, it would be greatly appreciated. :) Are you sure you're using the render_response function provided in toscawidgets.mods.pylonshf and passing all widgets to the template in the c.w attribute? 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 -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
On Jun 28, 2007, at 12:42 AM, Ian Bicking wrote: Jonathan LaCour wrote: Ian Bicking wrote: Personally I'd like to see something a bit different: * Way for a library to get the transaction manager. * Interface for that transaction manager, maybe copied from Zope. * Single convention for how to specify a database connection (ideally string-based). * Probably a way to get the configuration, so you can lazily get a connection based on the configured connection. The frameworks would setup the transaction manager and configuration, and database frameworks would basically consume this information. This would be pretty much ideal, and would satisfy my use cases very well. It would also allow framework authors to build in support for any ORM / database layer in an agnostic way, sort of like the Buffet API does for templating systems. Then, we could also create a simple WSGI middleware for Pylons that gives it TurboGears-like automatic transaction start/commit/rollback on a per request basis. Only, we could make it configurable so that it didn't happen on read-only operations. All of this would be ORM / database layer agnostic, which would be very nice indeed. The way I see this working is something like (vaguely): def transaction_middleware(app): def wrapper(environ, start_response): manager = TransactionManager() environ['transaction.manager'] = manager try: app_iter = app(environ, start_response) except: manager.rollback() raise else: manager.commit() I see you've mentioned vaguely and that paste.transaction implements it properly... but I just had to say this. An almost exact implementation of that pseudocode caused me a very embarrassing bug in which transactions were committed after the authorization middleware trapped security exceptions and turned them into 403s. Luckily it was only an internal app and the bug was noticed in- house... :) Bottom line is that the transaction middleware should rollback any transaction if the status code is = 400 to handle case like this (and that using existing, well tested code is usually better than rolling your own no matter how fun it is :) 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 -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
On Jun 28, 2007, at 7:33 PM, Jonathan LaCour wrote: Alberto Valverde wrote: I'd like to add here that I've got use-cases for the transaction boundary and session initialization being closer to the server than what the __before__ and __after__ hooks provide. For example, the authentication function I feed to AuthKit which uses a DB connection to retrieve the user and it's associated roles and permissions. I can think of other cases where other layers of middleware (more precisely, Middleware FrameWork Components) might want to access the database. Having all these layers plus the controller method (or other WSGI which sit below PylonsWSGIApp) wrapped in the same transaction sounds like a good idea to me. Fair enough to all of the above, however all the feedback from Mike and Ian has made it clear to me that we need a few different things: 1. A standard transaction manager that can be plugged into any application, WSGI or not. It should be similar in scope and API to Zope's transaction manager, but free of Zope dependancies. 2. A piece of middleware that uses the transaction manager to rollback any active transactions in the case of an exception, or commit them in the other case. (I'm assuming this middleware above the PylonsWSGIApp...) 3. Either some middleware or just a few lines inside the BaseController of the TurboGears template that starts a transaction on every request and puts it into the transaction manager. Hmmm, wouldn't having two transaction boundaries at 2 and 3 be redundant? Or maybe both boundaries will use the same manager in a similar way paste.registry has only one Registry for the whole stack? (albeit different context boundaries every time a RegistryManager is stacked) One problem I see is that this might cause trouble in cases like this: Request | V db transaction middleware - creates session A | V authentication middleware - authenticates user and keeps ref to User instance (attached to session A) | V other middleware and PylonsApp | V TG controller - creates session B inside __call__ | V authorization library tries to check permissions for mapped Foo instance (attached to session B) which has a owner attribute: foo.owner (sess B) == logged_in_user (sess A) I haven't actually tried it so I'm not sure how to objects attached to different sessions compare as or interact, so this might be a non- issue (maybe Mike can shed some light on this?) Anyway, this might be a non-issue on the whole if the transaction middleware does not handle session creation at all. OTOH, I do see the difficulty of having just one boundary in a single TG/Pylons app in a layer of middleware above PylonsApp since I don't see a clear way of making parameters passed via a decorator reach the middleware *before* the method is actually called (which will be needed to signal that a BEGIN should not be issued) 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 -~--~~~~--~~--~--~---
Re: Turbogears now based on Pylons!
On Jun 28, 2007, at 7:45 PM, Ian Bicking wrote: Alberto Valverde wrote: On Jun 28, 2007, at 12:42 AM, Ian Bicking wrote: Jonathan LaCour wrote: Ian Bicking wrote: Personally I'd like to see something a bit different: * Way for a library to get the transaction manager. * Interface for that transaction manager, maybe copied from Zope. * Single convention for how to specify a database connection (ideally string-based). * Probably a way to get the configuration, so you can lazily get a connection based on the configured connection. The frameworks would setup the transaction manager and configuration, and database frameworks would basically consume this information. This would be pretty much ideal, and would satisfy my use cases very well. It would also allow framework authors to build in support for any ORM / database layer in an agnostic way, sort of like the Buffet API does for templating systems. Then, we could also create a simple WSGI middleware for Pylons that gives it TurboGears-like automatic transaction start/commit/ rollback on a per request basis. Only, we could make it configurable so that it didn't happen on read-only operations. All of this would be ORM / database layer agnostic, which would be very nice indeed. The way I see this working is something like (vaguely): def transaction_middleware(app): def wrapper(environ, start_response): manager = TransactionManager() environ['transaction.manager'] = manager try: app_iter = app(environ, start_response) except: manager.rollback() raise else: manager.commit() I see you've mentioned vaguely and that paste.transaction implements it properly... but I just had to say this. An almost exact implementation of that pseudocode caused me a very embarrassing bug in which transactions were committed after the authorization middleware trapped security exceptions and turned them into 403s. Luckily it was only an internal app and the bug was noticed in- house... :) paste.transaction itself is something I should have really removed, as it's so incomplete. But yes, it's the basic pattern, but without a clear concept of a TransactionManager. Bottom line is that the transaction middleware should rollback any transaction if the status code is = 400 to handle case like this (and that using existing, well tested code is usually better than rolling your own no matter how fun it is :) Er... I'm not sure about this. I'm not sure =400 is really a failure. Maybe it is; I just don't feel comfortable making that claim generally. I can understand this... at least we're sure we shouldn't implicitly *commit* the transaction If you have a security exception that is caught, you could also look for the manager and roll it back exactly then, instead of expecting the middleware to do it. The middleware is just the furthest-out boundary for transactions, it's not the only place where you can control the transactions. However, this would couple the security-exception-trapping middleware with the transaction manager. Right now, the mentioned middleware's responsability is very simple: Trap security exceptions and turn them into 403s or 401s (depending if there's a user logged in). it doesn't even handle authentication (which is handled above to provide a REMOTE_USER and/or wsgi_org.user_info and trapping 401s). I can also think of other layers which could change status codes, expecting all this layers to be aware that a transaction manager is in the stack and explicitly rollback any transaction doesn't favor loose-coupling from my POV. I believe that in this scenario the most straightforward way to signal that an error (or non OK) condition has ocurred is to through the HTTP status code hence the db transaction middleware should take it into account. The question of what status codes should be treated as errors is still open though... Alberto -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers --~--~-~--~~~---~--~~ 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: Turbogears now based on Pylons!
On Jun 28, 2007, at 8:52 PM, Mike Orr wrote:
On 6/28/07, Jonathan LaCour [EMAIL PROTECTED] wrote:
3. Either some middleware or just a few lines inside the
BaseController
of the TurboGears template that starts a transaction on every
request and puts it into the transaction manager.
And, in my opinion, items #1 and #2 should be in Pylons by
default, and
the third item should be in the TurboGears template by default.
... and available to non-TG Pylons applications. The @transactional
decorator sounds like a good idea, possibly with a False flag if the
default is transactional.
This is a good point to ask, how will the TG template differ from the
standard Pylons template? Will there be a base controller, or at what
point will they diverge? Where will CherryPy-style dispatching be
implemented? I imagine you will override PylonsApp and/or
PylonsBaseWSGIApp in pylons.wsgiapp, no?
The dispatching is currently implemented in a route method in a
PylonsWSGIController subclass. There's a route defined like:
map.connect('*url', controller='root', action='route')
That handles it url to further dispatch it, cherrypy style. Here's
all the meat:
http://trac.turbogears.org/browser/trunk/tg/controllers.py#L58
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
-~--~~~~--~~--~--~---
Re: Toscawidget example partially renders tags as entities
On Jun 22, 2007, at 7:25 PM, Brendan Arnold wrote: Hi there, I have followed the instructions on http://docs.pythonweb.org/display/pylonscookbook/Getting+Started +With+ToscaWidgets+and+Pylons and although the example serves ok and outputs html, some of the fields later in the form (specifically the fields after the password confirm box to the submit button) are rendered with lt; and gt; entities and show up as html code on the page This was the case with the wsgi_app.py as well This isn't specific to my browser, I have tried with both ff and opera. I have double checked the code and it seems to be exactly as in the article. Some details, python 2.4.4 Pylons-0.9.5 paste 1.3 myghty 1.1 formencode 0.7.t toscawidgets 0.1a2dev twForms 0.1a2dev any ideas? Try removing RuleDispatch and PyProtocols from your lib and reinstall them. This has happened before to some people and, though I'm not 100% sure, I believe this issue is related to old versions of these libraries being around. Alberto BTW: Cross-posting to toscawidgets-discuss. Please follow up there. --~--~-~--~~~---~--~~ 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: paster shell not available
On May 17, 2007, at 1:29 PM, Max Ischenko wrote: On 5/16/07, Alberto Valverde [EMAIL PROTECTED] wrote: $ paster shell development.ini Command shell not known Make sure there's a file called paster_plugins.txt inside your egg_info directory with, at least, the following lines: Pylons PasteScript That was it, thanks! On a related note, how can I extend paster controller command to use different templates? Hmm, not sure since I've never done it... If you want some ideas... I would begin looking up the code at pylons.commands:ControllerCommand (where the controller paste.paster_command entry point points to), copy it in my project (or some utilities egg), add the corresponding entry point to the egg's setup.py (with an alternate name) and add the egg's name at paster_plugins.txt of the app I want the command available at. Once the new command emulates Pylons' I would start tweaking the template to suit my needs. Hope it helps, 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 -~--~~~~--~~--~--~---
Re: paster shell not available
On May 16, 2007, at 11:09 AM, Max Ischenko wrote: Here is the question: where is paster shell command hooked in? When I attempt to use paster shell in my current project I got this: $ paster shell development.ini Command shell not known Known commands: Newly created Pylons projects have this functionality working so I guess I need to upgrade something in my existing project to get this command. Make sure there's a file called paster_plugins.txt inside your egg_info directory with, at least, the following lines: Pylons PasteScript 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 -~--~~~~--~~--~--~---
Re: Spawning a worker thread from the controller?
On May 5, 2007, at 2:59 AM, Shannon -jj Behrens wrote: On 5/4/07, Matt Billenstein [EMAIL PROTECTED] wrote: On Fri, May 04, 2007 at 05:27:42PM -0700, Shannon -jj Behrens wrote: On 5/4/07, Matt [EMAIL PROTECTED] wrote: Hi, I have a pylons app which I want to spawn a long-running process from. While this process is running (might be an hour or so), I want the page that kicked off this process to just display status (maybe referesh ever 30 seconds or so)... Does anyone have some pointers on how this should be done or what packages I should be looking into? I've done this before, but not in Pylons. Spawning a long running process or thread is fine. Watch out for Paste because I think Ian put in some code to watch for runaway threads--it's probably fine. Use a timer and AJAX to have the Web page poll the server to see if the work is done. (You could use Comet, but polling is probably fine. Ignore this statement if you don't know what I'm talking about.) In the best case, you can use a progress bar on the page. Just work your way through it; I'm sure you'll be fine. Any recommendations on passing status between the worker thread and the controller when it's polling? I tried just using class variables, but they don't seem to get updated between the threads... How were you updating the class variable? ClassName.variable = foo? If you do self.variable = foo, you're shadowing the class variable. By the way, naturally, watch out for race conditions. Another option is to use the queue module and have the worker thread push messages onto the queue, and the controller can read messages from the queue. I tend to prefer message queues over explicit lock management. I've found this threadpool implementation useful for a similar task: http://tinyurl.com/yw6xc9 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 -~--~~~~--~~--~--~---
Re: Pylons and Rights to Objects...
On May 2, 2007, at 4:46 PM, durumdara wrote: Hi! I used Zope before modpy, and now I subst. to Pylons. I want to ask something about rights and objects. The Zope's philosophy that everything in the site is an object, and every of these objects have special attributes named rights. With these rights you can set what object is published, and what rights or roles needed to access this object. In modpy I need to do same thing, because I need to use menus, and menus linked to pages - so every page have three base attributes (path, title, rights). In directories I have a special file that described the pages in this dir, and grouped them to menus. In Pylons I don't see same thing, but I need it, because my site need forbidden areas, and I want to centralize the pagetitle / page right handling. What solution YOU used IN YOUR SITE? I've written a small authorization library [1] based on peak.security [2] and use AuthKit [3] for authentication. The combination has been running for a couple of months in a production site and I'm quite happy with the results Maybe you find it useful (DISCLAIMER: TPS has no docs except for some unittests) Alberto [1] http://svn.toscat.net/TPS/trunk [2] http://peak.telecommunity.com/DevCenter/SecurityRules [3] http://authkit.org --~--~-~--~~~---~--~~ 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: [OT] backend processing of large jobs
On Apr 12, 2007, at 4:25 PM, Sean Davis wrote: Thanks, Alberto. That is what I was thinking. Just to followup, if I may, but where do you keep your threadpool so that all requests have access to it? In a global variable? place it at yourapp/lib/app_globals:Globals binding it to self inside __init__. You'll have it availbale at pylons.g Alberto --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Deleting expired sessions
Hi, I'm using Beaker to manage sessions with the dbm backend and noticed that expired sessions are not deleted automatically. I see there's a session.delete method which seems right what I'm lookinng for... What's the best way to ensure that it's called when a session has expired? Thanks, 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 -~--~~~~--~~--~--~---
Re: Deleting expired sessions
On Mar 21, 2007, at 11:37 PM, Ben Bangert wrote:
On Mar 21, 2007, at 3:25 PM, Alberto Valverde wrote:
I'm using Beaker to manage sessions with the dbm backend and noticed
that expired sessions are not deleted automatically. I see there's a
session.delete method which seems right what I'm lookinng for...
What's the best way to ensure that it's called when a session has
expired?
If you have the session expiration set to go after 20 mins, then a
find command to locate all session files not touched in the last 20
mins would do the trick. I recall seeing a snippet somewhere in the
past that deleted them all.
I see, I thought there might have been some sort of session
expired callback to do it automatically...
find sessions/ -amin +20 -type f -exec rm {} ';' did the trick.
Thanks
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
-~--~~~~--~~--~--~---
Re: POST showing up as GET
On Mar 17, 2007, at 6:28 PM, vga wrote: I've managed to get the toscawidgets 0.1a2dev_r2777 demo running under pylons 0.9.4.1 (well with minor changes to use myghty). But I've encountered a weird bug. The POST request from the demo form shows up as GET on the server side, which cause the @validate to never execute. Obviously this causes an exception due to nonexistent form_result. I've verified with ethereal that the browser is actually sending a POST request to the server, but it shows up as GET in the server request dict. Here is the TCP stream reassembled by ethereal: (snip) This is weird indeed. I've managed to reproduce the problem with unchanged PylonsTWSample though I haven't tracked down the source. The problem, however, doesn't manifest itself in other Pylons apps I've written (I would have noticed that long time ago... :) so I guess it must be some stupid bug in the sample. I'll probably rewrite that sample app soon with 0.9.4.1 and new helper code based on http:// tinyurl.com/26zyk9. 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 -~--~~~~--~~--~--~---
Re: ANN: Documentation Wiki Launched
On Mar 19, 2007, at 7:59 PM, Kevin Monceaux wrote: Fellow Pylons Enthusiasts, On Sun, Mar 18, 2007 at 02:10:00PM +, James Gardner wrote: I'm pleased to announce the launch of a new wiki for Pylons documentation where we would encourage you to contribute any articles or information which you would usually post on the current Pylons Trac-based wiki. I'm very happy to see some additional Pylons documentation. I've been trying out both TurboGears and Pylons. There are a few things I like better about Pylons than TurboGears but I've been working mostly with TurboGears because of the available TG documentation and for TG widgets. It looks like Pylons is improving in both areas. There are a couple of things I'm wondering about: Is choosing a J2EE based wiki really a good way to promote python web development? Wouldn't a python based wiki be a better choice? And, if primarily for Pylons wouldn't a Pylons based wiki be an even better choice? Well, I guess it all boils down to the choice of a tool for a job. If the tool fits well it's purpose and it's already developed and usable, then who cares what technology is powering it behind the scenes? Something positive can be said for Python for sure: how nicely it integrates with most languages. The syntax coloring is powered by pygments running under Jython :) 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 -~--~~~~--~~--~--~---
Re: What should I use to generate forms on the fly?
On Feb 14, 2007, at 11:25 AM, Max Ischenko wrote: Hi, Thank you for the quick answer. I'm wondering if I should go with formbuild or ToscaWidgets. Which of the two is more likely to be a stable solution in the near future? Hard question. I haven't used formbuild myself and ToscaWidgets is certainly not stable yet and I have no idea when it stabilize. I can suggest spend some time with both (starting with TW) and make your opinion. And look into source code, because chances are you may need to hack it. ;) I'd like to add that ToscaWidgets is already aiming for API stabilization since I released a first alpha a few weeks ago. I'm making heavy use of them in some projects and they're certainly stable in the sense that they don't break mysteriously ;). The desperately need some docs though... for sure, but there's a surprise regarding this in a few weeks... :) 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 -~--~~~~--~~--~--~---
Re: Request: tutorial for ToscaWidgets :)
On Feb 5, 2007, at 6:32 PM, Damjan wrote: I've created this Genshi markup for a project of mine http://groups.google.com/group/pylons-discuss/web/edit.html ... now I have this tagging widget there that works with Mochikit. It shows the tags associated with a page, and allows for AJAX adding and removing of the tags (with all the bells and whistles). So the input to the widget is, the initial taglist, addtag and removetag URL's and a url for the activity indicator. It would be nice if those parameters could be passed to a constructor in a single js call, that would make wraping it in a TW quite easy and it would allow having multiple taggers in the same page. Now I thinks it would be great if this was a ToscaWidget, that I could reuse in other pages.. but I don't know anything about ToscaWidgets (yet) ... so maybe if someone can create a ToscaWidget of this example it would be an interesting and helpfull tutorial? Indeed :) I'm having the same problem as David mentioned, quite a few widgets made for projects but none simple, yet interesting enough ones to use as examples (well, apart from all the crappy late-hour rushes which I'm too embarrased to share ;). I'm pretty short of time lately but if you could rearrange the js to be initialized with a single call I'll try to provide a widget with commented code soon. Thanks, 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 -~--~~~~--~~--~--~---
Re: how (Tosca)Widgets fits into MVC concept
On Jan 25, 2007, at 12:42 PM, Ksenia wrote: On Jan 25, 11:31 am, Ksenia [EMAIL PROTECTED] wrote: Thanks for feedback! New google groups interface seems not to have accepted my reaction from yesterday :( Just testing now... (Ok, seems to work :) After reading al your helpfull reactions I see that my confusion with TG/TW widgets is more about it's implementation: - general widgets like TinyMCE, grids, js trees, select shuttle, etc. belong to the concept of helpers. I dont care how they made, where they are installed on the system - I just want to use them. So the egg system and TW are great for that. - domain-specific widgets, like product info, is something that I see as a template that should be in the products view directory. It makes more sense to me to see those widgets as clever templates with some extra python code in it. TW/TG widgets feels upside down for this use. Just the matter of taste I guess. Of course. It's up to you to decide which views are general enough to deserve encapsulation in a reusable component or could benefit from being clever templates (being clever meaning they know what static resources (js, css, images...) they need for rendering and pull them automatically when they're used in a page). But keep in mind, TW widgets are a superset of form widgets. Depends on your taste and style but widgets can be used for other things apart from validation (a js drop-down menu, for example). From a user's perspective they're just objects you can instantiate setting some initial state that affects how they behave and then be call them in a template to generate a chunk of markup. To sum up: they are equivalent of a template function but that can take care pulling static files and be encapsulated with all it's baggage into a reusable component. TW is just an API to create them, in fact, twForms ATM is more of a proof of concept which provides *very* basic widgets, they could be much enhanced with client-side scripting, styling, etc... 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 -~--~~~~--~~--~--~---
Re: I'm lost with ActiveMapper
On Nov 16, 2006, at 11:31 PM, Bruno Silva wrote:
On 11/16/06, Shannon -jj Behrens [EMAIL PROTECTED] wrote:
I haven't used activemapper, but does this help?
http://pylonshq.com/project/pylonshq/wiki/SqlAlchemyWithPylons
I think the challenge is that you need to actually connect the
engine,
and you need a dsn to do that.
Didn't help much, because with ActiveMapper the connection is made
diferently.
And the example I show before works,... until I add a ForeignKey to
another table, then ActiveMapper gives again the error can't find
engine|mapper|connect
I'm trying to dive in the internals, but for a python newbie is a kind
of hard :-)
I made a simple script like:
activemapper.metadata.connect('mysql://user:[EMAIL PROTECTED]/
database')
#declare classes, like the User example
t = objectstore.context.current.create_transaction()
#do things with all classes, insert/select/update/delete
t.commit()
everything works. But in pylons I just can't get things to work right.
And doing the connect in every request is not the best thing to do :-)
Hi,
Maybe you can get some ideas from how TurboGears sets ActiveMapper up
in http://tinyurl.com/yh5zeh.
In database.py (lines 21-48) the engine is configured, ActiveMapper's
metadata is bound to it and ObjectStore is configured and bound to
session. This is done once when the app is loaded so I guess you
should do something similar in your Pylons app's websetup.py and bind
session to an app_global to use it in your controllers. Your tables
should be configured with the metadata you just configured there
(make sure metadata is configured before importing the module where
you define your tables).
You could also edit BaseController in lib/base.py to start a new
transaction before returning WSGIController.__call__ and wrap
start_response to commit the transaction if no exception is raised or
roll it back if an exception occurs.
I'm a Pylons newbie (yet, I hope...) so I'm not really sure if this
would work, if the same technique can be applied to Pylons, or if
it's an optimum solution; but, a-priori, I can't see why it couldn't
BTW, I'm in the process ATM of migrating a TG app to Pylons so I
might be able to give better advice in a few days.
HTH,
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
-~--~~~~--~~--~--~---
