[TurboGears] TastyAuth: simple social auth(entication|orization)
Hi folks! I've just published TastyAuth, a python module to integrate third-party providers (read: Google, Facebook, Twitter): * https://github.com/vrde/TastyAuth It is designed to be framework agnostic and it is extremely easy to integrate with your existing web application, you just need a `redirect` and a WSGI environ, here is an example of integration with Bottle: * https://github.com/vrde/TastyAuth/blob/master/example/server.py I'm not new to TurboGears, I started using it in 2007, and I used also repoze.who/what which is a pretty solid choice. But it would be great if you give TastyAuth a try and tell me what you think about it! I believe it is very easy to integrate with the TurboGears 2 framework. cheers, Alberto -- You received this message because you are subscribed to the Google Groups TurboGears group. To view this discussion on the web visit https://groups.google.com/d/msg/turbogears/-/Ke0WKxUXbVIJ. To post to this group, send email to turbogears@googlegroups.com. To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
[tg-trunk] Please bump up TG2's dependency on TW/tw.forms to 0.9.7.1
Subject says it all, last release breaks tw.forms when displayed on Genshi and this one should fix it. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: repoze.what-pylons
Mark Ramm wrote: If the require decorator is a real decorator, like all other real decorators needs to go inside the expose decorator or else the function that's exposed won't be the one that's actually called, and it won't have the right function attributes. We definitely need to document this better. Perhaps you can work around this by copying the original function's __dict__ into the wrapper's before returning it from the decorator. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Best way to get URL of deployed TG app
Gustavo Narea wrote: On Tuesday February 3, 2009 13:20:58 Alberto Valverde wrote: url = '%s://%s%s' % tuple(environ[k] for k in wsgi.url_scheme, HTTP_HOST, SCRIPT_NAME) Or: from paste.request import construct_url url = construct_url(environ) Which will also take the port into account. Nice shortcut, thanks! Anyway, ftr, HTTP_HOST already contains the port so both solutions are valid. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Best way to get URL of deployed TG app
Alberto Valverde wrote: Gustavo Narea wrote: On Tuesday February 3, 2009 13:20:58 Alberto Valverde wrote: url = '%s://%s%s' % tuple(environ[k] for k in wsgi.url_scheme, HTTP_HOST, SCRIPT_NAME) Or: from paste.request import construct_url url = construct_url(environ) Which will also take the port into account. Nice shortcut, thanks! Anyway, ftr, HTTP_HOST already contains the port so both solutions are valid. BTW, to use construct_url to get the base url of the application (what I think the P wanted, instead of the url of the request currently being served) one needs to tell it not to take PATH_INFO and the query string into account, so that should be: construct_url(environ, with_query_string=False, with_path_info=False) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: tg.include_widgets like functionality in TG2?
Christoph Zwerschke wrote: Diez B. Roggisch schrieb: I currently face the problem that I want to include jquery in *every* page we render, independent of a TW-widget that references it. So I wonder if there is a tg.include_widgets-like functionality available or planned that allows me to do that? There isn't but it is very easy to implement it on a per-project basis. The easiest way to include the in *every* html page is to override BaseController in yourapp.lib.base and add this in the __call__ method before delegating to super: for widget in include_widgets: widget.inject() I guess that if TG2 doesn't mind to couple a little bit more with TW the a 'include_widgets' attribute could be added to the config and the above line included in TGController so users don't have to do it explicitly. Or perhaps it could be added to the quickstart template, or... You can include it directly in your master template. But I guess your problem is that if you use widgets that include jquery explicitly, then jquery will be included double. As long as the JSLink wrapper use is the same links are only included once no matter how many widgets include them or if you inject() it manually. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] [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 TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Fwd: [TurboGears] #2152: TurboGears is shallowing up 401 from wsgi apps.
Mark Ramm wrote: @gustavo thank you very much, it was exactly that problem. @Alberto, yes I though about that but as Gustavo pointed out in the changelog, the error middleware should be the last one to show up and it was catching the 401 before repoze.who did. I actually think this solution isn't quite right. We can do as alberto suggests and stop trapping 401's in the error handler, and things should go back to working, unless there's another problem I'm not seeing. Quick FYI: I've disabled trapping of 401's if auth middleware is on in http://trac.turbogears.org/changeset/6137 since it also affected the new flash since cookies were swallowed when internal-redirecting to the error page. Should be no problem since we don't need to render a nice error page when it's never going to reach the user. And we're dropping the sqlalchemy session with the session removal middleare, and now repoze.what is outside of that so if it tries to do anything on the way out, it won't have an active DBSession. So, the current solution is broken. db_session_remover should be the last middleware executed on egress that needs access to SA's scoped session. If it isn't then further accesses to it will automatically create a new one which will contaminate the next request that the thread that opened it handles. Sure recipe for hard to track and reproduce bugs. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: repoze.what 1.0 Final and 1.0.1 released
Gustavo Narea wrote: On Thursday January 22, 2009 13:46:29 Jorge Vargas wrote: I got a production app (running 0.9.7something) which I'm in the process of upgrading to 2.0bsomething. I have check my code and I'm not affected by this per se. FTR, it affects *any* TG 1.9.7/2.0 application that uses the following predicates: All, in_all_groups and in_any_group. I would hold back the release of the next beta until a new minor release of repoze.what is made since a bug of the same nature remains in predicates.Any. I've explained it in more detail and sent a patch to fix it privately to Gustavo. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: rum admin vs catwalk2 admin
The differences are mostly architectural but the goal is mostlty the same: provide an automatic CRUD interface for model objects. Which ones if better? Well, it depends on who you ask ;) Time will tell which one is able to accommodate the functionality it plans to implement in a better way. Both should be fully customizable, probably Rum is more since it uses generic functions inside so you can hook into many points inside the application to override how it works (if you know how). For example, the SQLAlchemy plugin (RumAlchemy) extends in this way the default controller so it can handle the exceptions SQLAlchemy raises, all of this without you needing to use a different controller. However, this is both a blessing and a curse since it probably means Rum has a steeper learning curve if you're not familiar with generic functions. Anyway, besides the GF low-level way of customizing Rum there's an API that hides the peak.rules internals so you can go a long way without even knowing that they're used. Both use toscawidgets to generate forms, so you can carry this knowledge from Rum to TG2 to Catwalk and back. Once you know how to create a TW form you can plug it into any framework that uses them. Sprox is not required to build a tw.form (although it can save you some time). On the other hand, TW is not required to use Rum: you can easily build a custom form by hand or with other tools and plug it into Rum for certain views. Catwalk2 is a TG2 controller so you can only use it inside TG2. Rum is a stand-alone WSGI application so you can use it with any modern python framework. Although Sprox is independent of any framework, Sprox is only the automatic form generation library to build TW forms. Rum has decided to tightly couple the model introspection and form generation into its core since by doing that it has access to some basic services which Sprox doesn't have access to: url generation facilities to generate urls for any model, current locale, and (soon-to-be-implemented) security policy (to hide some fields from some users, etc...). This is one of the reasons Rum was designed to be a stand-alone app. in the first place. Catwalk2 will probably have a larger user-base than Rum in the long run since the TG lead quietly decided it will bundle it with TG2 instead of other alternatives. If this matters much to you you should take it into account. Finally, Rum has (and will probably have for a long time) horrible marketing so don't expect to hear much about its hidden gems out there in the streets if you don't ask (and someone is willing to elaborate on them) ;) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Authorization messages are not flashed anymore
Gustavo Narea wrote: Hello, Authorization-related messages are no longer flashed in TG2 trunk. Could this be related to the modifications to the flash() function lately? That's most probable since the flash payload is now passed in a cookie and this cookie is lost somewhere in the middleware stack if the response's status is a 401. This doesn't affect only flash but can potentially affect any application using cookies. I've just comited a FIXME test to prove it: http://trac.turbogears.org/changeset/6135 My guess is that repoze.who's RedirectFormPlugin is not copying the cookies from the 401 response when traps it and redirects to the login handler but I need to confirm it. Will try to that tomorrow. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Authorization messages are not flashed anymore
Alberto Valverde wrote:
Gustavo Narea wrote:
Hello,
Authorization-related messages are no longer flashed in TG2 trunk. Could
this
be related to the modifications to the flash() function lately?
That's most probable since the flash payload is now passed in a cookie
and this cookie is lost somewhere in the middleware stack if the
response's status is a 401. This doesn't affect only flash but can
potentially affect any application using cookies. I've just comited a
FIXME test to prove it:
http://trac.turbogears.org/changeset/6135
My guess is that repoze.who's RedirectFormPlugin is not copying the
cookies from the 401 response when traps it and redirects to the login
handler but I need to confirm it. Will try to that tomorrow.
Confirmed. The following patch makes the test pass so it will probably
fix the flash issue:
Index: repoze/who/plugins/form.py
===
--- repoze/who/plugins/form.py(revision 3293)
+++ repoze/who/plugins/form.py(working copy)
@@ -190,7 +190,8 @@
url_parts[4] = urllib.urlencode(query_elements, doseq=True)
login_form_url = urlparse.urlunparse(url_parts)
headers = [ ('Location', login_form_url) ]
-headers = headers + forget_headers
+cookies = [(h,v) for (h,v) in app_headers if h.lower() ==
'set-cookie']
+headers = headers + forget_headers + cookies
return HTTPFound(headers=headers)
It's late here, I'll send a proper patch tomorrow to the repoze people
tomorrow with a test case hopefully.
Alberto
P.S: Cc'ing them in case a kind soul wants to beat me to it while I'm
asleep :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: Fwd: [TurboGears] #2152: TurboGears is shallowing up 401 from wsgi apps.
Jorge Vargas wrote:
Hi, I'm not 100% sure if this bug is introduced by TG's
ErrorController or pylons or the new WSGIAppController (or any other
changes in between) But the above configuration is eating up the 401
response, and displaying it as an error, while the expected behavior
is to trigger repoze.who.
Could someone confirm or deny this is a bug in TG? also I'll love to
have a suggestion on how to fix it as I'm not familiar with this part
of the code.
{{{
def simple_app(environ, start_response):
Simplest possible application object
status = '401'
response_headers = [('Content-type','text/plain')]
start_response(status, response_headers)
return ['Hello world!\n']
class RootController(BaseController):
error = ErrorController()
hg = WSGIAppController(simple_app)
}}}
The error is being handled by TG's ErrorController, if I delete that line
it's dropping to pylon's error controller.
Therefore I believe somewhere in the TG stack this is not being delegated
to repoze.who, which it should.
Hmm, I think this might be the StatusCodeRedirect trapping it, try
configuring an app like this see what happens:
app_config.handle_status_codes = [404]
That is, removing the 401 and 403 it handles by default as specified
here:
http://trac.turbogears.org/browser/trunk/tg/configuration.py#L142
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Important! Update your TG2 apps [WAS:] Re-implement flash without sessions
Jorge Vargas wrote:
If someone wants to cook a widget or something for this or add a config
option so TG can use one or the other or something the community will
appreciate it (hint, Jorge, hint ;)
Ok I will :) But I can't promise I could get some time before b3, it
seems we are going to have b4 so I don't see this as a problem (nor a
blocker), of course for this to work what you say below has to be
implemented, which I'm +1
Nevermind, I already implemented a helper :) read below...
One more thing: I'd finally like to change the DOM structure and CSS of
the quickstart template to match the structure generated by the JS
version. Mainly so both versions can be used interchangeably and because
the current one sucks ;) Why? Because:
1) The class of the message should be conveyed in a... class attribute.
The current implementation makes impossible to refer to the *unique* div
that holds the flash in a reliable way from JS code. The id should
remain static, the class should vary with the kind of message (not the
other way around)
2) If the flash message is wrapped in a div inside the flash div then
one can implement floating centered messages easily.
To make it easy to visualize, the dom structure that the js code
generates is like this:
div id=some_id_of_your_liking
div class=status_codeMessage/div
/div
So the CSS style this could be something like:
#some_id_of_your_liking {
display: none; /* Recommended so a conditional can be avoided, the
JS code will make it visible */
...
}
#some_id_of_your_liking .ok { }
#some_id_of_your_liking .warn { }
#some_id_of_your_liking .error { }
Please strip the status_X prefix from the status code names, it is
redundant to say:
flash(lalalala, status=status_ok)
much nicer (IMHO) and less typing (mathematically provable):
flash(lalala, status=ok)
If no one object I'll implement these *slightly* breaking changes (for
existing users) tomorrow. Note that the default will still be non-js
flash messages, I'm just proposing to change the dom structure and CSS
to keep both in sync so it is easy to change between them.
Done in:
http://trac.turbogears.org/changeset/6114
http://trac.turbogears.org/changeset/6115
http://trac.turbogears.org/changeset/6116
http://trac.turbogears.org/changeset/6117
The quickstart template has been updated to the new DOM structure and
existing apps should continue working but show deprecation warnings.
How to upgraded your existsing apps (the following instructions could be
copy and pasted somewhere in the CHANGELOG)
1) The flash message is now rendered like this (in a genshi template)
py:with vars=flash=tg.flash_obj.render('flash', use_js=False)
div py:if=flash py:content=XML(flash) /
/py:with
Note that the tg.flash_obj.render() method returns a string so we need
to use the XML wrapper (not the HTML!) so genshi doesn't escape the html
entities. The conditional is so XML doesn't barf when there's no flash
(and we're not using JS) since render() will return an empty string.
To enable JS flash messages and be able to cache your pages just pass
use_js=True to the render() method
1.5) Using the helper in string based templates is easier, just do:
${tg.flash_obj.render('flash', use_js=False)}
2) Upgrade the your CSS to the new DOM structure, which is:
div =$flash_id
div class=$status$message/div
/div
The one in the quickstart template looks like:
#flash {
font-size:120%;
font-weight:bolder;
margin:0pt auto 0.5em;
width:680px;
}
#flash div {
padding:5px 15px 15px 55px;
}
#flash .ok {
background:#FF url(../images/ok.png) no-repeat scroll left center;
border:1px solid #EE;
}
#flash .warning {
background:#FF url(../images/error.png) no-repeat scroll left center;
border:1px solid #FF;
}
#flash .alert {
background:#99 url(../images/info.png) no-repeat scroll left center;
border:1px solid #00;
}
3) Change your code so the status string you pass to flash() does not
contain the status_ prefix, eg:
status_ok - ok
status_warning - warning
status_alert - alert
This step might not be needed if you use custom status codes
The tg.flash and tg.flash_status variables in the template have been
deprecated, the equivalents are tg.flash_obj.status and
tg.flash_obj.message. Note that any access to these will remove the
cookie so do not access them if using JS to render the messages.
Enjoy,
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: [rum-discuss] Re: Re-implement flash without sessions
Alberto Valverde wrote:
Jorge Vargas wrote:
On Fri, Jan 16, 2009 at 9:58 AM, Mark Ramm mark.mchristen...@gmail.com
wrote:
I think this is a good idea. It adds a little bit of complexity to
the template side of things, but we can use a widget in the
master.html to do the flash message via javascript so things can just
work out of the box.
If it's done right away, it can go into tg 2.0, if it takes a bit I'd
support a switch from the current flash implementation to this in
2.1.
I wonder if it could be put into webhelpers rather than into a seprate
library, since its a generally useful pattern
am I the only one concern by the fact that this will require JS on ALL
TG2 apps to be enable?
I think that nowadays all *webapps* (as opposed to *webpages*) require
JavaScript anyway. Flash is mostly used in the former so I think that
the advantages (cacheability, making servers state-less (or avoid having
to sign marshalled sessions in cookie)) fairly outweight the minor
disadvantages that requiring JS imposes.
How about make it a second implementation in a configurable way? so
you could either use the session or js thing, kind of like how beaker
swaps backends?
That is easier said than done ;). Anyway, the interface I've implemented
[1] can be extended to support fetching the cookie from the request
(please keep it a simple cookie so no sessions are needed) so... I'd
happily accept a patch to add a ServerFlash subclass to add that
functionality. But please: don't add new dependencies (currently only
the stdlib is required if python 2.6 is used + a response object that
has a set_cookie(name, value) method (eg: webob's)) and keep it portable
across any WSGI framework.
I've finally integrated WebFlash (that's the name of the library I've
release implementing this) into TG2 at:
http://trac.turbogears.org/changeset/6112
Some notes:
* Released at PyPI, should be added to TG2's private index
(http://pypi.python.org/pypi/WebFlash/)
* Due to popular demand, I've added support for flash without JS.
* The transport mechanism has changed to be a plain old cookie instead
of the session. This enables users to display the message more easily
from JS code and allows the use of TG2 without sessions.
* Code is unit-tested (both the JS part and the python part) and documented.
* The JS part has been tested to work under under IE6, IE7, Safari,
mobile Safari (aka: iphone), Chrome, Opera and Firefox 3)
* All of TG2's unit-tests pass without any modification. So, in theory,
no backwatds incompatible change has been introduced
Instructions:
To enable JS-only flash (recommended, but YMMV) you need to change your
master template:
Change:
div id=${tg.flash_status} py:if=tg.flash class=flash
py:content=tg.flash
/div
To:
${flash.render_genshi(some_id)}
div id=some_id /
That's all, the 1318 of minified JS code to support that will be inlined
in a script tag. If you don't want this code inlined you should:
a) Add a controller method that serves the file whose path is stored
at flash.js_path and add a script link to it.
b) Add this somewhere in your head: script type=text/javascript
content=XML(flash.js_call('some_id')) /
b) Tweak the CSS since the DOM structure the JS version generates is
slightly different.
If someone wants to cook a widget or something for this or add a config
option so TG can use one or the other or something the community will
appreciate it (hint, Jorge, hint ;)
One more thing: I'd finally like to change the DOM structure and CSS of
the quickstart template to match the structure generated by the JS
version. Mainly so both versions can be used interchangeably and because
the current one sucks ;) Why? Because:
1) The class of the message should be conveyed in a... class attribute.
The current implementation makes impossible to refer to the *unique* div
that holds the flash in a reliable way from JS code. The id should
remain static, the class should vary with the kind of message (not the
other way around)
2) If the flash message is wrapped in a div inside the flash div then
one can implement floating centered messages easily.
To make it easy to visualize, the dom structure that the js code
generates is like this:
div id=some_id_of_your_liking
div class=status_codeMessage/div
/div
So the CSS style this could be something like:
#some_id_of_your_liking {
display: none; /* Recommended so a conditional can be avoided, the
JS code will make it visible */
...
}
#some_id_of_your_liking .ok { }
#some_id_of_your_liking .warn { }
#some_id_of_your_liking .error { }
Please strip the status_X prefix from the status code names, it is
redundant to say:
flash(lalalala, status=status_ok)
much nicer (IMHO) and less typing (mathematically provable):
flash(lalala, status=ok)
If no one object I'll implement these *slightly* breaking changes (for
existing users
[tg-trunk] Re-implement flash without sessions
Hi, I'd like to propose (and I'm volunteering to do it) to re-implement TG's flash using the transport mechanism it used before: a POC (plain old cookie). This would be implemented as a stand-alone egg with no other dependence apart from webob (perhaps not even webob, a Request/Reponse object that implements a sub-set of webob's interface could be duck-typed). The main reason is selfish: I'd like to use this in Rum and would like it to inter-operate in the best possible way with TG. Sharing the same code would be ideal. The other reasons (which are more important ;) are that: 1) Flash messages are easier (possible) for a rich client ui to read since JS can read the cookie directly. 2) Flash messages can be displayed by JS code in non-dynamic pages without needing to put them in the template. This makes pages easier to cache. 3) Apps can be session-less All these advantages are explained much better than here in this post: http://blog.ianbicking.org/2008/12/17/javascript-status-message-display/ I'm probably going to implement it for Rum anyway but if TG is interested I can take it into account from the beginning and make sure it integrates well. Alberto P.S. Cross posting to rum-discuss since this also involves Rum but it is already being discussed in a ticket there (http://python-rum.org/ticket/62), please reply only to turbogears-trunk. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: [rum-discuss] Re-implement flash without sessions
Mark Ramm wrote:
I think this is a good idea. It adds a little bit of complexity to
the template side of things, but we can use a widget in the
master.html to do the flash message via javascript so things can just
work out of the box.
Template wise, I hope it will turn out to be a js include and js call
away, something like:
script src=/script
script type=text/javascript
(new Flash({some options or none for sane
defaults})).render(some_id_or_dom_node)
/script
As a helper, the JS call could be generated with python with something like
${flash(dom_node_id, **options)}
The API to generate messages from the controllers would be something like:
flash(mesage, status=info, webob_request_like, webob_response_like)
Of course, TG could wrap this call and partially apply both response and
request from the SOPs, resulting in the familiar:
flash(message, status=foo)
If it's done right away, it can go into tg 2.0, if it takes a bit I'd
support a switch from the current flash implementation to this in
2.1.
Right away like.. this weekend? (arrg I hate deadlines ;)
I wonder if it could be put into webhelpers rather than into a seprate
library, since its a generally useful pattern
Hmm, I'm not using webhelpers in Rum so I'd rather not introduce a new
dependency. I prefer to have it at a standalone egg (not even depending
on TW, which would make it easier to implement). Besides that, it will
need some JS support code and AFAIK webhelpers is moving away from
bundling js in their package.
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: [rum-discuss] Re: Re-implement flash without sessions
Jorge Vargas wrote: On Fri, Jan 16, 2009 at 9:58 AM, Mark Ramm mark.mchristen...@gmail.com wrote: I think this is a good idea. It adds a little bit of complexity to the template side of things, but we can use a widget in the master.html to do the flash message via javascript so things can just work out of the box. If it's done right away, it can go into tg 2.0, if it takes a bit I'd support a switch from the current flash implementation to this in 2.1. I wonder if it could be put into webhelpers rather than into a seprate library, since its a generally useful pattern am I the only one concern by the fact that this will require JS on ALL TG2 apps to be enable? I think that nowadays all *webapps* (as opposed to *webpages*) require JavaScript anyway. Flash is mostly used in the former so I think that the advantages (cacheability, making servers state-less (or avoid having to sign marshalled sessions in cookie)) fairly outweight the minor disadvantages that requiring JS imposes. How about make it a second implementation in a configurable way? so you could either use the session or js thing, kind of like how beaker swaps backends? That is easier said than done ;). Anyway, the interface I've implemented [1] can be extended to support fetching the cookie from the request (please keep it a simple cookie so no sessions are needed) so... I'd happily accept a patch to add a ServerFlash subclass to add that functionality. But please: don't add new dependencies (currently only the stdlib is required if python 2.6 is used + a response object that has a set_cookie(name, value) method (eg: webob's)) and keep it portable across any WSGI framework. Alberto [1] http://hg.python-rum.org/WebFlash --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Genshi and the meta content line...
samsli...@gmail.com wrote: The quickstart for Genshi has the line meta content=text/html; charset=UTF-8 http-equiv=content-type py:replace='' / as the first line of the head section for both the master.html and the welcome.html. I've been dutifully following this example. But today I started cleaning up and simplifying my templates. I'm wondering whether it is really necessary to have this line in each template if it's also in my master template. It's not absolutely necessary since TG will send a content-type header to the client when it renders them (in fact, as you can see, that tag will be stripped when processed) but it is useful if your templates contain UTF8 characters and want them to display properly when editing them. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: ToscaWidgets
Mark Ramm wrote: I noticed that a recent change in tg.controllers does 2 things: 1) it allows you to set your toscawidgets to adapt to mako or genshi on a per request basis 2) it makes a hard dependency on TW in tg. It was a goal to have the actuall turbogears2 package have as small a dependency set as possible, but I think this feature is pretty valuable. So I'm predisposed to keep it, but I think it should be a conscious decision by the community so what do you all think? -1. The use-case it simplifies is pretty unusual (having page templates written in different languages and use TW in all of them) to warrant a hard-dependency on TW. Why not implement it as a helper decorator so the dep. can be avoided? Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: ToscaWidgets
Mark Ramm wrote: if tg.config.use_toscawidgets: import tw tw.framework.default_view = tg.config.tw.framework.default_view Makes sense, though you only want to do the import once, not on each request. ;) It's safe to do that on every request since that attribute is a descriptor that stores the value you set in thread-local storage. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2/Rum demo app available online
Lukasz Szybalski wrote: So is this line the only thing that needed to be added? from tgrum import RumAlchemyController admin = RumAlchemyController(model, is_manager, template_path=config['paths']['templates'][0]) Almost, *please* read the docs I linked to before posting questions which can be easily answered by yourself after reading them: http://docs.python-rum.org/tip/user/deploy.html#running-rum-inside-turbogears-2 If you could tell me a brief summary of which files have changed from the default quick started template that would be great! This is part of your homework ;) Anyway, just root.py, as the docs I posted above mention. For example tgrum ? Where is that coming from? , etc Ok, this one is a legitimate question I guess since none of the packages have been released yet (I was planning to do so today but I got side-tracked..). If you're in a hurry then you should install the development versions from hg.python-rum.org, else wait until they're released (I'll announce it here when that happens) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 needs a better helper to mount WSGI apps
Mark Ramm wrote: Of course it would also be possible to do 1 and 2 inside of the use_wsgi_app function, and I thought I added a ticket to make that happen, but I can't find it now. Hmm, not really I believe... Take close look at the code I posted. The default() method needs to see what arguments were passed as positional args to calculate how many elements it needs to pop from PATH_INFO into SCRIPT_NAME. Unless TG stores this info somewhere in the request object there's no way to get it from inside use_wsgi_app One use case of use_wsgi_app was that's not covered by the above example is that we wanted it to be simple to just return the response OR for the controller to monkey with the response on the way out. Hmm, subclass and override default? Anyway, I've made it more explicit b adding a delegate method and documenting in its docstring thta you can use it for that purpose But, I like the idea of a mounting a wsgi application more directly than use_wsgi_app allows... Ok, you got it at http://trac.turbogears.org/changeset/6035 I've also implemented a TracController so you can easily (perhaps too easily) mount a Trac instance inside a TG2 app: class RootController(BaseController): trac = TracController(some_predicate, env_path='/path/o/your/trac') Try it out, it's cool :) BTW, authentication info is passed to Trac to of course.. and I took cae of the edge cases I banged my head agains with when doing something similar in tw.org (making the request body seekable, rewinding it before delegating to Trac, translating the HTTPExceptions Trac raises into proper WSGI responses, etc...) The only caveat is that it probably doesn't belong inside tg.controllers... but I do think that TG2 should bundle a bunch of helpers like this inside since it they're so short and don't need to pull dependencies (since you can do the imports inside __init__ and configire the app there). They also make great marketing material ;) So, should add some more of these in a separate module? For example, one for Rum? ;) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 needs a better helper to mount WSGI apps
percious wrote: How about WSGIAppController, and you pass in a wsgi app to the __init__? Err, yeah, that's exactly what the example I linked to does... ;) (rum_app *is* a WSGI app) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 needs a better helper to mount WSGI apps
Dean Landolt wrote: The only caveat is that it probably doesn't belong inside tg.controllers... but I do think that TG2 should bundle a bunch of helpers like this inside since it they're so short and don't need to pull dependencies (since you can do the imports inside __init__ and configire the app there). They also make great marketing material ;) So, should add some more of these in a separate module? For example, one for Rum? ;) That would be /fantastic /marketing. We've finally decided (on IRC) to put these helpers in separate eggs or recipes. The TracController I mentioned has been moved to the TG docs [1]. Rum will have a helper in the TgRum [2] package (which will be released this Monday, along with Rum 0.2) Alberto [1] http://trac.turbogears.org/browser/docs/2.0/docs/project_code/trac_controller.py [2] http://hg.python-rum.org/TgRum --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 needs a better helper to mount WSGI apps
For those not following IRC, Jorge and I have created a tgext package to dump all these nifty utilities in, TracController now lives here: http://toscawidgets.org/hg/tgext.wsgiapps Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Changes to quickstart template auth model
Hi,
I'd like to make some trivial changes to the quickstart template's auth
model.
1) Add __unicode__ methods to the model objects so they're displayed
nicely in GUIs
2) Fix a typo in the password synonym, the name should be '_password'
reflecting that it is a synonym of the _password ColumnProperty
3) Add a couple of info arguments to some columns so Rum can introspect
them out of the box. These look like this:
info = {'rum':{'field':'Foo'}}
They create no dependency on Rum at all (they're strings) and a comment
will clear their meaning to the users.
If no one objects I'll commit the changes later today...
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to
turbogears-trunk+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] TG2/Rum demo app available online
Hi, I've just put a sample quickstarted app with rum inside at: http://tgdemo.python-rum.org/admin/ Login as manager:managepass (and don't delete the manager user or change his password! ;) How to do this in your own app? Stay tuned to the upcoming docs... Enjoy, Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] TG2 needs a better helper to mount WSGI apps
The current solution (ie: use_wsgi_app) does not quite cut it. The problem is that to effectively mount a WSGI app inside a TG app two things must be done beofre delegating the request: 1) Pop a number of path elements from PATH_INFO into SCRIPT_NAME. This is needed so the inner app knows where it's mounted at and can generate urls, etc.. 2) Copy the environ before doing 1. This is because if the inner app returns an error status code that TG's middleware is configured to trap, the static links in the error page TG/Pylons generates won't be built properly since the SCRIPT_NAME is the one that has been updated for the inner app. So, I propose a solution like this one: http://hg.python-rum.org/TgRum/file/73c6d8a87fb2/tgrum.py#l12 Sounds good? Can I move that code, with a better name (ideas please, else I'll leave it as RumController.. ;), to somewhere inside TG2? Where? Where in the docs can I mention it? Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] TG2 shouldn't trap 400 (Invalid Request) error reponses by default.
... or at least allow for easy customization (ie: no need to subclass and override add_middleware()) in configuration.py... The reason is that it is possible that an embedded app uses this status code, legitimally, to signal validation errors (eg: Rum). This has been discussed before, although no fix has been applied to TG yet: http://groups.google.com/group/pylons-discuss/browse_thread/thread/acd72479217cf017 http://groups.google.com/group/rum-discuss/browse_thread/thread/a095a92c83472144 If get no red light I'll commit a fix later today or tomorrow... Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Why is tg2 using easy_install -i ?
Mark Ramm wrote: This is a crude way of implementing the freezed-set of EggBasket if you prefer :) http://www.chrisarndt.de/projects/eggbasket/ Agreed, the way we're doing this now is not the critical issue, and we're generating static interfaces just for speed, and easy-deployment now. EggBasket is probably the right way to go in the future, but installing will still come from a custom index, not pypi, so the client interface will not change. ;) I must admit I don't like the use of private indexes for packages that are intended for public distribution, mainly because it's much nicer to say: easy_install Foo than: easy_install -i http://some_url_i_always_need_to_look_up Foo I understand the rationale behind it and I always use private indexes for *private* deployments in order to get repeatable builds, but I don't think it is a good solution for anything you plan to distribute publicly: PyPI is the canonical place for that IMHO. Besides that, maintaining a private index is not fun :) (you have to manually keep it updated as the dependencies are upgraded, unless there's a buildbot doing it for you...) This is how I'm planning to handle distribution and dependency issues with in python-rum.org: - All eggs (Rum, tw.rum, RumAlchemy, etc...) list their dependencies with the minimum version guaranteed to work (and maximum if necessary, it isn't yet). - A buildbot [1] builds everything in a clean virtualenv every day (and on every push) pulling dependencies from PyPI. This is to simulate what a user downloading Rum would experiment in their system. If any new version of a a dependency is released the dependent package can be either fixed if possible or the metadata updated with an upper bound on the required version and a new minor release made ASAP. This step should be improved by fetching from the respective trunks in order to get an early warning. - Packages not available at PyPI are distributed from a private index and a dependency_link is added to setup.py to a page where *only* that dependency can be downloaded (eg: [2]). This is to avoid creating havoc all around with custom versions of other packages (as I once did by mistake with tw.org/download) - If Rum ever pins an old version of a dep. which ceases to be distributed at PyPI no problem: the buildbot barfs and we manually create a package and distribute it at pypi.python.rum.org/custom Alberto [1] http://buildbot.python-rum.org/waterfall [2] http://pypi.python-rum.org/custom/index/EggTranslations/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: BuildBot system needs slaves
Florent Aide wrote: On Thu, Jan 8, 2009 at 5:38 PM, Steven Mohr opensou...@stevenmohr.de wrote: I will post updates on this topic regularly and hope that the BuildBot system will become a useful part of the TG infrastructure. You bet on it :) I'm sure Alberto will be more than interested by this subject... Are you in the need of another boring Ubuntu 8.04 i386 slave? Unfortunately I haven't got any other fancy hardware/os with a decent net connection I can contribute to the TG pool. In the hand-labor department there's not much I can offer either: TW badly needs a buildbot too (since the human maintainer is such a disaster) so I must administrate well my scarce infrastructure-building-energies ATM. ;) The offer for the ubuntu slave still stands. Let me know and I'll open an account for you. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: bug in require
Chen Houwu wrote:
I have tried the fix, bug the bug still exists, here is the trace
message:
-
⇝ UnicodeEncodeError: 'ascii' codec can't encode characters in
position 0-3: ordinal not in range(128)
(.)
logger and logger.info('Authorization denied: %s' % str(exc))
UnicodeEncodeError: 'ascii' codec can't encode characters in position
0-3: ordinal not in range(128)
---
It seems that the logging module is not too unicode friendly... a fix
could be to relax the encoder's error handler:
print (uAviñón).encode('ascii', 'replace')
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to
turbogears+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~--~~~~--~~--~--~---
[TurboGears] Re: Using tg.g in TG2
Aigarius wrote: On Jan 2, 9:31 pm, Alberto Valverde albe...@toscat.net wrote: Jason wrote: Just so you don't think you alone I too would love to see an example of this pylons.g can only be accessed when a request is going on or from the shell paster shell gives you. Well, could you give an example on how to set a value in app_globals.py and then access that value in a controller? Sure. app_globals.Globals is instantiated once per-process when your application is loaded. You can add app-specific global variables in its __init__ method: from somewehere import MyGlobalService from pylons import config class Globals(object): def __init__(self): self.my_global_service = MyGlobalService(config['myglobalservice.parameter']) Note that wen Globals is initialized pylons.config is already populated so you can import it and access it to fetch configuration variables. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Using tg.g in TG2
Aigarius wrote: On Dec 31 2008, 8:57 am, Aigarius aigar...@gmail.com wrote: Hi all, I cann't find a working example on how to use lib/app_globals.py to provide global variables to the application. I tried setting variables in the __init__() or just adding them to the class, but when I try to access them in the controller, I cann't get any values back. I assumed the following would work: lib/app_globals.py: class Globals(object): def __init__(self): self.key = 1234 key = 1234 controllers/root.py: from tg import g print g.key I am not sure what I did wrong, but the above actually does work (assuming that the 'print g.key' is inside a method of a controller). Oops, I didn't read your post carefully enough to notice that you had already tried what I just posted... What does not work is dir(g) to find what keys exist or not. g is actually a proxy to the Globals instance that the application which is currently serving the request has initialized. This is to allow several TG/Pylons aps to live in the same process (eg: to split your app in several functional components which can be used stand-alone if you need to). You can use the undocumented internal API to grab a reference to the real object that is being proxied, dir() should work for that: cur_obj = g._current_obj() print dir(cur_obj) Keep in mind however that, being a private API, there's no guarantee this will work in futures so you'll have to dig up paste.registry.StackedObjectProxy's source to fix it when (if) this happens... Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
Re: [rum-discuss] Re: [TurboGears] Re: Data interfaces
Mark Ramm wrote: Sorry Ablerto, I think that post came out of left field for you, and I didn't express myself very well. I don't want to denigrate rum in any way. I've used it in apps at work already and love it. What I wanted in the TG2 release was a form generation library. Ultimately I also wanted an admin interface too, but a newforms competitor was at the top of my list for this release. As chirs mentions we both tried to make rum work as a form generation tool, but it was somewhat difficult, (all the rum form generation stuff required lots of request context stuff to be setup and torn down). Rum has lots of potential, but it's a mini-framework that creates a wsgi app, and not a library of form generation tools. And that design decision makes tighter integration with a TurboGears app harder. Of course it's easy to mount a RUM app in TG2, and we will always support and document that. But in my mind integration of admin stuff that can compete with the new django admin requires a bit more flexibility in embedding forms and whatnot in pages with content generated by the main app. Sprox provides both, but what I really care about in terms of shipping with TG2 is the form generation library stuff. So, you're right. Rum is not a form generation library. And that's why we're including sprox. Sprox also happens to implement an admin generator thing, but on that front Rum is still ahead of Sprox. And that's definitely not why I agreed to let chris put sprox in the index. It's possible that Rum could be refactored a bit so that the form generation stuff was exposed more cleanly. But I wasn't up to the task with the other stuff on my plate. And, even then I'd like to support jython/ironpython with all the stuff in the TG core, and that will be difficult while using peak-rules because they have different byte-code systems, and ByteCodeAssembler would have to be modified to help them, and that's a task that's definitely over my head. Fair enough. I more or less (more more than less) agree with all your points and see the motivation behind them. As I've said in this same thread (in rum-discuss), Rum isn't really in the business of automatic form generation and I would have gladly outsourced this part of it if there was a *model-based* (vs. table-based which is what DBsprockets was at the time Rum was being coded) and TW based alternative I could re-use, but there wasn't. Fortunately there's now an alternative and I will surely evaluate if Rum can reuse this component to shrink its code-base and support costs. However, my main gripe and, in retrospect, the reason for my overreaction, is that these good points you've made weren't discussed publicly before. If this is what the TG lead has privately decided I'll go with it. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Turbogears 2 SQLAlachemy execute()
Jason wrote: Mark, Thanks for the reply, when I do the mark_changed I now get this error Module zope.sqlalchemy.datamanager:167 in mark_changed view assert _SESSION_STATE[id(session)] is not STATUS_READONLY KeyError: 27286544 Try passing the thread-local session instance instead of the session factory: mark_changed(DBsession()) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Using tg.g in TG2
Jason wrote: Just so you don't think you alone I too would love to see an example of this pylons.g can only be accessed when a request is going on or from the shell paster shell gives you. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Data interfaces
Mark Ramm wrote: Catwalk2 is a part of sprox, which is the successor to DBSprockets, so three of your four options are really all one thing. ;) That leaves a choice between Rum and Sprox. I would use Sprox at the moment, I would use Rum :) because it seems to have developer momentum, Rum is more mature, is better designed (Sprox admittedly has borrowed some conceptual ideas from Rum ;) and has more active developers. and is definitely easier to use/debug than Rum. Definitely easier to use/debug, in what way? These kind of blanket statements with no further explanation smell like FUD to me. The 2.0b1 release of TG2 includes sprox by default because it has a cleaner interface with TG2 than Rum, Cleaner than WSGI? Perhaps the I've made a bad job explaining what Rum is [1]. (it's not an auto-form generation library! although it implements one) BTW, could anyone please post a link to the thread the decision of including a 9 day old project in a beta release of TG has been openly discussed? so that's another reason to use Sprox. Stay tuned... before mid February the scheduke of my day job's main project will have me back coding on Rum whether I'd like it or not... and there's a whole dojo-based rich client reason I left undone this summer ;) Now seriously. I think it's a pity that the scarce human resources TG has are being diverted in almost parallel directions, but something good will surely come out of the competition :) Alberto [1] http://toscawidgets.org/documentation/rum/#introduction --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: init_model changes in tg2 template
percious wrote: So, I did some experimentation tonight using the engine as an identifier. The problem is that I have no way of knowing which class is mapped to which engine without binding them. Maybe I'm missing something here... from sqlalchemy import orm mapper = orm.class_mapper(MyClass) # introspect the mapper... This is how RumAlchemy gets information about a mapped class' properties: http://toscawidgets.org/hg/RumAlchemy/file/tip/rumalchemy/util.py IIRC, you don't *need* a connection to a database (engine) to introspect the mapper. For CRUD operations you just need a reference to DBSession so you can create Query objects from a mapped class. You can safely assume that DBSession has already been bound to an engine somehow I guess. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: init_model changes in tg2 template
On Dec 19, 2008, at 15:36, percious ch...@percious.com wrote: Yes, and I am doing that. The problem becomes when you have two models that have the same named classes. How is that? AFAIK, as long as they're declared in different modules, two classes with the same name are different objects altogether. I check to make sure the mapper points to the proper metadata before returning the class. Question: why is it ok to bind the DBSession, and not the metadata? This seems contradictory in my mind. As Mark has pointed out in this thread, the session is thread-local (ie: can be configured dynamically on a per-request basis which can be very useful in some situations) while the metadata has a module scope (process scope) which makes some advanced use-cases impossible. In case anyone is wondering, DBSprockets need the ability to query the database so it can fill in the proper data for the drop-down menus, as well as to fill in table data. Can't it query it with the good old DBSession.query(SomeClass) ? Alberto cheers. -chris On Dec 19, 1:29 am, Alberto Valverde albe...@toscat.net wrote: percious wrote: So, I did some experimentation tonight using the engine as an identifier. The problem is that I have no way of knowing which class is mapped to which engine without binding them. Maybe I'm missing something here... from sqlalchemy import orm mapper = orm.class_mapper(MyClass) # introspect the mapper... This is how RumAlchemy gets information about a mapped class' properties:http://toscawidgets.org/hg/RumAlchemy/file/tip/rumalchemy/util.py IIRC, you don't *need* a connection to a database (engine) to introspect the mapper. For CRUD operations you just need a reference to DBSession so you can create Query objects from a mapped class. You can safely assume that DBSession has already been bound to an engine somehow I guess. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: How to write the @require decorator?
Hi GUstavo, Gustavo Narea wrote: Hello, everybody. I've tried to implement the @require decorator into TG with this code: http://paste.turbogears.org/paste/13386 However, that HTTPUnauthorized exception is not handled neither by TurboGears nor repoze.who and I'm sure it's because I'm missing something -- but what? IIRC, webob.exc.HTTPException (which HTTPUnauthorized inherits from) was converted into a response with the appropiate status code by PylonsController, let me see... here: http://pylonshq.com/project/pylonshq/browser/pylons/controllers/core.py#L94 So I believe that you/repoze.who/someone should not be trying to catch an exception but check the response's status code to see if it's a 401 and in that case tell repoze.who to perform authentication. This is how I do it in twWebSite in case it serves you: http://toscawidgets.org/trac/twWebSite/browser/twwebsite/lib/auth_middleware.py#L45 As you can see, what that code does is make an internal redirect to the siging url when it sees that the response has a 401 status code. I'm using webob for API niceness but it should be doable in plain WSGI to make it framework neutral... Perhaps repoze.who already does something similar? Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 - tg.url, or pylons url_for, tg.vars, turbogears.view.variable_provider
Mark Ramm wrote: - TG1 uses it - people will look for it. - it is evaluated on a per-request-base AFAIK, which makes creating data dependent on the current request possible. - no extra namespace needed. Might be just a matter of convenience - but in the end, that's what we are here for :) Could we maybe write this as a endware that would be added to the wsgi stack and would then receive the same params as any other wsgi middleware? Please note that I am all for the functionality you are talking about, and am just trying to feed a technical discussion in this mailing list to see if other people out there would be interested to give some input... hint, hint, hint... I think we should support it the variable providers thing, though I think that we may want to think about our options here. I'm not sure about the middleware idea, because what we're doing is just providing shortcuts to the template, which happens at the TG core layer. I think sticking a callable on app_globals, which we poll in the template variables setup phase to get a dictionary to throw in the template would work, and would be pretty similar to what we had in tg1. Moving rendering out into middleware would allow us to do the template namespace updating in middleware too, but that seems strange to me because the TG2 wsgi app (the core app) needs to return a list of strings, and I'm not sure what that list would include if the rendering happens elsewhere. I don't think this belongs in WSGI middleware since it will just complicate things for no good reason, perhaps if the rendering middleware was meant for reuse outside of TG it would make some sense but not if it is a TG only thing. The TG1 variable providers could be implemented I think with a list of callables at app_globals and a wrapper around render() that updated the extra_vars dict like it's done in TG1, something like: def render(template, extra_vars=None, ...): if extra_vars is not None: for f in g.variable_providers: f(extra_vars) return old_render(template, extra_vars, ...) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: DBSession.commit() replacement
Ján ONDREJ (SAL) wrote: On Nov 10, 1:55 pm, Alberto Valverde [EMAIL PROTECTED] wrote: Ján ONDREJ (SAL) wrote: You could perhaps try to commit the transaction manually in your controller and handling yourself any exception that occurs: try: transaction.commit() except StandardError, e: handle_exception(e) Thank you, but does not work too: UnboundExecutionError: Instance User at 0x965fb2c is not bound to a Session; attribute refresh operation cannot proceed Next example? :-) try: DBSession.flush() # --- transaction.commit() except StandardError, e: handle_exception(e) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: DBSession.commit() replacement
Ján ONDREJ (SAL) wrote: Hi, Because it is needed by repoze.tm middleware that manages the transactions for you. The bottomline is that you *shouldn't* need (or even further aren't allowed) to begin and commit/rollback transactions manually. This works for me without a hitch. Maybe you need to adjust the setup of the DBSession to match whatever the current TG2 is doing (under the assumption that your app has been developed over the course of a few TG2-subreleases/trunk-versions) Hmm, ok. May be me english is not good enough. Can somebody give me an example, how to handle database errors (like unique key exceptions or foreign key problems) in current TG2? I have one project in TG1, which has been updated to run under TG2. I like news in TG2, but I really need to handle SQL problems some nice way and don't raise standard error without any description, which is default in TG. You could perhaps try to commit the transaction manually in your controller and handling yourself any exception that occurs: try: transaction.commit() except StandardError, e: handle_exception(e) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: DBSession.commit() replacement
Ján ONDREJ (SAL) wrote: On Nov 10, 1:49 pm, Diez B. Roggisch [EMAIL PROTECTED] wrote: On Monday 10 November 2008 12:00:29 Ján ONDREJ (SAL) wrote: Can somebody give me an example, how to handle database errors (like unique key exceptions or foreign key problems) in current TG2? I have one project in TG1, which has been updated to run under TG2. I like news in TG2, but I really need to handle SQL problems some nice way and don't raise standard error without any description, which is default in TG. I didn't read that out of your last email, but re-reading them now makes things clearer for me. I've hit by that myself - unfortunately, this is actually a limitation of SQLAlchemy. I don't agree. It is not a problem of SQLAlchemy, but it's a problem of current version of TurboGears. My application is working well on TurboGears 1.0.7 and worked also on some TurboGears (I think an alfa, but I am not sure which). Just it's not working with TurboGears2-1.9.7b1, when ZopeTransactionExtension is ON. Note that ZTE is not mandatory. You can remove it from your DBSession and handle transactions manually as you were doing before. I'd recommend however to try to use the zope transacion API to handle them (as I suggested earlier in this thread) since some TG extensions in the future might rely on it (eg: to take advantage of its two-phase-commit semantics when dealing several data backends, say a ldap store, filesystem) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Auth in the quickstart
Gustavo Narea wrote: On Thursday October 30, 2008 05:42:58 Mark Ramm wrote: I do think it would be interesting and useful to be able to provide some helpers that make it very easy to write authorization rules that do row-level (really SA object level) authorization checks in the controller. I was planning to implement something along these lines for Rum and began working in it in RumSecurity [1] which is an authorization library which uses generic functions that users can extend to implement whatever policy. This is based on PEAK-security. I began writting it before Gustavo began working on his authz library and there's probably a big overlap so I might/probably ditch RumSecurity and study how to extend his better documented library to do what I need... anyway, maybe you can consider using generic functions to allow users to extend authorization rules in a very flexible and powerful way. You don't even need to depend on PEAK-Rules at all since it can extend any existing function (don't need to declare it as generic before using it). Only think about this use-case and design a function with a signature that allows for extension, for example take a look at the Policy.has_permission() function in [2]. Also, a way to bind permissions (metadata) to objects/actions is needed too... RumSecurity does this with Policy.permission_for() using a technique stolen from peak.metadata. Anyway, I still haven't looked at Gustavo's code in much detail so it might already be implemented in a way that allows for extension in this way, in that case just ignore what I said :) Alberto [1] http://toscawidgets.org/hg/RumSecurity [2] http://toscawidgets.org/hg/RumSecurity/file/tip/rumsecurity/policy.py --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: November Sprint Worldwide, and at PyWorks, Atlanta, GA Nov 15-16
percious wrote: I added a November Participants section. ... and I've added myself to the Madrid section. :) Hey Gustavo, perhaps we could meet somewhere to sprint together? So we can balance the sprint's North American center of gravity... ;) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: A few quick development questions from TG2 (1.9.7a4)
i18n appears to work from the .py files, but, I am not able to translate pages even though extract_messages does properly find them in the templates. Known broken, possibly broken, or, am I doing something wrong? If there's a bug, and it's certainly possible, it's not yet known. If you can provide a reliably broken test case, we'll fix it right away. If you can explain how to get the problem, that would help too. Perhaps the genshi.filters.Translator is not added to the templates when loaded? http://genshi.edgewall.org/wiki/Documentation/0.4.x/i18n.html#translation I would add a switch to enable this on demand since it'll probably add a noticeable overhead which can be avoided if no i18n is needed. Using the caching decorator doesn't seem to work. Using beaker.cache appears to not work even when specifying the key and writing the object. Known broken, possibly broken, or am I doing something wrong? Possibly broken, but I did test this recently on a project of mine, and it worked fine, so some details would help me know more. Secure Controller. Documentation appears to suggest that it should work, but, I am only able to get the decorators to work. While the decorator does work, the prompts are a bit vague. However, I am unable to protect a controller. There was mention in the turbogears list that Secure Controller was incomplete. Is there an ETA? Silverplate had some promise, but, I would prefer to use tgreposewho or the method that is most suggested by TurboGears. SecureController works except that unauthenticated access to the index method throws the wrong kind of HTTP error, and you are not redirected to the login page properly. The decorators are designed to work on exposed methods, but not on controllers. Silverplate is just a user-registration module for tgrepozewho users, and is not intended as a replacement. There is some refactoring work, and some other auth related work going on this week, and I expect to see the SecureController fixed real soon now. SQLAlchemy with ToscaWidgets Dropdown boxes seem to excessively cache. Using the example from the ToscaWidgets to create the genre dropdown box pasted into a sample app results in adding a record, and the refresh of that page not seeing the new genre until paster is stopped and restarted. Known bug, possibly broken, am I doing something wrong? Both Genshi and Mako display this behavior. This is probably something you are doing wrong, if you set default values for the widget at instantiation time, those will always be used. Either pass in a callable that returns the right values, or only set the values when the widget is rendered. Yep, this is right. You need to pass a callable as the 'options' parameter to the SingleSelectField if you want them to be updated on every request. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Little tweak needed in your apps if you upgrade to TG2 trunk
I'm having the same issue, I'll provide more debug info if needed, all I did was install via setuptools in a virtual environment with the 4th prerelease... It seems this is not a TG issue since it has been reported a couple of weeks ago in the dbsprockets list by someone using the sprockets on Pylons: http://groups.google.com/group/dbsprockets/browse_thread/thread/1fc3f32e2f97b2b0?hl=en Perhaps a ticket at dbsprockets tracker with as much debugging info as possible would help move things forward. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Mercurial for TG2 discussion
Hi, Sorry for being late to the party, I was on vacations. I'd also like seeing TG2 switching to mercurial. Most of the pro arguments have been already mentioned in this thread but I'll briefly repeat those that I find most valuable: - Being able to work offline. I know most of us have a good internet connection most of the time but the fact that it allows offline use makes many operations *way* faster (update to prev. revision, branch, view the log, see diffs, etc...). Besides that, I find it very productive to take my laptop to a net-free zone (trains are the best!) and get work done, for a change :) - Non-commiters can work on *complex* changes and then post a bundle for review in the trac. Better still, if twWebSite is leveraged, any registered user can create a repo/branch in tg.org to act as a central repository to collaborate with others or just plainly let everyone see what they're up to. These branches are then very easy to merge, usually just a hg -u pull someurl away. If conflicts occur kdiff (or your favorite merge tool) is spawned automatically to make conflict resoultion a breeze. - Makes sprints easier to organize for the reason above. - hgweb can create tarballs on the fly (on-demand snapshots) from any tag, revision or the tip. This is what http://toscawidgets.org/download uses to provide dev snapshots to easy_install. Without any external tool (save a short script to generates these links) - if twWebSite is leveraged (the code that powers tw.org) tracs and repositories can be easily created by registered (or specially authorized) users for related projects (eg: tgext.repoze.who, tg.authorization, tg.devtools, ...). This fits very well with TG2's philosophy of splitting up into smaller, independently maintained, components. I know SVN can be used for this as well but twWebsite is already written and I didn't hear anyone volunteer to write the SVN counterpart (let alone share some code ;) - patch queues could be a lifesaver for those in the absolute need of working-with/deploying a patched version of TG2. - From a personal philosophical POV: de-centralized better than centralized: p2p, internet, federalism vs. new-world-order... ;) To sum up, Most of the disadvantages pointed out in this thread refer to social problems rather than technical and will need to be sorted out using social means (how to handle multiple branches, where to pull release from, etc...) but the point is that Hg (or any distributed VCS) allows that freedom while centralized VCS don't, in fact, one can follow a pretty much centralized work-flow while using a DVCS (see the current usage of tw.org as an example) while pseudo-DVCS behavior using SVN is kludgy (to say the least ;) So, if this goes forward, what are the time-frames for the migration? I need to polish up twWebSite quite a bit before it can be easily reused in other sites. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: How can I invalidate a form?
Gustavo Narea wrote:
Hello,
I have a widget which already has its relevant validators, but in my
controller I'd like to invalidate it if it's trying to add an existing record.
The following code snipped partially works and seems like an ugly solution to
me:
@expose('animador.web.templates.websites.admin.add')
def add(self, **kwargs):
if pylons.tmpl_context.form_errors:
flash(_(Please correct the form))
pylons.c.add_site_form = widgets.AddWebsiteForm(add_site,
action=add_website)
return dict()
@expose('animador.web.templates.websites.admin.add')
@validate(form=widgets.AddWebsiteForm(), error_handler=add)
def add_website(self, website_alias):
if Website.query().get(website_alias):
error_msg = _(u'The web site alias %s is already in use') % \
website_alias
pylons.tmpl_context.form_errors['website_alias'] = error_msg
return self.add()
new_site = Website()
new_site.website_alias = website_alias
new_site.created = datetime.now()
DBSession.save(new_site)
DBSession.commit()
flash(_('The %s web site has been added!') % website_alias)
return dict()
I want add_website() to reject existing websites, which is done with the code
above, but the error message I inserted in pylons.tmpl_context.form_errors is
not displayed (not even if I redirect() to the add() action, instead of
returning a call to it).
You need to pass the form_errors to the form explicitly if you want to
build them yourself:
${form.display(, error=c.form_errors or None)}
How can I do this the right way?
I would check if the website alias is unique in a custom validator
(inside the validate_python method) for the website alias filed, not the
controller. This way the error will be displayed beside the website
alias field and the validate decorator can take care of everything.
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[TurboGears] Re: turbo gear 2 tests
kalin m wrote: the changes take place only after killing and restarting the local application server. i thought that the changes are active immeditely. there is no mentioning about restarting the server application to view the changes. in the wiki video the fact that the changes are taking place immediately is underscored as a tg advantage. on the page: http://www.turbogears.org/2.0/docs/main/Wiki20/wiki20.html it shows the usage of paster command to start the application server with --reload development.ini on mine i get: $ paster serve --relaod development.ini Usage: /path/tg2env/bin/paster serve [options] CONFIG_FILE [start|stop|restart|status] [var=value] Serve the described application /path//tg2env/bin/paster serve: error: no such option: --relaod and paster -h doesn't include --reload either --reload (not --relaod!) is an option of the serve subcommand: $ paster serve -h Options: -h, --helpshow this help message and exit -v, --verbose -q, --quiet -n NAME, --app-name=NAME Load the named application (default main) -s SERVER_TYPE, --server=SERVER_TYPE Use the named server. --server-name=SECTION_NAME Use the named server as defined in the configuration file (default: main) --daemon Run in daemon (background) mode --pid-file=FILENAME Save PID to file (default to paster.pid if running in daemon mode) --log-file=LOG_FILE Save output to the given log file (redirects stdout) --reload Use auto-restart file monitor --reload-interval=RELOAD_INTERVAL Seconds between checking files (low number can cause significant CPU usage) --monitor-restart Auto-restart server if it dies --status Show the status of the (presumably daemonized) server --user=USERNAME Set the user (usually only possible when run as root) --group=GROUP Set the group (usually only possible when run as root) --stop-daemon Stop a daemonized server (given a PID file, or default paster.pid file) This should work: $ paster serve --reload development.ini (make sure you type it correctly ;) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: UnmappedInstanceError in tg2
Lukasz Szybalski wrote: Hello, I am trying to follow: http://turbogears.org/2.0/docs/main/ToscaWidgets/forms.html ps. you have a typo from toscawidgets.api import WidgetsList should be from tw.api import WidgetsList but I get the following error: UnmappedInstanceError: Class '__builtin__.type' is not mapped; was a class (addressbook.model.address.Addressbook) supplied where an instance was required? Any idea how to solve this? I am importing my address.py in __init__.py in the last line as follows: from addressbook.model.address import * and in my root.py I import module as: from addressbook.model import Addressbook You're missing some context needed to answer this question properly. From the little you give I assume you're passing a class as an option or value or something when you should be passing an instance (as SA is pointing out). Can you paste the a code snippet that shows how you're feeding your Addressbooks to the widget/form? Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboGears-1.5 and transactions
On Aug 24, 2008, at 5:07 PM, Florent Aide [EMAIL PROTECTED] wrote: On 8/22/08, iain duncan [EMAIL PROTECTED] wrote: install tg1transaction manager. I am wondering if we could not use remoze.tm in tg 1.5 since CP3 is wsgi compliant... This would make us even more close to tg2. +1 on that idea from a users perspective. Seems the most like putting the right tool in the right place. Ok, we all agree that using repoze.tm with CP3 would be the best :) I think that what Mark tried to say was that we should use 'transaction' but reimplement repoze.tm2 as a CP tool for performance. I'm +1 on any solution that uses transaction + zope.sqlalchemy since it's what tg2 is using already. Alberto Who volunteers to do the job then ? Florent. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: AmbigousMethod driving me crazy
On Aug 23, 2008, at 1:47 PM, Diez B. Roggisch [EMAIL PROTECTED] wrote:
Hi,
I just tried to upgrade an existing app to TG1.0.4.4, and my json.py
gives me errors like this:
==
ERROR: This test ensures that the SO object inheritance is respected
in
jsonification.
--
Traceback (most recent call last):
File
/Users/deets/projects/artnology/Van_Abbe_RMS/Van-Abbe-RMS/varms/
tests/test_model.py,
line 643, in test_json_so_works
json = jsonify(g)
File
/Users/deets/.virtualenvs/RMS/lib/python2.5/site-packages/
TurboJson-1.2-py2.5.egg/turbojson/jsonify.py,
line 22, in jsonify
@abstract()
File generated code, line 0, in jsonify
File build/bdist.macosx-10.3-fat/egg/peak/rules/core.py, line 214,
in __call__
raise self.__class__(*self.args+(args,kw)) # XXX
AmbiguousMethods: ([Method(function jsonify_sqlobject at 0x1a70270,
Signature([Test(Truth(Call(Const(function is_sqlobject at
0x1a70130),
(Local('obj'),), (), (), (), True)), Value(True, True)),
Test(Truth(Call(Const(built-in function hasattr), (Local('obj'),
Const('__json__')), (), (), (), True)), Value(True, False))]), 127,
None), Method(function jsonify_user at 0x1f7e970,
Test(IsInstance(Local('obj')), Class(class 'varms.model.Guide',
True)), 131, None)], (Guide 1 user_name=u'charles'
email_address=u'[EMAIL PROTECTED]' display_name=u'Charles'
password=u'Wafer-thin Mint' created='datetime.datetime...)',), {})
I read up on Rules dispatch, but so fare it eludes me what to do to
get
rid of that problem. Any suggestions heartly welcomed.
Turbojson 1.2 allows a 'prio' argument to the decorators you can use
to disambiguate in these situations. Take a look at the docs of
prioritized_methods in pypi for more info.
Alberto
Diez
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~--~~~~--~~--~--~---
[TurboGears] Re: AmbigousMethod driving me crazy
On Aug 23, 2008, at 8:54 PM, Christoph Zwerschke [EMAIL PROTECTED] wrote: Diez B. Roggisch schrieb: I wonder: how does rules detect that? Through an algebraic analysis? Yes, it analyzes the rules to check which one is more specific. @jsonify.modelobject(clazz) that would render the proper signature. Good idea. TurboJson could define the following decorator: def when_sqlobject(classinfo=None): if classinfo: cond = isinstance(classinfo, str) and classinfo or 'classinfo' cond = isinstance(obj, %s) and % cond else: cond = cond += is_sqlobject(obj) and not hasattr(obj, '__json__') return jsonify.when(cond) Works perfectly well for me. But I just see that Alberto and Jonathan already solved this problem for TurboJson 1.2 by using prioritized_methods (see discussion here: http://www.mail-archive.com/[EMAIL PROTECTED]/msg05140.html ). The idea here is letting the json.py rules always have higher priority than the rules that are defined by default. I think this makes sense. However, we cannot use prioritized_methods for TJ 1.2 since it does not work with RuleDispatch. But we could use something similar, turbogears.genericfunctions.MultiorderGenericFunction. The only problem is that I would not like to create the reverse depency of TJ from TG, and the order parameter is called order instead of prio, and works the other way round. So maybe we could integrate a modified MultiorderGenericFunction with a prio parameter into TJ 1.1. Then we would be fully compatible with TJ 1.2 in this regard. I Prioritized_methods is a port of the genericfunctions module TW had some time ago when it used ruledispatch (dig through the past revisions in TW's repo). You might want to use it as a backport since Multiorder in TG has different semantics than prio_meths. Alberto -- Christoph --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: AmbigousMethod driving me crazy
On Aug 24, 2008, at 12:13 AM, Christoph Zwerschke [EMAIL PROTECTED] wrote: Alberto Valverde schrieb: Prioritized_methods is a port of the genericfunctions module TW had some time ago when it used ruledispatch (dig through the past revisions in TW's repo). You might want to use it as a backport since Multiorder in TG has different semantics than prio_meths. Ok, found it. I'll try to include that with TJ 1.1, so it will be compatible with TG 1.2. Btw, what is the advantage over MultiorderGenericFunction? It looks much more complicated. Not that there is an advantage, they just work differently. I can't elaborate much ATM since im iPhone-bound till next week, will do when i have a real keyboard... Source speaks better now :) Alberto -- Christoph --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Feature Freeze extension
On Aug 18, 2008, at 9:35 AM, Florent Aide [EMAIL PROTECTED] wrote: On 8/14/08, Diez B. Roggisch [EMAIL PROTECTED] wrote: To be clear, I think it's something we should install by default, and document in the main turbogears docs, the question is just should it live in a separate package and have a (potentially) separate release schedule? +1 for the default Hm, dunno. It's *very* few lines of code so far, as it's not to fancy - it just uses the webhelpers.Page.pager-call to create a link-list. You find the current code below. I don't think that really suffices a separate package, unless we plan to have a general useful-things-package. tg.ext seems like a good candidate: tg.ext.paginate Not tg.ext please. Check the troubles with the tg.ext namespace thread a few days ago. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Feature Freeze extension
On Aug 18, 2008, at 12:19 PM, Florent Aide [EMAIL PROTECTED] wrote: On 8/18/08, Alberto Valverde [EMAIL PROTECTED] wrote: I don't think that really suffices a separate package, unless we plan to have a general useful-things-package. tg.ext seems like a good candidate: tg.ext.paginate Not tg.ext please. Check the troubles with the tg.ext namespace thread a few days ago. Seen that but the thread did not continue or I just missed it... We could always use tg.ext without namespacing it no ? Yes of course, but the code will need to live inside the turbogears2 distribution, not a separate one. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: GSoC update
percious wrote: I think the idea here is the same as was behind SessionConfig in dbsprockets. That is, there is a standard set of data you expect to retrieve for a given generated widget, be it a set of data to populate drop-downs, or a jsonified stream to populate an autocomplete field. If there is a way we can make this data retrievable and customizable, we will have a win. The plan is to query the repository or router for this information, so, for example, to initialize a drop down you'll do: @get_view.before(isinstance(attr, fields.Relation)) def _add_options_and_validator(self, resource, attr, action, args): if not attr.required: options = [None] else: options = [] v = validators.RelatedFetcher(attr.other) self.add_validator(v, args) def get_options(): return options + list(app.repositoryfactory(attr.other).select()) args['options'] = get_options This code is from tw.rum. I'll explain: @get_view.before registers the decorated function so it is executed before the main body of get_view is called when the attribute we're visiting is a Relation. get_view is the ViewFactory's method that returns a view *class* for an object or one of it's attributes. The pattern you're seeing is used a lot: a before action that modifies the args dict which is a dict of keyword arguments that will be used to initialize the view (a widget in this case). So the whole thing basically says: when the attribute is a relation, generate a list of options by querying the repository that handles the related model for all it's items and add a validator that will take care of converting the related object into and id (to display in the drop-down) and back (to get the object from the repo. once we get the id back). If we wanted a fancy ajax lookup field instead of a drop-down we'll have to tell it somehow where to fetch the items from... so instead of querying the repository we ask the router who is the one who knows best at what url endpoint each collection or member can be accessed from, example: args['url'] = app.url_for(attr.other, action='index', format='json') BTW, app is a rum.app which is a proxy (StackedObjectProxy) which points to the the active RumApp (ie: the one serving the current request or the one we've explicitly put in context, more on this later...) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: GSoC update
Nice application. I comment you any thoughts:
1. When is showed a table, the underscores ('_') are showed but when
is edited are not showed.
I'm sorry, I don't know what you're trying to say here...
I think that underscores (of fields names) should been converted
auto. to spaces.
Sure, it's just a quick and dirty demo :) The code to do it exists (inside
tw.forms for example) but I just haven't plugged it in yet.
2. What do you think about to display another name for fields (for
more verbosity)?
???
3. It looks that is possible only display any tables. Perfect! It also
would be very well if were possible display any rows.
You mean to show a member? Like http://rumdemo.toscawidgets.org/persons/1 ?
4. Does would be possible display tables of only read? At least for
any groups/roles. And also that any tables could be edited only by any
group/role.
Yes, this will be implemented too. You'll be able to register a model with
Rum and specify which methods it supports (eg: show and index if you want
read-only)
This will also apply to any model's property, so you can define a
read-only property on a model object which should only appear in index or
show or as a read-only label in forms. If you take a look at the demo code
you'll see I've implemented a 'is_overtime' property on 'Rental' which I
planned to use to demo this feature but I didn't have time to make it tick
before the demo.
One thing I want to make clear: That demo is just a quick and dirty demo,
I implemented the GUI just hours before announcing it because posting a
link to a trac where you can read dead code is much less pleasing to the
eye :)
I'm still working on the backend-side of Rum: trying to design a decent
api to declare model metadata, refactoring, etc... the work on the gui has
really not begun yet so don't assume anything about how it will finally
look like by what you saw in that demo.
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[TurboGears] Re: Turbo Gears or Django?
I would say that it depends on... 1) You're in a tight schedule to make a content-oriented, web- application where the domain model is relatively simple. Django is the best at the moment. Django Admin has not rival and is a real time saver we all secretly envy. 2) You want to invest your time in learning something that's not so mainstream, that the fanboys don't preach as much, but has not got inherent design limitations that will hold it back while the barbarians stampede past it when the gates fall down. Then go with TG2 or Pylons. If this means anything at all, I know many people who've ended up here after banging their head against Django. The phrase django magically creates 90% of all I need in 2 days! But then I spend 3 months fighting it to get the 10 remaining % done has become an informal clichè. Frankly, I don't know of any case of the opposite situation. Alberto, Who's paid to fight Django every-day on the legacy app he has to maintain at his day-job, secretly conspiring to build the tools he needs to replace it and don't look back ever again. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: [Repoze-dev] repoze.tm wishlist
Chris McDonough wrote: So, long story short, I've been afraid to release *either* repoze.tm or repoze.tm2 until I had the time to sort all that out. I'd still rather not release either to PyPI Fair enough. As long as there's somewhere we can tell pkg_resources to grab packages from so users can easy install TG we'll be fine. but I'll go ahead and create a release of repoze.tm2 in an index on dist.repoze.org (which will also contain the transaction package). Done. I release repoze.tm2 1.0a2 and created an index for it on dist.repoze.org: bin/easy_install -i http://dist.repoze.org/tm2/dev/simple repoze.tm2 That's all we need. Thanks! Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Importing model
laureano arcanio wrote:
Hy guys, I'm building a model for my os project and i want to make it
importable to an existing TG2 app. So far I've created this model in
python package, and I'm not sure how to define The medatata and
Session to pick the one defined in a tg2 app. To be able of just
import this model in the app model directory..
You don't need tg2's metadata, just the session, something like this:
# some_model.py
from sqlalchemy.orm import mapper # Use this mapper, not the one
associated to a scoped session
from sqlalchemy import
metadata = MetaData() # don't bind it to an engine either
foo = Table('foo', metadata, ...)
class Foo(object): pass
mapper(Foo, foo)
# then in tg2, when the config has been loaded
engine = engine_from_config(config)
Session = scopedsession(sessionmaker(bind=engine))
This session knows what database to talk to, you now use your models as
usual (forget about the query attribute since the mapper you're using is
not bound to any session automatically)
@expose(..)
def show_all_foos(self):
foos = DBSession.query(Foo).all()
Not having a query attribute in every model is not that bad, you just
have to do things a little bit differently, example:
class Foo(object):
def do_something_with_bar(self, bar):
session = sqlalchemy.orm.object_session(self) # if this Foo
instance was returned by a query from TG's DBSession, object_session
will return that session object
similar_bars = session.query(bar.__class__).filter(bar.foo ==
foo).all()
...
A class method is a little bit trickier since you can't get a ref. to
the session, you'll have to pass it as a parameter:
class Foo(object):
@classmethod
def all_broken_foos(cls, session):
return session.query(cls).filter(cls.broken==True)
Ahh, you also need to save your objects explicitly in the session since
they're not saved automatically by the scoped session's mapper.
Alternatively you can also define the scoped session in your model's
package, use the contextual mapper (to have the query attr. etc...), and
then use this session from tg2 instead of the one tg2 provides. You'll
need to take care of properly committing it, removing it after the
request is done, etc...
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: GSoC update
Felix Schwarz wrote: Thanks for your excellent explanation. As I may need something like dbsprockets/dbmechanic/rum in the near future, I'm interested in Elixir support. Does rum currently support Elixir? If not, any estimations when basic support is coming? Elixir should be usable already, pass the entities in a list as models to the repositoryfactory when initializing RumApp (like in the example) and pass elixir's session as 'session_factory'. I haven't really tested it, but it should work... And another very critical issue to me: Currently you use drop down menus to select referenced objects. I have an app with quite a few users ( 10,000) so I can't use drop down menus there. Any chance to select them by ID together with AJAX to get a label for this id? It's not implemented yet but it will be, all the infrastructure to support it is there but there's still many things to do before I get into any heavy client side coding, hopefully it'll be ready before gsoc ends. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: [Repoze-dev] repoze.tm wishlist
Hi Alberto, Thanks! I applied a slightly modified version of this patch: http://lists.repoze.org/pipermail/repoze-checkins/2008-July/001088.html The code can be checked out from http://svn.repoze.org/repoze.tm2/trunk/ . Awesome, thanks :) I'll remove my temporary implementation from rum and use repoze.tm2 now instead and tell you how it goes... Then I'll take ata sb at integrating it in turbogears2 (this is why I'm cross-posting to tg-trunk) BTW, where can I tell pkg_resources to pull repoze.tm2 as a distribution's requirement from? Are you planning to register it at PyPI like everyone else does? ;) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] GSoC update
Hi all, Today's midterm evaluation day so I cooked up a demo of the work I've done so far: http://rumdemo.toscawidgets.org/ Enjoy :) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: GSoC update
Felix Schwarz wrote: Alberto Valverde schrieb: Today's midterm evaluation day so I cooked up a demo of the work I've done so far: http://rumdemo.toscawidgets.org/ Sorry to ask these newbie-ish question here but what is the difference of your project to dbsmechanic/dbsprockets? The biggest difference is that I need Rum to support *model* objects (with inheritance, properties, etc...) instead of database tables. I found dbsprockets API too table-oriented to extend in the ways I need. Rum also makes heavy use of PEAK-Rules internally since I find it simplifies much the introspection we both need to do. Is there any overlap? Yes, they both handle CRUD operations but the internal abstractions are quite different. Can you share code? Sure, http://toscawidgets.org/hg/rum. Take all you want, it's free ;) Am I stupid and both projects do not have anything in common? The final goal is very similar (automate as much as possible the tedious CRUD interfaces we've written over and over again) but the implementation and abstractions it manages are quite different (better read the source). I believe Rum will be easier to extend to handle other data backends such as ZODB because it doesn't think in terms of tables but in terms of objects. Finally, I want Rum to be usable in TG2, Pylons etc... but not depend on them since I've bet my chances that I'll end up writing more code in the form of framework adapters than in the form of a very basic and very specifically tailored WSGI framework to provide the little services I need (BTW, this is all thanks to paste, webob, and the rest of pylons building blocks) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] GSoC update
Hi all, Today's midterm evaluation day so I cooked up a demo of the work I've done so far: http://rumdemo.toscawidgets.org/ Enjoy :) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: sending html mail
iain duncan wrote: what would be the best way to take a genshi template plus html content and get it rendered such that the css becomes inline? is there something else out there that does that? I have some code that does exactly this but it's ugly, undocumented and tightly coupled to my app. Contact me privately if you want me to send the relevant parts to you (privately) in case it can give you some ideas... it would be great if you could then share it publicly after it has been cleaned up to protect the innocent. ;) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Turbogears 2 slow?
[EMAIL PROTECTED] wrote: Hi, Is it slow only on the first occasion or on all occasions? When you run the app for the first time, all used python modules (i.e. your project modules, tg2 modules and all other dependencies) are compiled into byte code by the interpreter. Regards Sanjiv On Jul 13, 6:03 am, [EMAIL PROTECTED] wrote: Sorry if this has been asked and addressed elsewhere... I just got tg2 up and running and just hitting the welcome page takes a while. in tg1, it was almost instant. This is all being done from the same machine. Is this just development woes or is there something i need to do to pylons? i have literally one nothing extra to it, just installed and ran paster serve development.ini from defaults. PylonsApp (which TG2 uses internally) lazy imports the controller modules when they're first called so this could explain that the first request takes noticeably longer than subsequent requests. TG1 on the other hand loads all controllers on startup. Is this the case or are all requests served slower? If so I believe there could be something wrong in your setup because my experience is quite the opposite. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Christopher Arndt wrote: Alberto Valverde schrieb: Christopher Arndt wrote: Mercurial doesn't have to be installed to easy_install mercurial archives. These are created on the fly from the repository tip, Ok, I see. *zipped*, and served by hgweb. easy_install couldn't care less if the zip was dynamically generated or if is was a static file gathering dust in some hard drive platter ;) Take a look if you want to see for yourself at the links labeled download zip in http://toscawidgets.org/download. This URL is listed as download_url in pypi for prioritized_methods so easy_install looks there when it sees pypi has no 'dev' version registered there. I still don't like idea of TJ having a dependency on a development version of another project. Please make a release and require that. Ok, I've just released 0.2 to pypi [1] and updated turbojson's setup.py accordingly [2]. The only development version TJ still depends on is PEAK-Rules itself, I have no control over that package though. Alberto [1] http://pypi.python.org/pypi/prioritized_methods/0.2 [2] http://trac.turbogears.org/changeset/4920 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Just a FYI, I've released prioritized_methods at pypi: http://pypi.python.org/pypi/prioritized_methods/ Any interest around here in me getting my dirty hands on TurboJson to integrate it? Plan is: 1) Replace jsonify.around and jsonify.when with their prioritized_* counterparts but with their old name. 2) Add a prio=-1 argument when registering all implementations inside TJ so user extensions automatically override them if they create an ambiguous methods situation (if a builtin has a more specific rule it will still apply, of course) Changes should be 100% backwards compatible and Jonathan will be happy ;) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Jonathan LaCour wrote
Sure, but I still want to be able to turn them off, even if it
does break some future extension. The bottom line for me is that
I totally understand (and agree with) your arguments, but I still
think that there needs to be a mechanism for clearing out the
default rules to give the user complete control over them.
Just found out how you can do this:
from peak.rules import Dispatching, when
def f(n): pass
...
f(6)
when(f, n5)(lambda n: n)
function lambda at 0x862325c
f(6)
6
rule_set = Dispatching(f).rules
rule_set.rules
[Rule(function f at 0x862341c, (), None, 121), Rule(function lambda
at 0x862325c, Test(Comparison(Local('n')), Range((5, 1), (Max, 1))),
None, 122)]
rule_set.remove(rule_set.rules[1])
f(6)
I'm loving this PEAK-rules thing... :)
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Alberto Valverde wrote: Jonathan LaCour wrote Sure, but I still want to be able to turn them off, even if it does break some future extension. The bottom line for me is that I totally understand (and agree with) your arguments, but I still think that there needs to be a mechanism for clearing out the default rules to give the user complete control over them. Just found out how you can do this: (...) http://paste.turbogears.org/paste/3141 Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Jonathan LaCour wrote: Since I'm the squeaky wheel, I'll give this a shot today. I'll let you know how it goes :) Well, I tried, and failed :) Looks like there is a bug somewhere in prioritized_methods. When I replace the peak.rules `when` with the `prioritized_when`, all sorts of things go boom. Specifically, all of the default rules in TurboJSON raise exceptions about not being able to find imported modules. I can get a little further by replacing the `isinstance` checks with concrete type checking, but anything that passes a string-based rule that depends on something in the local namespace (imported modules like `datetime`, or helper functions like `is_saobject`), things blow up... Any ideas, Alberto? I think I've fixed this in a recent commit, update: easy_install -U prioritized_methods==dev and try again please. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Jonathan LaCour wrote: Since I'm the squeaky wheel, I'll give this a shot today. I'll let you know how it goes :) Well, I tried, and failed :) Looks like there is a bug somewhere in prioritized_methods. When I replace the peak.rules `when` with the `prioritized_when`, all sorts of things go boom. Specifically, all of the default rules in TurboJSON raise exceptions about not being able to find imported modules. I can get a little further by replacing the `isinstance` checks with concrete type checking, but anything that passes a string-based rule that depends on something in the local namespace (imported modules like `datetime`, or helper functions like `is_saobject`), things blow up... Any ideas, Alberto? I think I've fixed this in a recent commit, update: easy_install -U prioritized_methods==dev I've just created a turbojson branch and integrated prioritized_methods. with the pm's dev version all TJ tests pass untouched and a new one I've added passes too. http://svn.turbogears.org/projects/TurboJson/branches/prioritized/ If this works for you I'll release a fixed prioritized_methods to pypi and if no one objects I'll merge this TJ branch with the trunk too. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Alberto Valverde wrote: I think I've fixed this in a recent commit, update: easy_install -U prioritized_methods==dev and try again please. It works now. Patch for TurboJson trunk attached. Let me know if there is anything else you need. I'd love for this to be included in the upcoming preview release. Seems we got a mid-air collision :) I made an almost identical diff in the branch I mentioned + a test, if it's ok with you I'll leave the changes in the branch untouched since they're almost the same and they have a test, ok? Thanks, Alberto! no problem :) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Jonathan LaCour wrote: Alberto Valverde wrote: If this works for you I'll release a fixed prioritized_methods to pypi and if no one objects I'll merge this TJ branch with the trunk too. Works great for me. I've merged it already. I found a couple minor quirks in prioritized_methods which I've fixed but don't feel confident enough in making a release yet (I already made 3 today). Anyway, TJ requires the dev version which will be pulled out from the mercurial archive whenever it is is installed so it is not much of a problem. I'll make a release of both in a few days hopefully when the dust settles down a bit. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Christopher Arndt wrote: Alberto Valverde schrieb: I've merged it already. I found a couple minor quirks in prioritized_methods which I've fixed but don't feel confident enough in making a release yet (I already made 3 today). Anyway, TJ requires the dev version which will be pulled out from the mercurial archive whenever it is is installed so it is not much of a problem. You mean, you need mercurial installed to install TurboJson? IMHO, that's unacceptable. Please bear in mind that TurboJson is also used by the TG 1.1 branch, for which we hope to issue a beta release soon. We have worked hard to ensure that TG 1.0 is installable with just Python and no other development tools and I think it would be very bad if we regress from there without need. Mercurial doesn't have to be installed to easy_install mercurial archives. These are created on the fly from the repository tip, *zipped*, and served by hgweb. easy_install couldn't care less if the zip was dynamically generated or if is was a static file gathering dust in some hard drive platter ;) Take a look if you want to see for yourself at the links labeled download zip in http://toscawidgets.org/download. This URL is listed as download_url in pypi for prioritized_methods so easy_install looks there when it sees pypi has no 'dev' version registered there. However, I would like some feedback from someone who can try the new version with a TG1 app that makes some good use of custom jsonify rules before making a release, just in case. Although I'm pretty sure that if Jonathan's app didn't break with jsonify 50-60 rules we're going to be ok... :) Cheers, Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
On Mon, Jul 7, 2008 at 11:02 PM, Jonathan LaCour [EMAIL PROTECTED] wrote: I am upgrading my application to TurboGears 2.0, and in the process am having an absolute *fit* with TurboJSON after the switch to PEAK-Rules. I don't want to use any of the default jsonify rules, and before with the older version of TurboJSON, I was able to call `jsonify.clear()` so that I wouldn't have any conflicts. It now appears that this capability is gone, and the documentation for PEAK Rules is essentially non-existent. So, now I have a massive set of rules that are all blowing up with `AmbiguousMethod` exceptions and no way that I can determine a way to fix them. I'm on the fence on that one but I must admit I have been bothered by this too. I had no preexisting rules so just went the __json__ way but I see your point... Anyone? I think this could be solved in two ways which would allow default rules to be bundled (after all, TG2 is all about providing sane defaults to make simple things simple, right?) 1) Implement a custom Method that honors a priority (optional, default to 0) argument to the when/around decorators which will be used to disambiguate. This is what I had in TW when it used rule dispatch and used in many projects of mine and worked like a charm. Default rules in turbojson would have a priority=1000 (for example) so when an ambiguous methods situation emerges from user code extending jsonify the user would just need to raise his/hers implementation's priority. I will probably implement this soon for my gsoc project so if interested I could make it a standalone egg (unless PJE wants to include it in PEAK itself :) 2) Add context to jsonify so it can be dispatched on. This can be achieved by implementing jsonify as a method of GenericEncoder, example: class GenericEncoder(JSONEncoder): @generic() def jsonify(self, value): When generic functions live inside a class peak rules also uses 'self' to dispatch on giving preference to extensions declared inside the class body when the instance method is called (I'm not 100% sure though, only 95%. RuleDispatch did and the little I've played with peak-rules makes me believe it does too but I haven't any unittest to prove it yet) Users could then subclass turbojson's encoder and extend jsonify from there: jsonify = GenericEncoder.jsonify.im_func class MyEncoder(GenericEncoder): @jsonify.when(obj is an SA mapped instance) def _my_sa_jsonifier(self, value): return something useful Instances of this encoder will use _my_sa_jsonifier to encode SA instances overriding any rule declared en GenericEncoder. Rules declared outside of the class body will still affect all GenericEncoder subclasses (unless one does isinstance(self, Foo) of course). I believe 2 is the correct way to do it but the change might not be transparent enough. Besides that, some mechanism should be implemented to tell TG2 which encoder it should use. 1, however, is 100% backwards compatible (but needs someone to implement it :), as I've said, I'll probably do it but I first need to study peak-rules internals in more detail) To sum up, I strongly believe turbojson should ship with default rules as it has always done since it saves developer time by providing sane defaults which is what TG is about. Introspecting SA classes, heck, even extending generic functions, is not something someone new to python would like to face too soon IMHO Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Jonathan LaCour wrote:
Alberto Valverde wrote:
I think this could be solved in two ways which would allow default
rules to be bundled (after all, TG2 is all about providing sane
defaults to make simple things simple, right?)
TG2 is about making simple things simple, but its not about doing it
at the expense of complex things. Bottom line: both of your options
make it much more difficult to write a simple custom jsonifier, and
don't really solve the problem in a simple way.
Option 2 involves subclassing TJs encoder, in what way isn't that
simple? (and it might solve another bug for free as Chris Z has pointed out)
I want to have this at the top of my `json.py`:
@jsonify.when((Person,))
def jsonify_person(obj):
...
This is much simpler to write, and is way easier to explain to a new
user
than something like this:
@jsonify.when(isinstance(obj, Person) and crazy_disambiguator(1001))
def jsonify_person(obj):
...*
Option 1 involves *no* change in user code since TJ's implementations
can have a lower priority than the default so any extension made by the
user automatically overrides the built ins (I thought I had emphasized
this point...). Anyway, the crazy_disambiguator is just a simple
optional argument to the decorators, ie:
@jsonify.when((Person,), 1)
--^
Imagine having to write this 50-60 times (in my case)!
The following command could save you some time ;)
$ find . -name '*.py' -exec sed -e -i 's/\(@jsonify.*\))$/\1, 1)/g' {} ';'
New users don't want to think about things like generic function
disambiguation.
New users don't need to understand how the sausage is made in order to
eat it, I don't get your point.
I think your ideas are both fine ideas, but they
don't eliminate the need to be able to turn the defaults off.
I think the simplest approach here is the best: put the defaults in
a separate module, and have them be imported by default in the
TG2 json.py template in your project. If you want to remove the
defaults, you can simply delete that line from your `json.py` and
you're set!
So if you only need to override how Person is jsonified you suddenly
need to copy and paste (or re-implement for the fun of it) the rule to
jsonify all other SA mapped objects from tg since you turned it turned
it off en masse.
What if a some tg extension in the future needs to add rules to jsonify
their objects so they can be reused by user code? Now those rules are
disabled too, need to copy them again... suddenly all the power that
generic functions give framework developers to add hooks so their code
can be easily extended is lost.
Both solutions I proposed allow to *selectively* extend the encoder
while preserving rules any extension might have added or might need to add.
The simplest solution is the best, IMO :)
I fully agree, but I believe I've excelled in my previous at making them
sound much harder than they really are ;)
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Jonathan LaCour wrote:
Alberto Valverde wrote:
Option 2 involves subclassing TJs encoder, in what way isn't that
simple? (and it might solve another bug for free as Chris Z has
pointed out)
Maybe I misunderstood, would rules still be able to be functions,
rather than methods? I was under the impression that this method
would involve changing the way that jsonification rules are
written. If that isn't the case, then my objections to this method
are completely withdrawn :)
Not at all, no need to change how they are written, the only thing that
changes is what jsonify is (an instance method instead of a function),
TJ could do this interanally so the API remains the same:
jsonify = GenericEncode.jsonify.im_func
Option 1 involves *no* change in user code since TJ's
implementations can have a lower priority than the default so any
extension made by the user automatically overrides the built ins
(I thought I had emphasized this point...).
Yeah, in my exhausted stupor, I must have missed that detail :) As
long as the user's rules *always* override the defaults, I am a
happy man! Objection withdrawn to this solution.
The following command could save you some time ;)
$ find . -name '*.py' -exec sed -e -i 's/\(@jsonify.*\))$/\1,
1)/g' {} ';'
Ah, sed! Incidentally, this is exactly what I would have done :)
I knew that, just wanted to counter your poor argument :P
So if you only need to override how Person is jsonified you
suddenly need to copy and paste (or re-implement for the fun of
it) the rule to jsonify all other SA mapped objects from tg since
you turned it turned it off en masse.
Well, this is what I was doing, because I actually don't want every
single field of my SQLAlchemy objects to be serialized. I want to be
able to explicitly control it, which is why I don't like there being
no way to turn off the defaults! Having complete control over the
JSONification of my objects is extremely important to me.
With the current implementation you can easily pop fields like this:
@jsonify.around(instantance(obj, Person))
def jsonify_person(next_method, obj):
dct = next_method(obj) # call TJ's implementation
del dct['swiss_bank_acc_no']
return dct
Both solutions I proposed allow to *selectively* extend the
encoder while preserving rules any extension might have added or
might need to add.
Sure, but I still want to be able to turn them off, even if it
does break some future extension. The bottom line for me is that
I totally understand (and agree with) your arguments, but I still
think that there needs to be a mechanism for clearing out the
default rules to give the user complete control over them.
Thanks for your hard work, Alberto!
Hard work? seems you were spying on me... ;) here's option 1:
http://toscawidgets.org/trac/rum/browser/rum/prioritized_methods.py
With tests and docs (for a change ;) You can use the prioritized_when
decorator
in there *now* to fix your TJ troubles until TJ adopts a definitive
solution (I'll probably release it as a standalone egg when it gets more
eyeballs).
from turbjson.jsonify import jsonify
from prioritized_methods import prioritized_when
jsonify.when = prioritized_when.__get__(jsonify)
@jsonify.when(isinstance(obj, Person), prio=1)
def jsonify_person(obj):
(don't actually need the prio argument to override ATM since
prioritized_when overrides peak.rules.when by default)
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: [TW] Re: inject_resources and tg2
percious wrote: Um, I'm not using pylons.c.w. ... Sorry, I misunderstood you. My idea was that we should cycle through the objects in pylons.c before rendering the template, and call inject() on any item that is a Widget. Scanning the output dict is what precisely what the new injection mechanism tries to make unnecessary but there's not harm in doing it if you really want/need to. +0 (but it shouldn't be encouraged IMO) Perhaps we should discuss this on the tg2 board? Yeah, this is more related to tg than tw..., ccing them. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Controller differences between tg1 and 2
Mark Ramm wrote:
And request.params is a multidict, so it has all your values, with
nothing thrown away.
Ah, ok. So it's essentially the J2EE-way.
Well, since it's a multidict, if you treat it as a dict you get only
the first value, but for anything where there might be multiple values
you just call params.getall('name').
Which IMHO makes more sense, because 90% of the time you want a single
value, and when you occasionally do want a list it's easy to get.
You might find this useful, this is what TW does to emulate TG's behaviour:
http://toscawidgets.org/trac/tw/browser/tw/core/base.py#L485 (up to #L491)
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: Stupid TG2 question
Diez B. Roggisch wrote: Hi, I just installed the 1.9.7 alpha (using virtualenv ubuntu gutsy) A quickstart seems to run fine - yet I miss some start-tg2test.py or such. I looked into the docs to no avail. So - how do I *start* my new TG2 baby? TG2s wsgi app is loaded using pastedeploy as specified in an .ini file, there are no startup scripts like in TG: $ paster serve development.ini Chris P has made a screencast that covers this at around minute 7-8 :) http://showmedo.com/videos/video?name=287fromSeriesID=287 Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Performance of TurboGears vs. PHP+Apache
Sanjay wrote: Hi All, It might be a novice question on deployment. I am a TurboGears guy since long, but still new to certain things like deployment etc. So, pl. bear with me if my words are not exact and technical. A couple of days back I was presenting about TurboGears to a PHP web architect. He was of the view that PHP behind Apache is faster because it doesn't have to create new instances per request or queue requests. He's got it right except for that it is the opposite way around :) TG is (usually) a multi-threaded long running application for the good (modules are cached in memory when imported, import-time initialization stuff is done only once in the lifetime of a process...) and the bad (you have to be careful with shared memory among threads, leaking memory...) Ian wrote some time ago a good post that mentions this: http://blog.ianbicking.org/2008/01/12/what-php-deployment-gets-right/ But frameworks like RoR create new instances for each request and hence is not preferable for high traffic sites. AFAIK Rails' model of execution is similar to TG's CherryPy applications, as I have understood, do similar thing as PHP and should be at par. So, reverse proxing a TG Application behind Apache or NginX should be at par with a PHP+Apache deployment. Is my understanding ok? Nope :) What about TG 2.0? TG2 and Pylons are similar to TG1 in this sense: An instance is a long running app, usually multithreaded, that can serve arbitrary number of requests in its lifetime. Alberto thanks Sanjay --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Error when accessing pylons.c.w
Hi Roger,
Roger Demetrescu wrote:
Hi Walter and Sanjiv
On Thu, Jun 26, 2008 at 04:20, Sanjiv [EMAIL PROTECTED] wrote:
Hi Roger,
The WidgetBunch is no more required and the widget may be directly
stuck to the tmpl_context. So all pylons.c.w becomes pylons.c, i.e.
pylons.c.form = create_movie_form
and the widget can be obtained in the template directly from the
tmpl_context as
${tmpl_context.form(value=value)}
The docs seem to be not yet to be updated as this is a very recent
change.
BTW, you can also import widgets directy from the template. This is
useful for JS or CSS Links or for widgets that don't submit any input
(hence you don't need them in the controller to perform validation).
Widgets that require js or css links will work correctly too.
Ok... I did a quick test today morning and it worked indeed...
However, I am intrigued with the actual code of Toscawidget's
mods/pylonshf.py
===
def _render_func_wrapper(func):
...cut...
tw_extra_doc = \
This version is a ToscaWidgets wrapper which collects resources in
pylons.g.w and pylons.g.c and makies them available at pylons.c.resources
so the base template can render them.
It also sets the default_view if the engine name is overrided when calling me.
===
It seems it still looks at pylons.c.w and pylons.g.w... Is it only for
compatibility ?
Yes, these are legacy functions. I should probably put a deprecation
notice on them.
I didn't test the form with a javascript/css resource. Are these resources
been
correctly collected ?
Yep, take a look here for the details:
http://toscawidgets.org/documentation/ToscaWidgets/modules/resource_injector.html
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 docs update
Roger Demetrescu wrote: Hey Mark, What are the procedures to do an update in tg2 docs (at web site) ? Is it something you have doing manually ? ie.: I see that the changes in download install documentation are not yet reflected on http://turbogears.org/2.0/docs/main/DownloadInstall.html I believe they are now stored in TG's source tree in rst/sphinx format. You can edit them and check them in the same way you'd do for code. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Moving On
Paul Johnston wrote: Hi, I've been involved in TurboGears for nearly two years now. It's been an interesting ride, I've written some code I'm really proud of, and I think I've made some good contributions to the community. Just of late, I've been reassessing priorities in my life, and open source development isn't going to be a big one going forward. In fact, I may even be giving up the computer completely for a year or two and going travelling. So, I'll be unsubscribing from the mailing lists over the next few days. I'm still happy to get emails about turbogears at my personal account, at least for the next couple of months. And those of you I've worked with (Florent, Alberto co) - I hope we stay in touch. Thanks for all the interesting chat, It was a pleasure working with and having you around Paul. I Wish you the best with whatever you end up doing next! Thanks Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: validation
Hi ! I'm building an app in TG2, but my question is about the validation mechanism, i've building some kind of web components that wraps a few widgets and locate them in a structured html, and the problem is that i don't return the forms directly, instead a compound widgets with forms and other stuff. I'm not sure of how tg2 validation mechanism works but i'm really interested on keeping my web components, is there any way i can make validation for it ? i mind, how i can catch those messages and manually put them in the form ? ( or something like that ) ( This web components are the vertebral column of lymon ) If the form is not the root widget you won't be able to use the validate() decorator TG2 provides but will have to validate manually, example: Say we have a form inside widget panel called search_form def my_controller(self): try: value = panel.c.search_form.validate(request.POST) except Invalid, error: # validation failed, re-render the panel but this time pass the # error and previous values to the form explicitly panel.c.form.error_at_request = error panel.c.form.value_at_request = request.POST return panel.display() else: # do something useful Haven't actually tested the code so tell us how it goes... Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: tg2 install problem with pylons from mecurial
On Fri, 2008-13-06 at 00:56 -0700, iain duncan wrote:
Thought I'd get back on the TG2 again, but I get the following when I
try to check out Pylons from mecurial:
$ hg clone http://pylonshq.com/hg/pylons-dev Pylons
$ cd Pylons
$ sudo python setup.py develop
... ( lotsa stuff )
Processing dependencies for Pylons==0.9.7beta5dev-20080613
Searching for WebOb=0.9.2
Reading http://www.pylonshq.com/download/
Reading http://www.pylonshq.com/download/0.9.7
Reading http://pypi.python.org/simple/WebOb/
Reading http://pythonpaste.org/webob/
No local packages or download links found for WebOb=0.9.2
error: Could not find suitable distribution for
Requirement.parse('WebOb=0.9.2')
Anyone know what gives there? Should I be posting on pylons?
Yep, let them know at pylons-devel. It seems they have set their egg
metadata wrong in Pylons' setup.py. For the meantime you can force
setuptools to build an egg without the -dev suffix and install that. From
a WebOb checkout do:
python setup.py egg_info -RDb install
To be sure make sure you remove all previous WebOb versions from
site-packages manually before doing this.
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] [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 TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Mailing list help.
Mark Ramm wrote: Hi, I'm looking for archives of the TurboGears and TurboGears trunk mailing lists in mbox or maildir formats. If you have such a thing, or are willing to try to make that happen, I can promise to use it only for good. And to make turbogears debugging easier and better for everybody. ;) t I've got those since when I first subscribed. I've set up a cronjob to make a nightly archive at noon UTC and leave it at: http://toscawidgets.org/download/TGMailingListArchives.tar.bz2. They're in Maildir format. Happy spamming ;) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] [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 TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: dependency issue in tw.forms
Mark Ramm wrote: Changing the pylons version in tw.forms to: 'ToscaWidgets = 0.8.6', seems to resolve the problem. I think Alberto has plans to release some new TW versions in the very near future, but for those sprinting today this should get you working... I'm stupid. I forgot to release 0.8.7 yesterday. It's in PyPI now. Sorry for the inconvenience. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] ToscaWidgets without RuleDispatch (and a bunch of other deps.)
Hi, ToscaWidgets 0.9 is available for testing at the dev repository. To upgrade either pull the new changes with Mercurial or install the development snapshot: easy_install -U http://beta.toscawidgets.org/hg/ToscaWidgets-dev/archive/tip.zip Most notable change is that there's not C dependency at all anymore since RuleDispatch has been removed (hence no PyProtocols dep. either). Those of you still using TW's generic functions can grab the 0.8.X version from pypi which issues deprecation warnings to ease on the migration. 0.8 has been branched into a new repository to fix any possible bug though it won't be maintained for too long so please upgrade to 0.9 as soon as possible. PasteScript has also been removed as a hard dependency, that is, TW is perfectly usable without it, it is only needed to scaffold a widget egg with paster. The use of the decorator module has also been removed because it wasn't strictly necessary as we weren't depending on any decorated function's signature except to show them in the generated API docs. So, the only dependencies left are currently simplejson and Paste. :) Paul has also contributed an important internal change which allows widget repeater to have unlimited repetitions without incurring in an increased memory foot-print. Thanks! :) Finally, we've also made a tw.forms 0.8.1.2 release which is compatible both with the 0.9 and 0.8 branches. I'll try to close the remaining tickets from the 0.9 milestone [1] during this sprint and do a release on monday June 2nd though I can't guarantee anything (as always ;) since I'd also like to move beta.toscawidgets.org into production, write some ajax widget demos for the widget browser, get outdoors for a bike ride and go out to have a few beers ;) Anyway, the release will most probably go out even if not all those tickets are closed so these important changes can be tested in the wild ASAP. Enjoy, Alberto [1] http://beta.toscawidgets.org/trac/tw/milestone/0.9 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: ToscaWidgets 0.8.6 is out
percious wrote: I just wanted to say thank you to Alberto for his hard work. You're welcome :) Also, I wanted to mention that I don't know of any widgets in the twtools family that use Rule Dispatch. I urge those using RD in their widgets to speak up about it so that we can move quickly from deprecation to elimination. Elimination has hit the repository a few minutes ago :) I'm planning on a release this Monday after the sprint. Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Turbogears 2 and namespaces.
I propose we make tg a namespace for 2.0:
+1 but...
).)
Here is the required change:
begin patch:
Index: setup.py
===
--- setup.py(revision 4567)
+++ setup.py(working copy)
@@ -23,6 +23,7 @@
url=url,
license=license,
packages=find_packages(exclude=['ez_setup', 'examples',
'tests']),
+namespace_packages = ['tg'],
include_package_data=True,
zip_safe=False,
install_requires=[
Index: tg/__init__.py
===
--- tg/__init__.py (revision 4567)
+++ tg/__init__.py (working copy)
@@ -50,6 +50,9 @@
they make it possible for a group of TurboGears components to share
assumptions
about how things will work.
+#make the tg namespace work
+__import__('pkg_resources').declare_namespace(__name__)
+
from tg.controllers import TGController, redirect, url
from tg.decorators import validate, expose
from tg.flash import flash, get_flash, get_status
setuptools doesn't allow the __init__.py of the namespace-package to have
any code but the __import__ statement [1] :(
Quoting setuptools docs:
You must NOT include any other code and data in a namespace package's
__init__.py. Even though it may appear to work during development, or when
projects are installed as .egg files, it will not work when the projects
are installed using system packaging tools -- in such cases the
__init__.py files will not be installed, let alone executed.
So this would require some magic to populate the tg namespace after it
has been imported. Based on my experience with TW (with the tw.framework
symbol) I *don't* recommend this since it has some subtle side effects
that have caused me some headaches (eg, TW can't be nosetested at the
moment because nose's import mechanism interaction with this).
Alternatively, these symbols could be moved to a tg.api module but this
would be a minor API breakage.
Overall, I'm in favor of the change even if it causes a little breakage
(better now than later).
Alberto
[1] http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
