[TurboGears] Re: kw received by validation_error is empty
As I have said before, the correct way of doing it is:
def validation_error(self, tg_source, tg_errors, *args, **kw):
If this does not work, try running tests on you TG installation, if
there are no failures reported, you are messing up error handling
somewhere in your code.
Cheers,
Simon
Arnold wrote:
So far my best results are with:
def validation_error(self, func, errors, *args, **kw):
appliLogger.debug(Validator_error func : + func)
appliLogger.debug(Validator_error kw : + str(kw))
appliLogger.debug(Validator_error args : + str(args))
appliLogger.debug(Validator_error errors : + str(errors))
and the log is:
2006-07-03 21:11:51,985 DEBUG Validator_error func : suscribe
2006-07-03 21:11:51,985 DEBUG Validator_error kw : {}
2006-07-03 21:11:51,986 DEBUG Validator_error args : ({'age':
formencode.api.Invalid instance at 0xb7387f2c},)
2006-07-03 21:11:51,987 DEBUG Validator_error errors : {}
This link is not available at the moment, but I will visit it as soon
as it is on again.
http://trac.turbogears.org/turbogears/wiki/HowDoesErrorHandlingWork
But all that seems to be more less buggy...
Cheers
Arnold
Arnold
I can't get parameters in
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[TurboGears] Re: kw received by validation_error is empty
tg_errors should contain field name and error pairs while unmolested
input is in kw.
Try:
def validation_error(self, tg_errors,tg_source, **kw):
may be of help as well:
http://trac.turbogears.org/turbogears/wiki/HowDoesErrorHandlingWork
Cheers,
Simon
Arnold wrote:
Simon,
Looking at the TG code, I came to the conclusion that the order of
parametres should be like that:
validation_error(tg_errors,tg_source,self,kw):
My test code is :
def validation_error(tg_errors,tg_source,self,kw):
appliLogger.debug(Validator_error tg_source : + tg_source)
appliLogger.debug(Validator_error kw : + str(kw))
appliLogger.debug(Validator_error tg_errors : +
str(tg_errors))
errorList=kw.keys()
The log is this one:
2006-07-02 21:47:24,165 DEBUG Validator_error tg_source : suscribe
2006-07-02 21:47:24,166 DEBUG Validator_error kw : {'age':
formencode.api.Invalid instance at 0xb09ef38c}
2006-07-02 21:47:24,166 DEBUG Validator_error tg_errors :
newgears.controllers.Root object at 0xb7450aec
tg_source: it's ok, I get a string with the name of the calling
function
kw: it's OK, I get a dictionnary with the names of the parameters that
failed in validation
tg_errors: I thought that it would contain the parameters initially
sentby the browser to the calling function, but it doens't. I don't
understand what it is.
Can you explain ?
Thanks
Arnold
Simon Belak wrote:
**kw needs to be last (a Python limitation, see keyword arguements).
Cheers,
Simon
Arnold wrote:
Thank you Simon,
I replaced the names like this : def validation_error(self, tg_source,
**kw, tg_errors):
The fundamental change is **kw instead of kw, but I get an error at
server launch:
def validation_error(self, tg_source, **kw, tg_errors):
^
SyntaxError: invalid syntax
I believe that tg_source, **kw, tg_errors are names in calling
program.
Have you a short code example ?
Thanks again
Arnold
Simon Belak wrote:
Arnold wrote:
I can't get the form parameters that go through the validator. My code:
@turbogears.expose(html=newgears.templates.confirmation)
@turbogears.validate(validators={ mailAdress : validators.Email()})
...
def validation_error(self, funcname, kw, errors):
When the email is invalid, validation_error is correctly called but kw
is empty : {}
I guess my code is wrong ! Any clue appreciated
Arnold
If the above is actual code, you have your argument names wrong. Try
funcname - tg_source
errors - tg_errors
kw - **kw
Cheers,
Simon
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[TurboGears] Re: kw received by validation_error is empty
Arnold wrote:
I can't get the form parameters that go through the validator. My code:
@turbogears.expose(html=newgears.templates.confirmation)
@turbogears.validate(validators={ mailAdress : validators.Email()})
...
def validation_error(self, funcname, kw, errors):
When the email is invalid, validation_error is correctly called but kw
is empty : {}
I guess my code is wrong ! Any clue appreciated
Arnold
If the above is actual code, you have your argument names wrong. Try
funcname - tg_source
errors - tg_errors
kw - **kw
Cheers,
Simon
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[TurboGears] Re: kw received by validation_error is empty
**kw needs to be last (a Python limitation, see keyword arguements).
Cheers,
Simon
Arnold wrote:
Thank you Simon,
I replaced the names like this : def validation_error(self, tg_source,
**kw, tg_errors):
The fundamental change is **kw instead of kw, but I get an error at
server launch:
def validation_error(self, tg_source, **kw, tg_errors):
^
SyntaxError: invalid syntax
I believe that tg_source, **kw, tg_errors are names in calling
program.
Have you a short code example ?
Thanks again
Arnold
Simon Belak wrote:
Arnold wrote:
I can't get the form parameters that go through the validator. My code:
@turbogears.expose(html=newgears.templates.confirmation)
@turbogears.validate(validators={ mailAdress : validators.Email()})
...
def validation_error(self, funcname, kw, errors):
When the email is invalid, validation_error is correctly called but kw
is empty : {}
I guess my code is wrong ! Any clue appreciated
Arnold
If the above is actual code, you have your argument names wrong. Try
funcname - tg_source
errors - tg_errors
kw - **kw
Cheers,
Simon
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[TurboGears] Re: memory footprint ?
How much does a pure Python instance take on your system? It would probably help if you compile Python yourself and include only what you actually need. Cheers, Simon [EMAIL PROTECTED] wrote: Kevin Dangoor wrote: On Jun 20, 2006, at 9:17 PM, [EMAIL PROTECTED] wrote: well, just checked it again. I saw 2 processes(from the startup script), one with 15M, the other 70M(with 2 thread_pool). This seems to be a bit high. Are you running in development mode? You should only have one process in production mode. Yes. changing to production mode reduce it some what but the virtual memory foot print is still 57M for 2 thread pool. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Shoudn't First Class be 2.0?
The problem is, many people freak out when they hear we will do almost a full rewrite in 1.1 coming right after supposedly stable 1.0, making it harder to convince people to commit to TG for a long term project. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Production server stops responding.
A long shot, but is it possible that this particular process runs out of available threads (see prod.cfg: server.thread_pool)? Cheers, Simon mulicheng wrote: I'm running a couple instances of my application in production and balancing them with lighttpd's mod_proxy. (Thanks all for getting me on the right track with that.) On a pretty regular frequency, one of the instances will stop responding to requests. (The site stays up because there is more than one instance running.) Does anybody have any suggestions on how to debug the process that is still running? I'm not sure if it is something in my business logic causing the problem or if there is something wrong with TG/Cherrypy. The process is still listening on the port I started it on, a tcp connection can be made, but no response is delivered and there is no debugging information printed. Thanks Dennis mydrawings.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: [europython] Off topic, but very important..
Rune Hansen wrote: On 6,7. jun. 2006, several people responded: It's a bit early but one could draw the conclusion that: a) We will be 3-4 people available for a sprint... b) Only one person, apart from my self, has made any committed to the beer drinking part. c) I'm the only one interested in football, apart from Splee - who might not even be there(!). I'm not much of a football fan but than again beer does wonders for inquiring minds. ;) I'll gladly take your offer (and beer). Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: [europython] Off topic, but very important..
I am going (and even giving a talk). Cheers, Simon P.S. I am still interested in a sprint Rune Hansen wrote: Who among you are going to Europython? Identify your self! I know that Kevin is going. (btw. Kevin, if you need any help, let me know. I will be arriving at CERN on July 1. I'm staying at the CERN hostels.) Personally, I'll be up for: a) Coding b) Having a beer c) Watching football d) Watching some more football e) Perhaps another beer? d) Some more coding. Anyone interested in joining me? /rune - Behind the firewall, nobody can hear you scream... -- Simon Belak vodja projektnih skupin e: [EMAIL PROTECTED] - Hruska d.o.o., agencija za nove medije Ilirska 21, SI-1000 Ljubljana t: +386 1 430 25 86 f: +386 1 430 25 87 s: http://www.hruska.si s: http://akademija.hruska.si (izobrazevalni portal) s: http://www.elor.si (kadrovski sistem letnih razgovorov) Hruska.si - socne resitve To elektronsko sporocilo in vse morebitne priloge so poslovna skrivnost in namenjene izkljucno naslovniku. Ce ste sporocilo prejeli pomotoma, Vas prosimo, da obvestite posiljatelja, sporocilo pa takoj unicite. Kakrsnokoli razkritje, distribucija ali kopiranje vsebine sporocila je strogo prepovedano. This e-mail and any attachments may contain confidential and/or privileged information and is intended solely for the addressee. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail, or any action taken or omitted to be taken in reliance on it, is strictly prohibited. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: massive code simplification
Kevin Dangoor wrote: I think that we'll be able to simplify our code *a lot* in 1.1 (if not sooner, definitely post-1.0 though). That should be a goal. Simon has done impressive work on the decorators to make them 1) work within a straight decoration model (you call the method, and it gets all of the decorated behavior... no shenanigans with CherryPy to make it work) 2) preserve the look of the original controller method I have a hunch that we'll be able to tremendously simplify things by throwing away decoration altogether. I *could* be wrong, but you never know for sure until you try. The basic idea is that the decorators rather than truly decorating the original method will instead register a set of behaviors to occur at input/output/error/exception time. All of the monkeying with method signatures and whatnot can go away. This simplification *might* be doable today with a CP filter. If not, I'd be surprised if we couldn't get CP3 or RhubarbTart to do what's needed. I realize that this is vague, but I wanted to toss the general notion out there. Looking through the code, we're doing *a lot* of work at compile time and run time to provide a consistent view of the world, and I think we can make everything easier with a bit of refactoring. You bloody bastard since when do you have a mind reading device installed? ;) Seriously I have been toying with the same ideas, even have some code, but I intend to wait until PJE finishes RuleDispatch overhaul. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] buzhug -- alternative model provider?
This looks interesting: http://buzhug.sourceforge.net/ a pure-Python database engine, using a Pythonic, no-SQL syntax Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: EuroPython: call for presentations
What's the deadline (I'm going 99%)? Cheers, Simon P.S. will there be a TG code sprint? Kevin Dangoor wrote: Hi, TurboGears needs another presentation at EuroPython. I'm giving the keynote for the web track and I don't really have time to prepare more than that right now. If you're planning to go to EuroPython and would like to do a talk, please email me... (Also, a possible alternative: if you won't be at EuroPython, but you'd like to help me out with presentation preparation, I could likely give the presentation there. My issue is mostly that the month of June is heavily oversubscribed for me.) Thanks! Kevin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: py2exe
Let's just say I wouldn't be surprised if SoC brought us tg.exe ... ;) Cheers, Simon Kevin Dangoor wrote: On 5/15/06, Jonathan LaCour [EMAIL PROTECTED] wrote: Yeah, I had a feeling this was the case. It was worth a shot! Are there any efforts going on that you know of in the py2exe/py2app camp to make this happen? IIRC, setuptools is becoming a part of Python in the 2.5 release, so it stands to reason that this will have to happen sooner or later. I haven't really seen any movement on this on distutils-sig. I agree that it has to happen sooner or later (and I think the maintainers of those packages do as well). It's just a matter of someone having a project that urgently requires it. Kevin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] [article] How To Set Up A Loadbalanced High-Availability Apache Cluster
http://www.howtoforge.com/high_availability_loadbalanced_apache_cluster A little something for all us poor misguided souls who insist TG scales just fine. Cheers, Simon P.S. is anybody else interested in some sort of TG users reading club for such articles (not directly related to TG but still very useful)? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Custom logger
Disclaimer: I am being lazy and asking here before doing any serious research, having said that, how does one define a custom stream for logging. Looking at the config file: [[handlers]] [[[debug_out]]] class='StreamHandler' level='DEBUG' args='(sys.stdout,)' formatter='full_content' I should probably set args to something else, but how will imports/namespaces be handled? Basically I want to collect all the crap that gets written to stdout. Thanks! Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Custom logger
Kevin Dangoor wrote: On 5/12/06, Simon Belak [EMAIL PROTECTED] wrote: Basically I want to collect all the crap that gets written to stdout. I should also note that there is a FileHandler class that takes a filename as the arg. But I would like to have a stream (file-like object). Since TG uses a multitude of logging namespaces it's not very practical to use basicConfig() on each one. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: Paginate is not working
This needs to be solved system wide, not just hacked for specific situations. Cheers, Simon Claudio MartÃnez wrote: I found the problem to be that when tg.strict_parameters is disabled adapt_args will clear the parameters used by paginate. There are many ways to solve this: I can directly use cherrypy.request.input_values and still clear the variables from **kw so they don't hit the controller in strict mode. Or we can make adapt_args not to clear tg_* variables and let every decorator clear their own parameters. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] No tg_flash
Is there any way not to have tg_flash in method output if returning dicts? I could probably serialise my data before hand (thus returning a string), but I would like to keep it DRY. Thanks! Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Theory: an XML Model library, styled after SQLObject
Would you mind writing a trac/wiki page on this?
Thanks!
Cheers,
Simon
Sean Jamieson wrote:
Hmm, either nobody is interested, or everybody is to busy...
I'm going to assume the latter, for the sake of my own ego :-)
Just to recap, XMLModel allows you to expressively define an XML document,
using native python classes, you can then access the elements of the XML
through
a tree of native python objects.
In the future, I'm hoping to write a parser that can take a given model,
and fill in the data from an XML document. I don't imagine this being
too dificult, as a lot of the work is done by the model itself (it
defines what data to look for).
Here is an example of how XMLModel is used:
#!/usr/bin/env python
from xmlmodel.main import *
from xmlmodel.xmlvalues import *
from datetime import datetime
class rss( XMLModel ):
class XMLAttrs:
version = '2.0'
class channel( XMLNode ):
title = XMLValue('test')
description = XMLValue('something')
link = XMLValue('http://here')
lastBuildDate = XMLDateTime( format = %a, %d %b %Y %H:%M:%S EST )
generator = XMLValue()
docs = XMLValue()
class item( XMLNodeList ):
title = XMLValue()
link = XMLValue()
description = XMLValue()
category = XMLList()
pubDate = XMLDateTime( format = %a, %d %b %Y %H:%M:%S EST )
feed = rss()
feed.channel.title = 'Latest Headlines'
feed.channel.description = 'Most Recent Headlines'
feed.channel.generator = 'XMLModel 0.1a'
feed.channel.lastBuildDate = datetime( 2006, 5, 10, 8, 24, 30 )
# Normally we would loop this ;-)
item = feed.channel.item.new()
item.title = 'foo'
item.link = 'http://foo'
item.description = 'foo bar'
item.category.append( 'foo' )
item.category.append( 'bar' )
item.pubDate = datetime( 2005, 1, 2, 3, 4, 5 )
item = feed.channel.item.new()
item.title = 'bar'
item.link = 'http://bar'
item.description = 'bar baz'
item.category.append( 'bar' )
item.category.append( 'baz' )
item.pubDate = datetime( 2006, 2, 3, 4, 5, 6 )
print feed
# or this would be ever so slightly faster
# (it made a one second difference, when generating 2.5MB of XML, on my
laptop)
# for buf in feed.toxml(): # toxml() is a generator
# print buf
Any comments, suggestions, or bug reports are welcome.
Sean
Sean Jamieson wrote:
Well, it was a bit painfull, and I ran head first into several walls.
But here is the 0.1 alpha version of XMLModel.
if the attachment didn't work, here is a temporary link:
http://www.barriescene.com/xmlmodel.tar.gz
Try it, let me know what you think, or of any bugs (patches welcome)
I'll figure out an SVN for it later on.
Sean
P.S. I just joined www.linkedin.com feel free to invite me using this
address :-)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[TurboGears] [article] Flummoxed By Frameworks
http://meyerweb.com/eric/thoughts/2006/05/08/flummoxed-by-frameworks/ Some insights into what people find confusing with web framework intros/presentations. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Exception reporting
The trunk version does.
Cheers,
Simon
Max Ischenko wrote:
I tried to use Simon's exception handling first but gave up because it
gives no traceback which is crucial for a developer.
I use the following instead:
def cp_on_http_error(self, status, message):
from cherrypy import _cputil
_cputil._cp_on_http_error(status, message)
if status == 404:
return # do no extra processing on 404 errors
log.exception('CherryPy %s error (%s)', status, message)
import traceback, StringIO
buf = StringIO.StringIO()
traceback.print_exc(file=buf)
url = %s %s % (cherrypy.request.method,
cherrypy.request.path)
send_exception_to_developer(status, url, buf.getvalue())
# Return customized page
...
# Hook it in for production only
if tg.config.get('server.environment') == 'production':
Root._cp_on_http_error = cp_on_http_error
# function send_exception_to_developer
# simply formats mail message nicely and sends via SMTP
HTH,
Max.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[tg-trunk] Re: Retrieving data from function to decorators
Jorge Godoy wrote:
Hi.
I'd like to know if there's something I can do to pass data from inside my
function to the decorator, more specifically pass a parameter that my code is
expecting and passing it to the decorator. Something like this:
@turbogears.expose()
@turbogears.error_handler(
turbogears.util.bind_args(segmento = kword['segmento_id'],
tabela = kword['tabela_id'])(precos))
@turbogears.validate(form = formulario_precos_analises)
@identity.require(identity.conditions.in_any_group('latam_novo', 'admin'))
def save(self, **kword):
...
With this code I get a NameError exception saying that kword is not
defined.
If I try passing the names outside the dictionary I get the same error...
Why this? In this case, I want the page to go back to the same data it had
when the form was submitted. I am doing that, today, from inside the method
and checking tg_errors, but I would really prefer using the decorator for
that.
Thanks for any tips, hints or it will never work messages ;-)
Considering the order of execution, in general you can't pass state from
the function to the decorators at run-time.
Try using an intermediate function that extracts relevant data from
kword or have the arguments for precos be named same as keys in kword
and it should work automatically.
Cheers,
Simon
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[tg-trunk] Re: strange decoration behavior
Kevin Dangoor wrote:
Or, at least, it seems strange to me.
If I run nosetests on the whole suite, a create_request that calls this
method:
[expose(turbogears.tests.simple)]
[expose(json, accept_format = text/javascript, as_format=json)]
def with_json_via_accept(self):
return dict(title=Foobar, mybool=False, someval=foo)
Gets called like this:
Calling function with_json_via_accept at 0x2560030 with *((function
with_json_via_accept at 0x255e9f0,
turbogears.tests.test_expose.ExposeRoot object at 0x2511c70)),
**({})
Interesting thing #1: this test doesn't fail when test_expose is run
by itself. I'm not sure at all why that would make a difference.
How it fails?
So, the problem that comes up, in case that cryptic log output doesn't
reveal it, is that the first argument passed is a different function
masquerading as the original one (note the ids), and the *second*
argument is the true self.
This is to be expected. By our convention decorators have the form:
def my_d(a):
def entagle(func):
def my_d(func, *args, **kw)
the inner my_d is what gets evoked on a call.
I like this naming convention because it allows us to see how decorators
are getting called at run-time.
This is likely directed at Simon: my guess is that the problem here is
caused by having two decorators. Any idea why it works in one context
and not the other?
It could be just something [new] expose() specific. Another possibility
is a bug in decorator module which manifests only when the same
decorator is applied multiple times. How the tests fails would be most
helpful.
Cheers,
Simon
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[tg-trunk] Re: Making expose work the way I want
Kevin Dangoor wrote: I really *want* to be able to do what Elvelind was originally suggesting: @expose(path.to.some.template) @expose(json) def foo(...) @expose(json) def bar(...) The bar case above works right now. The foo case does not (and I recently made a change to explicitly throw an exception, rather than just acting in unexpected ways -- specifically, the JSON one wins). My thought for making this work is to defer the creation of the generic function to the first request, just hanging on to the info needed to build the rules as the decorators are called. The *last* expose that is called as a default (which is the top most decorator visually) is the one that is treated as the default. Any other ones listed as a default will have the template engine name used in place of as_format. That would allow @expose(xmlrpc) to be added potentially as well... It would be good if the template engines could specify the accept headers that may be appropriate for their output. Kevin Give me a ticket and I will give you code. ;) I've been meaning to clean-up expose() anyway because this is getting unbearable. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Exception reporting
Robin Haswell wrote: Hey there Does TG have any provisions for exception reporting (eg, E-mailing the developer), and if not, do you think this would be difficult to implement? I'm coming up to BETA deployment soon and I'd like to have some notifications of errors :-) Built-in no, however it is pretty trivial to do so. You can either: 1) override method _cp_on_error in your Root controller 2) define a catch-all exception handler: @dispatch_error.when(tg_exception is not None) def notify(self, tg_source, tg_exception): return Holly exception Batman! Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Exception reporting
Robin Haswell wrote: 2) define a catch-all exception handler: @dispatch_error.when(tg_exception is not None) def notify(self, tg_source, tg_exception): return Holly exception Batman! Cheers, I think I'll go for this option, but it doesn't seem to work properly. Have I done something wrong? [EMAIL PROTECTED]:~/obb$ ./start-obb.py Traceback (most recent call last): File ./start-obb.py, line 26, in ? from obb.controllers import Root File /home/rob/obb/obb/controllers.py, line 33, in ? class Game(controllers.RootController): File /home/rob/obb/obb/controllers.py, line 350, in Game @turbogears.errorhandling.dispatch_error.when(tg_exception is not None) File /usr/local/lib/python2.4/site-packages/TurboGears-0.9a5-py2.4.egg/turbogears/genericfunctions.py, line 20, in when return self._decorate(cond, primary%d % order) File build/bdist.linux-i686/egg/dispatch/functions.py, line 577, in _decorate File string, line 10, in parseRule File build/bdist.linux-i686/egg/dispatch/functions.py, line 440, in parseRule File build/bdist.linux-i686/egg/dispatch/functions.py, line 326, in parse File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 383, in parse_expr File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 378, in build File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 111, in comparison File build/bdist.linux-i686/egg/dispatch/predicates.py, line 576, in Compare File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 378, in build File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 10, in lambda File build/bdist.linux-i686/egg/dispatch/predicates.py, line 58, in Name NameError: tg_exception Sorry, I gave you the wrong name, in 0.9 (and 1.0) it's tg_exceptions (plural). Perhaps this is related to my broken .9a1-.9a5 project? I intend to fix it up soon, but I currently get these errors all over the bloody place (although never on startup, only on shutdown or page load): 2006-05-07 20:58:07,831 cherrypy.msg INFO HTTP: Serving HTTP on http://localhost:8080/ 2006-05-07 20:58:11,723 cherrypy.msg INFO ENGINE: Ctrl-C hit: shutting down autoreloader 2006-05-07 20:58:11,763 cherrypy.msg INFO HTTP: HTTP Server shut down 2006-05-07 20:58:11,823 turbogears.visit INFO Visit Tracking shutting down 2006-05-07 20:58:11,864 turbogears.identity INFO Identity shutting down 2006-05-07 20:58:11,865 cherrypy.msg INFO ENGINE: CherryPy shut down Error in atexit._run_exitfuncs: Traceback (most recent call last): File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs func(*targs, **kargs) File /usr/lib/python2.4/logging/__init__.py, line 1332, in shutdown h.flush() File /usr/lib/python2.4/logging/__init__.py, line 718, in flush self.stream.flush() AttributeError: 'str' object has no attribute 'flush' Error in sys.exitfunc: Traceback (most recent call last): File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs func(*targs, **kargs) File /usr/lib/python2.4/logging/__init__.py, line 1332, in shutdown h.flush() File /usr/lib/python2.4/logging/__init__.py, line 718, in flush self.stream.flush() AttributeError: 'str' object has no attribute 'flush' I think it's related to having no logging directives or anything. When I get this running I think a trac page is definitely in order. This is probably due to changes in logging facilites [1]. Cheers, Simon [1] http://groups.google.com/group/turbogears-trunk/browse_thread/thread/501a6e4e5c952cfc/7049312e45cf4281 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Exception reporting
Great, thanks! Cheers, Simon P.S. let it be known, I always gladly trade buggy pseudo-code for nice docs like these. ;) Robin Haswell wrote: Ah, thanks for the help. I put up a quick trac page at http://trac.turbogears.org/turbogears/wiki/ErrorReporting. There was one other bug in your code, the controller method takes one more parameter: (self, tg_source, tg_errors, tg_exception) Cheers -Rob Simon Belak wrote: Robin Haswell wrote: 2) define a catch-all exception handler: @dispatch_error.when(tg_exception is not None) def notify(self, tg_source, tg_exception): return Holly exception Batman! Cheers, I think I'll go for this option, but it doesn't seem to work properly. Have I done something wrong? [EMAIL PROTECTED]:~/obb$ ./start-obb.py Traceback (most recent call last): File ./start-obb.py, line 26, in ? from obb.controllers import Root File /home/rob/obb/obb/controllers.py, line 33, in ? class Game(controllers.RootController): File /home/rob/obb/obb/controllers.py, line 350, in Game @turbogears.errorhandling.dispatch_error.when(tg_exception is not None) File /usr/local/lib/python2.4/site-packages/TurboGears-0.9a5-py2.4.egg/turbogears/genericfunctions.py, line 20, in when return self._decorate(cond, primary%d % order) File build/bdist.linux-i686/egg/dispatch/functions.py, line 577, in _decorate File string, line 10, in parseRule File build/bdist.linux-i686/egg/dispatch/functions.py, line 440, in parseRule File build/bdist.linux-i686/egg/dispatch/functions.py, line 326, in parse File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 383, in parse_expr File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 378, in build File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 111, in comparison File build/bdist.linux-i686/egg/dispatch/predicates.py, line 576, in Compare File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 378, in build File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 10, in lambda File build/bdist.linux-i686/egg/dispatch/predicates.py, line 58, in Name NameError: tg_exception Sorry, I gave you the wrong name, in 0.9 (and 1.0) it's tg_exceptions (plural). Perhaps this is related to my broken .9a1-.9a5 project? I intend to fix it up soon, but I currently get these errors all over the bloody place (although never on startup, only on shutdown or page load): 2006-05-07 20:58:07,831 cherrypy.msg INFO HTTP: Serving HTTP on http://localhost:8080/ 2006-05-07 20:58:11,723 cherrypy.msg INFO ENGINE: Ctrl-C hit: shutting down autoreloader 2006-05-07 20:58:11,763 cherrypy.msg INFO HTTP: HTTP Server shut down 2006-05-07 20:58:11,823 turbogears.visit INFO Visit Tracking shutting down 2006-05-07 20:58:11,864 turbogears.identity INFO Identity shutting down 2006-05-07 20:58:11,865 cherrypy.msg INFO ENGINE: CherryPy shut down Error in atexit._run_exitfuncs: Traceback (most recent call last): File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs func(*targs, **kargs) File /usr/lib/python2.4/logging/__init__.py, line 1332, in shutdown h.flush() File /usr/lib/python2.4/logging/__init__.py, line 718, in flush self.stream.flush() AttributeError: 'str' object has no attribute 'flush' Error in sys.exitfunc: Traceback (most recent call last): File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs func(*targs, **kargs) File /usr/lib/python2.4/logging/__init__.py, line 1332, in shutdown h.flush() File /usr/lib/python2.4/logging/__init__.py, line 718, in flush self.stream.flush() AttributeError: 'str' object has no attribute 'flush' I think it's related to having no logging directives or anything. When I get this running I think a trac page is definitely in order. This is probably due to changes in logging facilites [1]. Cheers, Simon [1] http://groups.google.com/group/turbogears-trunk/browse_thread/thread/501a6e4e5c952cfc/7049312e45cf4281 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Time running out for Summer of Code!
We are under PSF (Python Software Fundation). Cheers, Simon Petro Verkhogliad wrote: i would like to submit an application. however, i dont see TurboGears as one of the organizations. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: 0.9a5 on python2.3 - anyone have working?
Although we could be nice and make quickstart gnostic about Python versions. Cheers, Simon Kevin Dangoor wrote: Hi Hal, The official stance is that 2.3 is supported, but it's not the encouraged platform. By that, I mean that all code in the turbogears.* package is 2.3 compatible, but the examples and the quickstart templates are geared toward 2.4 users. Luckily, 0.9a5 includes a convenient syntax for decorators, which should make changing a quickstart project a piece of cake. @expose(template=...) becomes [expose(template=...)] We have Phillip Eby and Simon Belak to thank for that little bit of magic. The standard 2.3 way to use a decorator is: index = expose(template=...)(index) which is far less pleasant, and that's the reason why it's not the default for quickstart. Kevin On 5/5/06, hal [EMAIL PROTECTED] wrote: I'm not seeing traffic on this issue, or open trac issues. However, there's at least one obvious bug in a 0.9a5 quickstart generated project (2.4. decorator, rather than 2.3 compatible syntax) which hasn't been reported, so it doesn't feel like anyone is using it. Before I start going through lots of issues - can anyone report success? Is there still demand for this? (My shop is stuck on py2.3 for a while yet) -- Simon Belak vodja projektnih skupin e: [EMAIL PROTECTED] - Hruska d.o.o., agencija za nove medije Ilirska 21, SI-1000 Ljubljana t: +386 1 430 25 86 f: +386 1 430 25 87 s: http://www.hruska.si s: http://akademija.hruska.si (izobrazevalni portal) s: http://www.elor.si (kadrovski sistem letnih razgovorov) Hruska.si - socne resitve To elektronsko sporocilo in vse morebitne priloge so poslovna skrivnost in namenjene izkljucno naslovniku. Ce ste sporocilo prejeli pomotoma, Vas prosimo, da obvestite posiljatelja, sporocilo pa takoj unicite. Kakrsnokoli razkritje, distribucija ali kopiranje vsebine sporocila je strogo prepovedano. This e-mail and any attachments may contain confidential and/or privileged information and is intended solely for the addressee. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail, or any action taken or omitted to be taken in reliance on it, is strictly prohibited. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: 0.9a5 on python2.3 - anyone have working?
Kevin Dangoor wrote: On 06/05/2006, at 12:55, Simon Belak wrote: Although we could be nice and make quickstart gnostic about Python versions. You mean generating different content for each version? In this case I think it'd be better to templatize the [] syntax to make sure quickstarted apps work in both versions. Ick. As cool a hack as it is, I wouldn't want to put the non-standard [] syntax into a Python 2.4 project. Simon's point is valid, though: we can easily make the template wise to the Python version in use. It's worth opening a ticket on. Opened as #837. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: Stacking decorators with []
Works for me. Just to be sure I submitted updated tests to the trunk (r1378). Cheers, Simon Kevin Dangoor wrote: In testing use of the multiple expose decorator style, I discovered that it doesn't look like you can stack [] style decorators. By which I mean: [turbogears.expose(turbogears.tests.simple)] [turbogears.expose(json)] def multiexposejson(self): return dict(title=Foobar, mybool=False, someval=foo, tg_html=turbogears.tests.simple) If I'm correct, then the [] is not very useful with the number of decorators TG now offers. Kevin -- Kevin Dangoor TurboGears / Zesty News email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: json via multi expose
Alberto Valverde wrote: On 05/05/2006, at 13:04, Kevin Dangoor wrote: It's funny... I didn't realize that Alberto had written a failing test for this already! One of us will need to fix this soon. I tried to use the new multiple expose style in a revised 20 Minute Wiki video and ran into this very problem. For now, I may just go with allow_json=True. To be honest, the new expose() has given me so many headaches I've resorted to allow_json=True when I want json. I'm not sure if it's a bug, but allow_json=True is silently ignored if I override the template in the controller's body by sending 'tg_template' in the returned dict. I like to return json from the same controller methods which normally render HTML because it avoids duplicating code, so this is a problem because to reuse Controller subclasses I use something similar to fastdata which can accept template paths in it's init args and then sends tg_template. I managed to work around this by inspecting cherrypy.request.params but I find it somewhat ugly and prone to break as soon as some internal implementation details are changed. My question is: What advantages does the new expose *really* offer?, when I say *really* I mean advantages that really work. It looks to me that all the generic function's goodness is hidden because you cannot actually pass arbitrary logical expressions to expose. Enough rant for now :) The bottom line is that I agree that this should be fixed somehow. I really feel uneasy about having undocumented, semi-broken code at expose I talked to Elvelind and he promised he will clean it up as soon as he finds some time. Either way this needs to be fixed before 1.0. It seems the relevant function for specifying custom specialisations gets binded to attribute _expose. For example: @expose() def foo(): pass @foo._expose.when(...) def output_goodness(_func, accept, allow_json, allow_json_from_config,*args, **kw): pass Mind you, I haven't tested this. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Serving binary data.
What (type) are you returning exactly? Cheers, Simon mulicheng wrote: In the latest TurboGears, I started having this exception: AssertionError: Method Root.tile() returned unexpected output. Output should be of type basestring, dict or generator. The tile method referenced is serving a dynamic image. The image is served correctly but the new assertion is an annoying addition to the logging messages. Am I missing a setting for serving dynamic content other than strings, dics, or generators.. or is this something that still needs to be addressed? Looking into the turbogears/controllers.py, I didn't see a way to bypass this assertion. Perhaps there is a generator available already for binary data but I'm not seeing that in the TG docs. My setup: * kid 0.9.1 * TurboKid 0.9.5 * simplejson 1.3 * PasteScript 0.5.1 * TurboJson 0.9.2 * RuleDispatch 0.5a0.dev-r2100 * setuptools 0.6a11 * CherryPy 2.2.1 * elementtree 1.2.6 * Paste 0.4.1 * ConfigObj 4.3.1 * cElementTree 1.0.5-20051216 * Cheetah 1.0 * TurboGears 1.1a0dev-r1377 * SQLObject 0.7.1dev-r1457 * PasteDeploy 0.4 * PyProtocols 1.0a0 * FormEncode 0.5.1 * nose 0.8.6 Thanks Dennis --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Summer of Code - SQLAlchemy schema migration
jvanasco wrote: aprprove this application, please please please Will try. ;) Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: #719 Pagination decorator, easy pagination and sorting
Kevin Dangoor wrote: On 4/30/06, Simon Belak [EMAIL PROTECTED] wrote: Should this go into the official distribution? I like it (although it could do with some refactoring). There have been a few pagination approaches submitted along the way, and I *do* think it's a good thing to include. However, I just hadn't decided on an approach to take because there are always tradeoffs and I haven't played with them enough to know which api feels right. This one looks like a reasonable implementation, though. One thing that can throw people off: the query is re-run every time. This is very different from a typical search engine scenario where the list of results is held on to and paging is done through that (ensuring a consistent view of the data). It depends on your data set (and how often it changes) whether or not that matters. This does also require 2 queries to retrieve the data on every hit. All of that aside, this API does look friendly and complete enough that I think we can take it. Maybe we can get him to provide different schemas for data retrieval? Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: 'tg_exception' in errorhandling in .9a5 out of sync with branch 1.0
Jorge Godoy wrote: Em Terça 02 Maio 2006 18:11, Alberto Valverde escreveu: Confusion gone :) Happy me! More beautiful with peace the world is. ;-) (Maybe I should stop watching Star Wars...) I'm a bit late, so let me just rehash what has already been said. New exception handling was intentionally commited as a trunk-only feature. It will probably undergo some more changes as I am not convinced it is pulling it's own weight. However if there is general consensuses that the new tg_exception should get released in 1.0, I have no problem with that. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: raising an error
Alberto Valverde wrote: On 02/05/2006, at 19:16, jvanasco wrote: i've just discovered that exception_handling only works on exposed methods i'm not sure if this is a feature or a bug. i'd hope a bug. AFAIK exception_handler only binds rules to the method it decorates for errorhandling.try_call to catch and dispatch. If you need this functionallity for non exposed methods you could write a decorator that wrapped your function so it gets called by try_call. True. Historically there was just error handling so it made sense to work only with exposed methods. For First Class I am thinking of decoupling error handling from TG and make it a stand alone WSGI application/layer. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Summer of Code project idea
Try and see how it goes. It shouldn't take to long to rewrite what you posted here into a nice proposal, so you don't have much to loose. I suggest concentrating on what you can give back to the Python community as this will be the critical point in accepting your application. Cheers, Simon Mark Prokosch wrote: Hi, I know it's been done. I dont claim it's something new. I still think it's cool to do it using TurboGears and if the user experience is rich enough it could be better than the competitors. The technology is a little different - it's not a firefox extension and its not a frame. It has the potential to work on other browsers. So, the question still stands: is it an appropriate SOC project and is someone willing to mentor it? Thanks, Mark --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] #719 Pagination decorator, easy pagination and sorting
Should this go into the official distribution? I like it (although it could do with some refactoring). Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Attention Summer of Code prospective participants!
It is 1st of May! Good luck with your applications. We are ideally looking for 4-6 projects. Cheers, Simon Kevin Dangoor wrote: As of right now, I know that we have at least one mentor approved. Students can start applying on May 1. I'd recommend that people start working on their proposals ASAP. Be sure to read the student FAQ: http://code.google.com/soc/studentfaq.html#2 There's a page on the wiki for people to use for coordination, and some project ideas are there: http://trac.turbogears.org/turbogears/wiki/SummerOfCode SQLAlchemy schema migration tools are at the top of my love to see list. I think that's a good size for a project (hint: don't try to do fully automated migrations). Good luck! Kevin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] IRC logger
It would be useful to have an IRC logger like Django [1]. Cheers, Simon [1] http://simon.bofh.ms/logger/django/2006/04/15/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: r1279 (breaks third-party decorators)
Jorge Godoy wrote: Em Sexta 28 Abril 2006 17:26, Kevin Dangoor escreveu: On 4/28/06, Simon Belak [EMAIL PROTECTED] wrote: Kevin Dangoor wrote: I intend to make some changes to not burden people who do not need 2.3 compatibility (see Jorge's example) and than merge with a5. Commited into 1.0 branch as 1290. I tried a quick test of it. Looks good! And works with legacy decorators ;-) One just has to from turbogears.decorator import simple_decorator as decorator and he can keep using the old syntax. Simon did a great job with this compatibility layer! Really good! Just to clarify, simple_decorator and family are not intended solely for backward compatibility, my main motivation was reducing boilerplate and not have the user adjust to the framework but vice versa. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] #803 ExtendingVisitFramework
Ticket #803 seems interesting: http://trac.turbogears.org/turbogears/ticket/803 Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Theory: an XML Model library, styled after SQLObject
Evolving something like this into a fully-fledged model provider would be a cool SoC project. Cheers, Simon Carlos Ribeiro wrote: On 4/28/06, *Sean Jamieson* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: What I have in mind is a way to model your XML document in terms of python classes, much like SQLObject does with relational tables. A long time ago I've explored this kind of declarative programming. There was a project started at the time, we used to call it metatemplate. It was a framework which could be used to write any kind of hierarchical data structure using plain Python classes. There are some notes at: http://pythonnotes.blogspot.com/2004/10/metatemplate-generic-data-templates-in.html and there is evena project started at Python-Hosting for it: http://metatemplate.python-hosting.com/wiki I'll probably go about trying to write this reguardless, but given some positive feedback from the list, I may be more motivated. And I am wondering if this would be a welcome addition to turbogears. Feel free to use my code as a starting point. I'm willing to resume working, I just need someone to push me a little bit :-) so if you wanna to... drop me a note. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: r1279 (breaks third-party decorators)
Kevin Dangoor wrote: On 4/27/06, Simon Belak [EMAIL PROTECTED] wrote: In r1279 I added support for alternative decorator syntax as used by PEAK to lessen the anguish of people still on Python 2.3. This unfortunately requires a bit different application of decorator() function. I have one other question about this: is there any perceptible difference in startup time? startup time is actually somewhat important, because the user has to sit through that startup time every time they make a change to their code during development. I'd rather not dramatically slow down use for Py2.4 users. If there isn't a big startup cost, then this is a really nice change for 2.3 users (and those of use working on TG itself!) Penalty is a couple of function calls per decorator. Nothing wild. I intend to make some changes to not burden people who do not need 2.3 compatibility (see Jorge's example) and than merge with a5. Cheers Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: line endings
It seems I am the biggest offender. :( Sorry, upgraded my text editor recently and forgot to set default line-ending style. Cheers, Simon Kevin Dangoor wrote: I got a couple conflicts trying to merge from 1.0 to trunk and it looks like test_errorhandling at least has some bad line endings that my editor graciously corrected, but now I need to merge. (And it's harder for me to know if I just take everything since work has begun on the trunk). So, just a reminder to keep your editors set for spaces and unix-style line endings. thanks, Kevin -- Kevin Dangoor TurboGears / Zesty News email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: r1279 (breaks third-party decorators)
Jorge Godoy wrote: Em Sexta 28 Abril 2006 12:04, Simon Belak escreveu: Forgot to mention, decorator() and weak_signature_decorator() expect a closure. In your case def mensagem_json(): def entangle(func): def caller(func, *args, **kwords): print # return caller return weak_signature_decorator(entangle) @mensagem_json() def ... should do the trick. It didn't. As of 1285 two new decorator factories are available: simple_decorator() simple_simple_weak_signature_decorator() which work as before (apply to caller, no Py2.3 compatibility). They still give me errors. Second is with simple_weak_signature_decorator. [EMAIL PROTECTED] ~/empresa/clientes/latam/Site-Amostras % ./start-siteamostras.py Traceback (most recent call last): File ./start-siteamostras.py, line 26, in ? from siteamostras.controllers import Root File /home/godoy/empresa/clientes/latam/Site-Amostras/siteamostras/controllers/__init__.py, line 18, in ? from siteamostras.controllers.toxicologia import Toxicologia File /home/godoy/empresa/clientes/latam/Site-Amostras/siteamostras/controllers/toxicologia.py, line 24, in ? from siteamostras.controllers import analises File /home/godoy/empresa/clientes/latam/Site-Amostras/siteamostras/controllers/analises.py, line 24, in ? from siteamostras.decorador import mensagem_json File /home/godoy/empresa/clientes/latam/Site-Amostras/siteamostras/decorador.py, line 18, in ? @decorator() TypeError: simple_decorator() takes at least 1 argument (0 given) [EMAIL PROTECTED] ~/empresa/clientes/latam/Site-Amostras % ./start-siteamostras.py Traceback (most recent call last): File ./start-siteamostras.py, line 26, in ? from siteamostras.controllers import Root File /home/godoy/empresa/clientes/latam/Site-Amostras/siteamostras/controllers/__init__.py, line 18, in ? from siteamostras.controllers.toxicologia import Toxicologia File /home/godoy/empresa/clientes/latam/Site-Amostras/siteamostras/controllers/toxicologia.py, line 24, in ? from siteamostras.controllers import analises File /home/godoy/empresa/clientes/latam/Site-Amostras/siteamostras/controllers/analises.py, line 29, in ? class Analises(controllers.Controller): File /home/godoy/empresa/clientes/latam/Site-Amostras/siteamostras/controllers/analises.py, line 213, in Analises @turbogears.expose() TypeError: entangle() takes exactly 1 argument (0 given) [EMAIL PROTECTED] ~/empresa/clientes/latam/Site-Amostras % I would however very much appreciate if you could also try to make the new weak_signature_decorator() work with your code, just to make sure before I apply these changes to a5. Thanks! I'm trying that for hours :-) May I send you my decorator off list so that you take a look and see what I'm doing wrong? :-) Please do. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: r1279 (breaks third-party decorators)
Kevin Dangoor wrote: I intend to make some changes to not burden people who do not need 2.3 compatibility (see Jorge's example) and than merge with a5. Commited into 1.0 branch as 1290. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: end of day again, but good stuff tomorrow
Roger Demetrescu wrote: Cool !!! :) Kevin, does #750 have any chance to be in 0.9a5 ? Well, there are others, but not so critical, like #768 ... ;) +1 Both patches apply cleanly for me with no tests failing. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: end of day again, but good stuff tomorrow
Simon Belak wrote: Roger Demetrescu wrote: Cool !!! :) Kevin, does #750 have any chance to be in 0.9a5 ? Well, there are others, but not so critical, like #768 ... ;) +1 Both patches apply cleanly for me with no tests failing. And while we are at it why not #790 (trivial), fits nicely with the theme of making life essayer for Py2.3 folks. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: r1257 (potentially breaks error handling and failsafe)
Ups, forgot to commit decorator.py. Fixed in r1260. Sorry for the inconvenience. Cheers, Simon Jorge Godoy wrote: Em Quarta 26 Abril 2006 18:40, Simon Belak escreveu: Hi, I would just like to highlight some (breaking) changes I made in r1257. For now all are intended for First Class, if we decide anything should be released beforehand I will merge than (I hope this covers me from Michelle's wrath ;)). 1) Fail-safe mechanism is uncoupled from error handling and validate() decorator. Some examples can be had in test_errorhandling.py (should probably refactor as well), I will update the docs soon (on sprint at the latest). 2) tg_exceptions is renamed to tg_exception and is in fact no longer an exception as such, but a tuple compatible with what sys.exc_info() returns. (it should be possible to do some pretty sick things with stack manipulation now ...) Hi Simon. I believe that your changes breaks the expose decorator: === File /home/godoy/empresa/clientes/latam/Site-Amostras/siteamostras/controllers/analises.py, line 213, in Analises @turbogears.expose() File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/util.py, line 200, in entagle signature=(argnames, varargs, kwargs, defaults))(func) TypeError: decorator() got an unexpected keyword argument 'signature' === Here's the offending function (with its 'svn blame' output): === 760 simon def bind_args(**add): 807max Call with arguments set to a predefined value. 807max def entagle(func): 1257 simon argnames, varargs, kwargs, defaults = getargspec(func) 1257 simon defaults = list(ensure_sequence(defaults)) 1257 simon defaults = [d for d in defaults if 1257 simon argnames[-len(defaults) + defaults.index(d)] not in add] 1257 simon argnames = [arg for arg in argnames if arg not in add] 1257 simon 807max def bind_args(func, *args, **kw): 1257 simon return inject_call(func, add, *args, **kw) 1257 simon return decorator(bind_args, 1257 simon signature=(argnames, varargs, kwargs, defaults))(func) 760 simon return entagle 760 simon === And here's the signature of this function: === @turbogears.expose(html=siteamostras.templates.form_generico) @identity.require(identity.conditions.in_group(latam_ver)) def analises(self, **kword): === Also, now I have: === Ran 170 tests in 25.538s FAILED (failures=6, errors=66) === --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Attention Summer of Code prospective participants!
Sylvain Hellegouarch wrote: How's Python support for decorators on these versions? I know that Jython lags considerably behind CPython and last time I saw was the equivalente of CPython 2.2 (without packages written in C...). I don't know to be honest but this is a very good question. Nevertheless I do believe it would be a great boost for any project to be the one that can run on IP and Jython. That would also bring lots of new users. Absolutely, added among ideas. Thanks! Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Attention Summer of Code prospective participants!
Kevin Dangoor wrote: On 4/27/06, Gerhard Häring [EMAIL PROTECTED] wrote: Sylvain Hellegouarch wrote: I don't know to be honest but this is a very good question. Nevertheless I do believe it would be a great boost for any project to be the one that can run on IP and Jython. That would also bring lots of new users. I don't think that's relevant to TurboGears here. If somebody is on the Java or .NET platform they'll most likely using the web technologies native to that platform (Java servlets or ASP.NET), even if they chose to use the Python language. I agree. I think TurboGears would gain far more users by putting more effort into making web app development easier, than it would by supporting Java and .NET directly. I disagree. Being able to sneak TG into a Java or .NET enterprisey mess would be great, making TG a great option for high profit consonancy gigs. Maybe it would not extend our user base, but it would certanly fill our bank accounts. ;) Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: TG-Content, a Pythonic CMS
Looks mighty fine! Cheers, Simon Matthew Bevan wrote: Howdy, all! Well, it's nearing completion (just need to finish the shopping cart, really) and is working without a hiccup on a just-slightly-pre 0.9a3 version of TG. Soon I'll be able to SVN up and see what breaks... I'm sure plenty will! Here are a few screenshots of my '0.5' version in action: Site Front Page: http://flickr.com/photos/gothcandy/135991895/ Modifying Site Folder: http://flickr.com/photos/gothcandy/135991896/ Front Page Properties: http://flickr.com/photos/gothcandy/135991897/ Modifying Front Page: http://flickr.com/photos/gothcandy/135991898/ Accented Language Test: http://flickr.com/photos/gothcandy/135991899/ Japanese Language Test: http://flickr.com/photos/gothcandy/135991900/ I'll be putting out a release as soon as the cart is stable and can send e-mail notifications of purchase. I'll probably wait until the next official release before upgrading TG, though expected breaks include: - Identity - TG Extensions Interface - SQLObject - It'll do it somehow. ;^) Though, hopefully, CatWalk will work better. The version I'm currently using doesn't seem to want to display a list of rows, and when displaying a specific row's data, looses the top tabs to navigate away with. Very strange! - Matthew --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] r1257 (potentially breaks error handling and failsafe)
Hi, I would just like to highlight some (breaking) changes I made in r1257. For now all are intended for First Class, if we decide anything should be released beforehand I will merge than (I hope this covers me from Michelle's wrath ;)). 1) Fail-safe mechanism is uncoupled from error handling and validate() decorator. Some examples can be had in test_errorhandling.py (should probably refactor as well), I will update the docs soon (on sprint at the latest). 2) tg_exceptions is renamed to tg_exception and is in fact no longer an exception as such, but a tuple compatible with what sys.exc_info() returns. (it should be possible to do some pretty sick things with stack manipulation now ...) Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: r1257 (potentially breaks error handling and failsafe)
Michele Cella wrote: Oh, and please Michele (one L not two, only Roger calls me Michelle) :D Shit. And I knew that. Sorry. Tell you what, call me Simoon a couple of times and we'll call it even. ;) Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: vexed by decorators in TG
You could also try metaprogramming (probably the most Pythonic solution): def make_saver(form): @expose() @validate(form=form) def save(): ... return save class MyController(Controller): saveThisTypeOfElement = make_saver(ThisTypeForm) saveThatTypeOfElement = make_saver(ThatTypeForm) ... Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: vexed by decorators in TG
You could try writing a custom validation Schema that will select the
appropriate form (you get type as argument) and call it's validate().
Cheers,
Simon
P.S. I smell another (don't worry Jeff, it would be optional ;))) use
for generic functions
Roger Rohrbach wrote:
I'm trying to refactor a controller that adds objects to the database,
following the DRY (Don't Repeat Yourself) principle. I've got:
class Add(controllers.Root):
...
@validate(form=ThisTypeForm)
def saveThisTypeOfElement:
# do what's needed to save an object of ThisType in the
database
@validate(form=ThatTypeForm)
def saveThatTypeOfElement:
# do what's needed to save an object of ThatType in the
database
It turns out that the method bodies can be the same; the only
difference is the form--the two objects have different attributes,
validation requirements etc. I want something like:
class Add(controllers.Root):
...
@validate(form=???)
def saveElement(type):
# do what's needed to save an object of type 'type'
You see my dilemma: the decorator needs to know which form to associate
with the method, but that depends on the method's 'type' argument. I
can't, for example, call a function:
@validate(form=getForm('type'))
since 'type' is not defined when the decorator is applied. I can't use
a callable:
@validate(form=getForm)
because the callable really needs a 'type' argument to get passed at
runtime.
Am I just completely missing the point here? Surely there's a way to
associate the correct form with my method at runtime?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[TurboGears] Re: Identity Introspection
Oops, the first option was incroect/buggy, but the second should work. See tests attached. Cheers, Simon Jeff Watkins wrote: On 23 Apr, 2006, at 12:10 pm, Simon Belak wrote: Either add it to func within (inner) require(), or to the result of decorator(): newfunc = decorator(require)(fn) newfunc._require = ... return newfunc I was doing it exactly as you demonstrate and I couldn't access the _require attribute from the tests. -- Jeff Watkins http://newburyportion.com/ Just because you have the right to do something, doesn't mean it's the right thing to do. -- Fred Friendly, former president of CBS News --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- test_decorator_attr.py Description: application/python
[TurboGears] Re: Identity Introspection
Either add it to func within (inner) require(), or to the result of decorator(): newfunc = decorator(require)(fn) newfunc._require = ... return newfunc Cheers, Simon Jeff Watkins wrote: Simon, I've been trying to add this feature and it doesn't seem to work correctly. The require decorator is presently defined as: def require(predicate, obj=None): ''' Function decorator that checks whether the current user is a member of the groups specified and has the permissions required. ''' def entangle(fn): def require(func, self, *args, **kwargs): try: errors= [] if predicate is None or \ predicate.eval_with_object(current, errors): return fn(self, *args, **kwargs) except IdentityException, e: errors= [str(e)] raise IdentityFailure(errors) return decorator(require)(fn) return entangle I've tried adding a _require attribute to entangle or the internal require, but in neither case is it visible as part of the decorated method. The magic seems to have failed. Any idea what I might be doing wrong? On 18 Feb, 2006, at 5:38 am, Simon Belak wrote: Jeff Watkins wrote: Wow. That's a really interesting idea. I could easily expose the permission predicate that the require decorator is using, however, I don't think that would work, because later decorators would hide that information. Anyone with deeper Python-fu who'd like to make a suggestion? Depends how you intend to expose it. It should work if you make it an attribute (as long as everyone is using well behaved decorators). We can of curse also tweak the decorator library if you have any special needs (preferably in a way useful to others as well). Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Generic functions
Seeing a positive correspondence between people who disdain generic functions and people who do not know what exactly generic functions are, I decided to write a little primer in hopes FUD propagation will make way for an augmented discussion. --- Somewhat simplified, generic function is a set of functions bound to a single symbol. Where things get interesting is how a particular function* (let's call it specialisation) gets selected (dispatched). The process is usually deterministic, following a set of rules. Three predominant dispatch strategies are: 1) type dispatch (also called multiple dispatch and overloading) A function is selected depending on types of arguments passed. Examples: C, Py3k?, PyProtocols.dispatch.on 2) identity dispatch Usually used in conjunction with type dispatch A function is selected depending on concrete instances of arguments passed. Examples: CLOS 3) predicate dispatch A function is selected depending on arbitrary (logical) expressions. Examples: Cecil, Mathematica, PyProtocols.distpatch.generic The aforementioned rules usually also establishing a selection hierarchy (more specific is often the governing relation) to reduce ambiguity. While having more than one applicable specialisation may seem like a bad thing, it can actually be very useful. Enter function combination. Strictly speaking function combination is not a part of generic functions, therefore let's limit the scope to what PyProtocols (and CLOS) offer us. The simplest combination strategy is allowing the selected specialisation to call the next most specific specialisation. What makes function combination transcend generic functions are secondary functions. These allow us to define (generic) functions that get called automatically in relation to another function (called primary). Hence we can have secondary functions be called before, after or around (same as composition) a primary function. Some common misconceptions: 1) Generic functions are an alternative to normal (Java) OOP False. Message passing is nothing more than type dispatch on first (implicit) argument. 2) There is nothing I can't do without generic functions True, however considering lambda calculus (or Turing completeness) this can be said for most language constructs. References: http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html http://peak.telecommunity.com/DevCenter/CombiningResults http://en.wikipedia.org/wiki/Multiple_dispatch http://en.wikipedia.org/wiki/Generic_functions * term method is often used Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Generic functions
Tim Lesher wrote: On 4/23/06, Simon Belak [EMAIL PROTECTED] wrote: 1) type dispatch (also called multiple dispatch and overloading) A function is selected depending on types of arguments passed. Examples: C, Py3k?, PyProtocols.dispatch.on I think you meant to say C++, not C. Yes, of course. In any evernt, your primer is rather lopsided. If your goal is really education rather than advocacy, you'd note the drawbacks of using generics. There are more than one, and if you really understand generics, then you can probably enumerate them. Yes, there are, but all are mostly implementation specific. To me, the biggest drawback is their resistance to static analysis (the human kind!). True, Python already has features that make static analysis difficult, but there's no reason to make the problem worse if you don't have to. I assume we are talking about border cases where function resolution order is not clear. Yes, it is harder, however why would you want to do static human analysis in a dynamic language? Fire up an interpreter prompt and experiment. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Generic functions
Tim Lesher wrote: On 4/23/06, Simon Belak [EMAIL PROTECTED] wrote: I assume we are talking about border cases where function resolution order is not clear. That's one situation, but... Yes, it is harder, however why would you want to do static human analysis in a dynamic language? Fire up an interpreter prompt and experiment. The bigger problem is that in a interpreter, it's often difficult to duplicate the conditions that are prevalent during runtime of a large Python application. This is less a problem with the theory of generic functions (which is mathematically sound, of course), than with their implementation and use in Python. In my experience, interactive live development is a lot harder in Python environments that it is in Lisp or Smalltalk environments, simply because many Lisp and Smalltalk applications are _designed_ to be developed in this way: they are usually comprised of smaller functions, with less state and fewer side effects (pre-optimization, of course), and their standard libraries support that idiom very well. On the other hand, Python applications tend to be a mixture of C-style procedural libraries (mostly because of the C-runtime-flavored Python standard library), C++ and Java-style object-oriented classes, and a small slice of functional programming. That makes them harder to debug than either environments based on functional languages (where a live REPL is often sufficient for most,but not all, debugging) or C-like environments (where static analysis is often sufficient for most, but not all, debugging). This isn't an anti-Python rant (although it's starting to smell like one!). My opinion is that generic functions are harder to work with in Python than they are in the environments from whence they originated (due to the environment, not the functions themselves), and for that reason, they can't be used as lightly as they are in their native habitats. Can't argue with that, however as an avid (smug ;)) Lisper I would much rather TG moves towards a live environment (where it belongs) than to relinquish my toys, erm I mean powerful tools. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: advanced form processing / internal redirect ?
I'm probably missing something very obvious, but why not just call that method passing _data_ along? Cheers, Simon jvanasco wrote: i couldn't find the answer to this in the wiki or the group example: @validate(form=registration__form) @error_handler(registration) @expose(template=templates.registration__success) def registration_save(self, **data): return dict( user_email = data['email'] ) should the form be validated, i'm not going to go into a direct 'success' . my flow is really this: validate form process form - lookup email. if its registered, push to a different controller / function ( registration__failure__exists ) process form - attempt to register email. if it fails, push to a different controller / function ( registration__failure__sql ) process form - attempt to send verification email. if it fails, push to a different controller / function ( registration__failure__sql ) actual sucess - either push the template as-is , or possibly better , this controller has no template and we redirect to a registration__success controller instead does anyone have a suggestion on how to do this, or a better approach? the only thing i could find similar was a reference to the identity framework. in it, we have this line based on a failure url cherrypy.InternalRedirect.__init__(self, url) i think, however , that a) there has got to be some sort of TG abstraction of this, so I'm not using cherrypy directly ( i have no issue with that, other than i'd like to stay within TG if possible ) b) there must be some way to do this without having an exposed url ( ie: i don't want register_fail to be accessible, just be a function called from register_save ) c) there is a more TG-esque way of this than I am thinking of I've been combing through Fasttrack and Docudo looking for potential implemtnations, but no luck. the only thing i've found is turbogears.redirect() which seems to be an external redirect --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: advanced form processing / internal redirect ?
jvanasco wrote: i'm on day3 of TG. i'm the one missing many things obvious. if i call the method, how do i get the template into the method and not have that method exposed? ( i'm under the impression that the only way to set the template is in the expose argument ) if you can answer that, my problems are solved. You may want to try returning a dict with key tg_template. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: done [Re: Widgets: template_vars, retrieve_javascript/css and validate...]
Michele Cella wrote:
Simon Belak wrote:
Would util.call_on_stack() help against infinite recursion?
mmm, I never used it but IIRC you're using it inside controllers.py to
avoid infinite recursion, what parameters should I use? I want to give
it a try or if you want you can go ahead and fix widgets/base.py to use
it inside __getattribute__ no problem. ;-)
Thanks Simon I was pretty sure to get a reply from you. :D
You recall correctly, just to recapitulate:
call_on_stack(func_name, kw, start=0)
Check if function named func_name has already been called with partial
arguments kw starting start frames bellow the one from where the
call to call_on_stack has been made.
For example:
def foo(x,y,z):
return call_on_stack(foo, {x:1})
foo(1,2,3) = True
Cheers,
Simon
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[TurboGears] Re: Developing stuff with TurboGears
Elver Loho wrote: On 4/18/06, Michele Cella [EMAIL PROTECTED] wrote: No, 0.9 is already feature freezed (the focus is: bug fixing, doc and polishing existing things) and 1.0 will not be any different than 0.9 since the latter will become 1.0 when Kevin is happy with every aspect of it. What does that mean? Does feature freeze mean that there will be widgets and identity and sqlobject and ... or does it mean the APIs for widgets and identity and sqlobject and ... have been frozen? Latter. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Fwd: [Web-SIG] [Fwd: Summer of Code preparation]
ajones wrote: Karl Guertin wrote: On 4/17/06, Igor Murashkin [EMAIL PROTECTED] wrote: Sooo, anyone want to mentor us CS students? :) You don't want my mentoring! Mine either, but it would be nice to see some turbogears related stuff happen. Some of the ideas I have had: * Google/Yahoo/Whatever widget library: Would be nice to be able to supply a widget with the appropriate account information and have support for maps/adsense/whatever integration from inside turbogears. At the upper limit of the idea it would essentially be from mashup import *. * SQLObject schema interpreter: Reads pre-existing tables and generates SQLObject classes based on their contents. Probably not possible to make it 100% accurate, but it would be a nice headstart. * Database schema versioning: Similar to Ruby on Rails migrate system. Basically allow for alterations to be made to an existing database according to migrate rules. This obviously would require that SQLObject be capable of altering existing tables. (Is it? Has it always been able to? I don't know) * TurboGears documentation: Mwuhahaha mwuhahahaha the perfect inter^W student project. Seriously though it could be a decent project if it involved development work on Docudo. Anyone else have ideas? Who wants to badger Kevin into seeing if he will find/be a mentor for this? How about creating a specification similar to our template protocol for widgets and separate them from TG core. This would be beneficial to the whole Python web community (and a step closer to a franken-framework that not just kicks but pulverises ass ;)). Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Fwd: [Web-SIG] [Fwd: Summer of Code preparation]
Jonathan LaCour wrote: Kevin Dangoor wrote: FYI, Google's Summer of Code is on. If you have interesting project ideas and want to mentor someone, check it out! FWIW, I would be happy to mentor someone in an effort to make SQLAlchemy support a reality in TurboGears. This would include: finishing up ActiveMapper, improved support in TurboGears (widgets, catwalk, etc), and potentially an SQLObject compatibility layer or model converter utility. Anyone else think that this is a good idea? Anyone else interested in helping mentor such a thing? +1 I am also willing to (help) mentor TG-related projects. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Continuations, and the web, and you!
Elver Loho wrote: So, anyhow, I was playing around a bit and came up with this crap. What's it good for? http://elver.cellosoft.com/2006/04/15/persistent-user-classes-with-turbogears/ Cool shit! Have you considered combining generators with CPS? This way all the state changes could be represented by a list of continuations still to be evaluated. Either way, Would you mind adding it to the recipes in trac? Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: Widgets: template_vars, retrieve_javascript/css and validate...
Michele Cella wrote: Hi guys, I would like to hear your opinion on these things: 1) We have the nifty template_vars attribute that let's us pass values at class, construction and display time without the need to implement a single line of code. While writing some widgets I have noticed that I would like to use it even for some parameters that I need but that at the end will not end up to be used inside the template (an example is the disabled_fields parameter for a form), in other case the name used in the template is the same as the one in template_vars but the content of the variable is not exactly the same. So I'm wondering should we rename template_vars to a more generic name? parameters perhaps? the reason is that I avoid using template_vars if the attribute used is not directly present inside the widget template since the relation between template_vars and template is being lost in this case. +1 Perhaps tg_args (since Python uses the term argument)? Or should we introduce another type of magic attribute like this one to manage those case? something like other_parameters (better name)? this one will automatically remove things from the dict after update_data has finished, but it's not my preferred one since we will need to explain the difference between this, template_vars and also member_widgets for compounds. -1 Sounds too complicated. 2) I would like to rename some of the generics methods we are using to make it clear that you can use any type of object that provides those methods, just like in python you can provide a custom iterable with a proper __iter__ method, so that's what I'm proposing: retrieve_javascript - __javascript__ retrieve_css - __css__ validate - __validate__ +1 We should gather all informal protocols and apply a consistent naming-scheme. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: IdentityMangement - troubles
Take a look at turbogears.util. There are a bunch of functions there that deal with functions and their arguments. adapt_call() or has_arg() are probably your best bet. Cheers, Simon Jeff Watkins wrote: Good catch. That certainly would be confusing. Is there some way I can check whether the final method is expecting a user_name and password parameter? I don't want to cause an exception... On 12 Apr, 2006, at 8:18 am, Patrick Lewis wrote: I think the problem is when IdentityVisitPlugin.identity_from_form pops the user_name and password fields off of the form. Catwalk then doesn't have those parameters on to sqlobject, and the exception is raised. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: error_handling dispatch problem?
Brain fart, sorry. Fixed in [1127].
Cheers,
Simon
Max Ischenko wrote:
I updated to r1122 and now when an exception occurs inside my controller I
got this error instead of plain traceback.
Can anyone confirm?
Page handler: bound method ItemViewer.default of
bookswap.controllers.ItemViewer object at 0x01711330
Traceback (most recent call last):
File
c:\python24\lib\site-packages\cherrypy-2.2.0-py2.4.egg\cherrypy\_cphttptools.py,
line 106, in _run
self.main()
File
c:\python24\lib\site-packages\cherrypy-2.2.0-py2.4.egg\cherrypy\_cphttptools.py,
line 255, in main
body = page_handler(*virtual_path, **self.params)
File string, line 3, in default
File d:\projects\3rd-party\turbogears\turbogears\controllers.py, line
206, in expose
output = database.run_with_transaction(expose._expose,func, accept,
allow_json, allow_json_from_config,*args, **kw)
File d:\projects\3rd-party\turbogears\turbogears\database.py, line 216,
in run_with_transaction
retval = func(*args, **kw)
File string, line 5, in _expose
File d:\projects\3rd-party\turbogears\turbogears\controllers.py, line
227, in lambda
expose._expose.when(rule)(lambda _func, accept, allow_json,
allow_json_from_config,*args,**kw: _execute_func(
File d:\projects\3rd-party\turbogears\turbogears\controllers.py, line
248, in _execute_func
output = errorhandling.try_call(func, *args, **kw)
File D:\Projects\3rd-party\turbogears\turbogears\errorhandling.py, line
81, in try_call
output = dispatch_error(self, func, None, e, *args, **kw)
File string, line 5, in dispatch_error
File _speedups.pyx, line 362, in _speedups.BaseDispatcher.__getitem__
File
C:\Python24\lib\site-packages\ruledispatch-0.5a0.dev_r2100-py2.4-win32.egg\dispatch\interfaces.py,
line 15, in __call__
NoApplicableMethods: ((bookswap.controllers.ItemViewer object at
0x01711330, function default at 0x016CEBF0, None,
dispatch.interfaces.NoApplicableMethods instance at 0x0178AC10,
('2dtwqskf7iek5yqc', 'edit'), {'pst': 'su5ikl5y3c089vax0waox5zp'}), {})
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[tg-trunk] Re: providing default error handler: how to get the traceback?
I'll look into it. However the main problem is the traceback is not a property of the exception but a completely separate entity. What I will probably do is wait for First Class (to become trunk) and than change [each item of] tg_exceptions to a tuple similar to what sys.exc_info() returns and add some automatic cleanups. If you are in dire need, I can conjure up a proof of concept before that. Cheers, Simon Max Ischenko wrote: Hi, My post is mostly for Simon. I want to intercept all application errors that normally results in CherryPy's 500 Internal Error page to save error info and display it differently. My error handler defined like this: @dispatch_error.when(tg_exceptions is not None) def notify_on_error(controller, tg_source, tg_errors, tg_exceptions, *args, **kw): # record error and format for display return 'FAIL' The problem is that I cannot get to the traceback I usually see on 500 error page. The tg_exception is just an exception, sys.exc_info() and traceback.extract_stack() both give different tracebacks, unrelated to the source of error. Adding print stmts to try_call at errorhandler.py shows that orginal traceback is there but then (I guess) discarded. If I'm missing something, please explain how I can access original traceback. If it cannot be accessed please fix error handling so I can access it. ;) May be add another argument like tg_traceback to dispatch_error? Max. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: providing default error handler: how to get the traceback?
Max Ischenko wrote: I'll look into it. However the main problem is the traceback is not a property of the exception but a completely separate entity. That's true. But the error handling code seems to be messing it up. Actually, it doesn't mess it up, it just catches the exception, removing any guaranties that the caught exception is the last in the execution path (making exc_info() and relatives inconsistent). Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: o3 magazine wants TurboGears articles
Kevin Dangoor wrote: o3 magazine (http://www.o3magazine.com) is a nice looking, widely circulated PDF-format magazine covering open source topics. The founder of the magazine has asked me about running a TurboGears-focused issue, which I think would be a good thing. We have no shortage of things we can cover. Their current way of working is to give a free ad to someone who writes an article for them (ahh... the barter system!). If you're interested in writing an article, let me know. What's the deadline? I'm thinking about something along the lines use- cases for generic functions in TG. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Tutorial for 0.9a4: bugs, corrections and questions
Victor Kryukov wrote: TypeError: pagelist() got an unexpected keyword argument 'tg_format' It's a known[1] bug. Cheers, Simon [1] http://trac.turbogears.org/turbogears/ticket/740 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: Error handling broken in the trunk?
I think you solved it a bit to drastically. It seems that self is no longer being passed around (should have been the first element of args). What exactly did you do? Mind you, there is still a fair chance it's a bug and not your doing. Cheers, Simon Jorge Godoy wrote: I've just updated to r1105 to see if I could get that self problem solved and now I get a different error, with the same code: Traceback (most recent call last): s, **kw) File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/database.py, line 216, in run_with_transaction retval = func(*args, **kw) File string, line 5, in _expose File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/controllers.py, line 226, in lambda expose._expose.when(rule)(lambda _func, accept, allow_json, allow_json_from_config,*args,**kw: _execute_func( File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/controllers.py, line 249, in _execute_func output = errorhandling.try_call(func, *args, **kw) File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/errorhandling.py, line 71, in try_call output = func(self, *args, **kw) File string, line 3, in save File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/controllers.py, line 139, in validate return errorhandling.run_with_errors(errors, func, *args, **kw) TypeError: run_with_errors() takes at least 3 non-keyword arguments (2 given) I still dunno if I'm using something wrong or if this is a new bug (or family of bugs ;-)) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: [ANN] TurboPeakSecurity. An authorization layer for TurboGears based on PEAK Security
Super cool! Only thing I don't like is you are copying PEAK instead of linking it. You really should reconsider it. Cheers, Simon Alberto Valverde wrote: Hi people, I've recently began to factor out an implementation of PEAK security I had made for an application that required something more powerful than the Identity system TG currently provides (at the expense of Identity's simplicity ease of use). I had planned to polish it a bit more before officialy announcing it, but I've decided to the release rapidly, release often principle. I've ported the basic functionality I use in the app it came from. This is: * A CP filter that checks permissions along the object trail. * A base AuthService to provide authentication (can be easily adapted to delegate to Identity). Needs to be extended to do the real work... * A literal rip-off of PEAKs binding API to assign metadata (permissions, roles, context...) to classes and attributtes. * Another rip-off of PEAK's security rules enhanced with Simon''s genericfuntions (allows override of autogenerated rules) * A permission factory to generate permission classes. * Misc utils and helper functions. I've decided to copy what's needed from PEAK's core to avoid depending on the whole package, I hope it's been a wise decision... Right now there are no docs apart from unittests and docstrings. There is also a sample app that implements a very basic AuthService and some rule auto-generation. Reading http://peak.telecommunity.com/DevCenter/SecurityRules is a must, http://peak.telecommunity.com/DevCenter/ShortIntroPeakSecurity can help clarify some points. It's a normal egg with entry_points defined for turbogears.extensions and has no extra dependencies that TG doesn't have already. A minumum of TG 0.9a4 is required as it depends on MultiOrderFunction. You need to define some config parameters to enable and initialize it. The sample project shows how. I plan to write a compatibility layer to delegate authetication to identity, though I'll greatly appreciate some work in this area if there's a genuine interest in integrating this more closely with TG, mainly because I'm not using it myself so I haven't got a real use case to motivate me. There is a (out-of-the-box, bare-bones) Trac at: http://trac.toscat.net/TurboPeakSecurity/ The subversion repository is at: http://svn.toscat.net/TurboPeakSecurity/trunk And a sample application at: http://svn.toscat.net/TurboPeakSecurity/tptest Comments, criticisms, suggestions, etc... are greatly appreciated. Contributors even more, specially the generic function and Identity gurus around here (you know who you are ;) Hope someone finds this useful. 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 -~--~~~~--~~--~--~---
[TurboGears] Re: [ANN] TurboPeakSecurity. An authorization layer for TurboGears based on PEAK Security
Alberto Valverde wrote: On Apr 6, 2006, at 8:42 PM, Simon Belak wrote: Super cool! Only thing I don't like is you are copying PEAK instead of linking it. You really should reconsider it. Yep, it's something I'm really feeling uneasy about... The orignal implementaion linked to it, I decided to copy it for the opensourced version to avoid extra dependencies for current TG users. The problem is that the only components of PEAK that are currently needed (besides RuleDispatch which is already packaged separately) are 'binding' and 'security' wich I estimate to be a 5% of the whole package. TPS's version of 'security' already overrides 'hasPermission' with your MultiOrderFunction so this is not much of a problem (though that's what inheritance is all about). bindind is a literal copypaste and could really link to the original. I'd probably retract from this and live with the extra dep. (which I have already in my machines).. probably whoever needs this also needs other parts of PEAK so I realize it wasn't that wise of a decision :/ I'll be changing this soon... Maybe ask PJE if he would be willing to repackage PEAK a bit. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Using bind_args with turbogears.error_handler
Jorge Godoy wrote: Hi! I was searching the wiki to see if this information had been filled in since last time I went there but there was no change (http://trac.turbogears.org/turbogears/wiki/HowDoesErrorHandlingWork). I am willing to pass some parameters to my error_handler method, but I couldn't since it doesn't know self at the decorator level and it doesn't allow me to omit this parameter. I tried something like: @turbogears.expose(...) @turbogears.error_handler(method(parameter = value)) @turbogears.validate(...) @identity.require(...) def method(self, **kw): ... but it said that I needed to pass an unnamed parameter as well (it can only be self since my function signature is like the above). How should I pass, in the above case, a parameter to my error_handler? try: @error_handler(bind_args(parameter=value)(method)) Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Using bind_args with turbogears.error_handler
Jorge Godoy wrote: Simon Belak [EMAIL PROTECTED] writes: try: @error_handler(bind_args(parameter=value)(method)) I already did that, sorry for ommiting it from the first post: Traceback (most recent call last): File ./start-marketwatch.py, line 26, in ? from marketwatch.controllers import Root File /home/godoy/empresa/clientes/g2ctech/marketwatch/trunk/MarketWatch/marketwatch/controllers.py, line 10, in ? from marketwatch import compras File /home/godoy/empresa/clientes/g2ctech/marketwatch/trunk/MarketWatch/marketwatch/compras.py, line 35, in ? class Compras(object): File /home/godoy/empresa/clientes/g2ctech/marketwatch/trunk/MarketWatch/marketwatch/compras.py, line 106, in Compras @turbogears.expose(format = 'json', allow_json = True) NameError: name 'bind_args' is not defined 06/Apr/2006:19:03:09 ENGINE INFO SystemExit raised: shutting down autoreloader 06/Apr/2006:19:03:09 HTTP INFO HTTP Server shut down 06/Apr/2006:19:03:09 ENGINE INFO CherryPy shut down Using turbogears.bind_args and turbogears.errorhandling.bind_args also didn't work: AttributeError: 'module' object has no attribute 'bind_args' Should have mention it, it's in turbogears.util. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: TurboGears 0.9a3 released!
Baruch wrote: Ok, but that means that between 0.9a1 and 0.9a3 you removed the option to use the same method to validate and be the error handler. It generates a kind of ugly interface where I'll have a register method to display the form and doregister to get it submitted. Guess I'll have to live with it. Not willfully. Consider it a bug. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Proposed Visit/Identity change
Why not use time and ID of some request (thread) specific object. Such IDs are guarantied to be unique for the object's lifespan. Cheers, Simon ajones wrote: If he is using datetime.now() it is almost guaranteed to be unique, as that is down to the milisecond. It would be awesome if it were possible to process requests within the time delta to cause a problem, but python is simply not that fast yet. :-) In all seriousness it would be easy to do a hash on time+IP address, or time+incremented letter of the alphabet to ensure absolute uniqueness, but I don't see how this would really cause a problem. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Proposed Visit/Identity change
Alberto Valverde wrote: On 06/04/2006, at 0:09, Simon Belak wrote: Why not use time and ID of some request (thread) specific object. Such IDs are guarantied to be unique for the object's lifespan. Sounds good. A sha.new(%s%s % (thread.get_ident(), datetime.now ())).hexdigest() will do, right? A random() could also be thrown in but it might affect performance... I don't think random is a very good idea, considering the Mersenne Twister generator Python uses is deterministic and hence not suited for cryptography*. Cheers, Simon * technically combining MT with a hash solves this problem, but since we will not be hashing as part of generation, that leaves an (admittedly very small) opening for the bad guys**. ** it's quite possible I am being overly paranoid ;) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Proposed Visit/Identity change
Object ID's are (at least in current CPython implementation) actually corresponding memory addresses so it should be safe in multi-process environments. Cheers, Simon lateef jackson wrote: Some of us may run multiple instances of TG on multiproc machines (or cluster) and have a potential for a conflict if only the time is used. If there was something unique to the TG instance + time it would be fine. Not sure but I am just guessing that thread.get_ident() is not unique across multiple processes? What do we think of this datetime.now() + os.getpid() (assuming GIL you don't need to add the thread id but if GIL goes away then it would need to be added). Thoughts? On 4/5/06, *Alberto Valverde* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 06/04/2006, at 0:09, Simon Belak wrote: Why not use time and ID of some request (thread) specific object. Such IDs are guarantied to be unique for the object's lifespan. Sounds good. A sha.new(%s%s % (thread.get_ident(), datetime.now ())).hexdigest() will do, right? A random() could also be thrown in but it might affect performance... Alberto -- Simon Belak vodja projektnih skupin e: [EMAIL PROTECTED] - Hruska d.o.o., agencija za nove medije Ilirska 21, SI-1000 Ljubljana t: +386 1 430 25 86 f: +386 1 430 25 87 s: http://www.hruska.si s: http://akademija.hruska.si (izobrazevalni portal) s: http://www.elor.si (kadrovski sistem letnih razgovorov) Hruska.si - socne resitve To elektronsko sporocilo in vse morebitne priloge so poslovna skrivnost in namenjene izkljucno naslovniku. Ce ste sporocilo prejeli pomotoma, Vas prosimo, da obvestite posiljatelja, sporocilo pa takoj unicite. Kakrsnokoli razkritje, distribucija ali kopiranje vsebine sporocila je strogo prepovedano. This e-mail and any attachments may contain confidential and/or privileged information and is intended solely for the addressee. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail, or any action taken or omitted to be taken in reliance on it, is strictly prohibited. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Proposed Visit/Identity change
Jorge Godoy wrote: Simon Belak [EMAIL PROTECTED] writes: Object ID's are (at least in current CPython implementation) actually corresponding memory addresses so it should be safe in multi-process environments. Now lets add more to the game: how about a clustered environment with, lets say, 5 machines running the same TG app and accessing one DB server... ;-) Good point! Probably the best solution would be a seed hook with some reasonably safe default. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: TG-0.9-a2: Forms and widgets headaches
Fixed in [1068]. Thanks!
Cheers,
Simon
Andrey Lebedev wrote:
OK, that's all the code, demonstrating the problem. It is not much
different from the original:
import cherrypy
import turbogears
from turbogears import controllers
from turbogears import identity
from turbogears import widgets
from turbogears import validators
class MySchema(validators.Schema):
pwd1 = validators.Int()
pwd2 = validators.Int()
pwd3 = validators.String(not_empty=True , max=5)
chained_validators = [validators.FieldsMatch('pwd1', 'pwd2'), ]
def createPasswordForm(controller=None):
field1 = widgets.PasswordField('pwd1')
field2 = widgets.TextField('pwd2')
field3 = widgets.TextField('pwd3')
form = widgets.TableForm(fields=[field1, field2, field3],
name='myform', validator=MySchema())
return form
class FormTest(controllers.Controller):
@turbogears.expose(template=turbogears.fastdata.templates.form)
def index(self, tg_errors=None, **kw):
turbogears.flash(tg_errors)
return dict(obj=None, action='test', form=createPasswordForm())
@turbogears.expose()
@turbogears.error_handler(index)
@turbogears.validate(form=createPasswordForm)
def test(self, pwd1, pwd2, pwd3=None):
return Password1: %sbr /Password2: %s % (pwd1, pwd2)
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[TurboGears] Re: [PATCH] Strict controller parameters
Kevin Dangoor wrote: On 3/30/06, Simon Belak [EMAIL PROTECTED] wrote: Kevin wrote: Should unexpected parameters raise an exception every time? The idea was we should not allow something as simple as an incomplete link resulting in errors (500). Having said that, I agree with Claudio, making this behaviour optional can save time during development. OK. We can take this patch. Should we turn this on by default in dev.cfg (and off in prod.cfg)? Sounds good. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Overridable generic functions
Just a heads-up. In [1066] I committed turbogears.genericfunctions.MultiorderGenericFunction class allowing fine-tuning of resolution order. when() and around() of a generic function defined in this manner take an additional (optional, default 0) argument named order to define primary method resolution order. For example: from turbogears.genericfunctions import MultiorderGenericFunction from dispatch import generic @generic(MultiorderGenericFunction) def foo(a, b): pass @foo.when(a b) def foo_agtb(a, b): print I am first! @foo.when(a b, order=2) def foo_agtb(a, b): print I hate being last :( foo(234,67) I am first! Order takes precedence before specificality: from dispatch import strategy @foo.when(strategy.default, order=-1) def foo_superduper(next_method, a, b): print Better than the rest! return next_method(a, b) foo(234,67) Better than the rest! I am first! To make it simple for the users, we should be the ones primarily worried about order, defining rules with order 0 where it makes sense to override specialisations provided by TG (jsonify comes to mind). See also: http://trac.turbogears.org/turbogears/ticket/352 http://peak.telecommunity.com/DevCenter/CombiningResults http://trac.turbogears.org/turbogears/browser/trunk/turbogears/genericfunctions.py http://trac.turbogears.org/turbogears/browser/trunk/turbogears/tests/test_genericfunctions.py Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: TG-0.9-a2: Forms and widgets headaches
Andrey Lebedev wrote: PROBLEM I. Magic in method calls discovered. First thing I wanted is to show error message when passwords didn't match. So I added argument to index() method (as described in docs):: def index(self, tg_errors=None): turbogears.flash(tg_errors) ... Flash message was always None. I sarted investigation. I modified index() signature: def index(self, tg_errors=None, *args, **kw): ... Such a modification doesn't cause problems in python, however when I run a program, I've got TypeError: index() got multiple values for keyword argument 'tg_errors'. I removed *args argument and error disappeared, but tg_errors was still always None. After a few hors of tweaking the code and looking deep into the inner workings I left only **kw argument of index() method and thats when I could access form error information. That's not really a pythonic behaviour, a true sign, that some magic is going on behind the scenes and might be a little frustrating for the newbies (even if such behaviour is documented somewhere). While there is some magic, it should be so magical it appearers mundane. ;) Would you mind posting all of the code, as it seems you have stumbled upon a bug. Thanks! Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: util as an independent package
I was so entranced by my own brilliance I forgot to add it would be prudent not to schedule this change before First Class as some helpers will most likely undergo a breaking rewrite making them as general as possible. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: TraceKnack exception handling
I see. In that case I suggest using RhubarbTart[1]. Cheers, Simon [1] http://rhubarbtart.org/ Canis Lupus wrote: Well... it's certainly minimal :) But it's not really what I'm looking for -- if I make my own WSGI application and server combination, then TK is bound to work with it :) as it will likely make the same assumptions I did when writing the WSGI layer for TK. But it might not work with other people's real systems, that use different corners of the spec that I might've missed. What I need is a simple, complete, conforming server application into which I can drop TraceKnack and make sure TK doesn't break any of the existing functionality. There must be some around. If not, it's OK, I'll just wait for the WSGI-based TurboGears. Simon Belak wrote: This is probably as minimal as it gets: http://pythonpaste.org/do-it-yourself-framework.html Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: about RuleDispatch-0.5a0.dev-r2115.tar.gz Error
Try downloading [1] an egg (which comes precompiled) and installing from there. Cheers, Simon P.S. my previous reply was a brain fart, sorry ;) [1] http://peak.telecommunity.com/snapshots/ biomatrix wrote: I use windows xp python 2.42 When i install 0.9a2 by easy_install -f http://www.turbogears.org/preview/download/index.html TurboGears when install RuleDispatch-0.5a0.dev-r2115.tar.gz error report need Microsoft Visual Studio 7.0 to complie I download RuleDispatch-0.5a0.dev_r2100-py2.4-win32.egg form turbogears site exact it to the lib\site-packages path directly. Now, I installed the 0.9a2. I test it by the quickstart. Thing is Ok! This maybe helpful to turbogeras's beginers like me! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Trouble upgrading
Try using -U (update) switch for easy_install: easy_install -U -f ... Cheers, Simon hazy wrote: Hi all I'm new to Tg and very keen to get going. I've tried to download the 0.9a2 release but have run into trouble. Any thoughts as to hat to do next much appreciated. I run the command as suggested by the new web page: easy_install -f http://www.turbogears.org/preview/download/index.html TurboG ears But get this result: Searching for TurboGears Best match: turbogears 0.8.9 Processing turbogears-0.8.9-py2.4.egg turbogears 0.8.9 is already the active version in easy-install.pth Installing tg-admin-script.py script to C:\Python24\Scripts Installing tg-admin.exe script to C:\Python24\Scripts Using c:\python24\lib\site-packages\turbogears-0.8.9-py2.4.egg Processing dependencies for TurboGears Is there another URL I should be using perhaps. TIA for all suggestions John --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] [Article] The adventures of scaling
http://poocs.net/articles/2006/03/13/the-adventures-of-scaling-stage-1 Although it's targeted at Rails people, most principles apply across the board. Considering there was a thread about scaling here not long ago, I figure this might interest some of you. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: 0.9a1 appears to be slower than 0.8.9
When performance is an issue, CherryPy is not a very good choice. Also serving static pages is not a very good use-case (and again, it can be done more efficiently if by-passing TG altogether). Cheers, Simon venkatbo wrote: Hi Folks, I ran an 'unscientific' test using both these versions... I created a simple app via: tg-admin quickstart under both versions. When I ran the non-db TG app under 0.8.9 it took ~0.007 seconds to serve the static page, whereas under 0.9a1 it took ~0.015 seconds... Does this imply that more complex dynamic apps, could be quite slower under 0.9a1 as compared to 0.8.9 :?) /venkat --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Can't have a class named Group in model.py?
This is probably SQL limitation, as group is a keyword. Cheers, Simon Enigma Curry wrote: Hi, I've been designing a new model this morning and I ran into a bug or a misconception on my part. Here is my very simple model to illustrate the problem: from sqlobject import * from turbogears.database import PackageHub # Uncomment the following line if you wish to use Identity and SO_Provider #from turbogears.identity.soprovider import TG_User, TG_Group, TG_Permission hub = PackageHub(enigmacurryblog) __connection__ = hub class Group(SQLObject): stuff = StringCol(length=10) When I do a tg-admin sql create I get the following traceback: Using database URI sqlite:///airlock/subversion/blog/EnigmaCurryBlog/enigmacurry.sqlite Traceback (most recent call last): File /usr/local/bin/tg-admin, line 7, in ? sys.exit( File /usr/lib64/python2.4/site-packages/TurboGears-0.9a1-py2.4.egg/turbogears/command /base.py, line 270, in main command.run() File /usr/lib64/python2.4/site-packages/TurboGears-0.9a1-py2.4.egg/turbogears/command /base.py, line 129, in run command.the_runner.run(sys.argv) File /usr/lib64/python2.4/site-packages/SQLObject-0.7.1dev_r1457-py2.4.egg/sqlobject/ manager/command.py, line 102, in run runner.run() File /usr/lib64/python2.4/site-packages/SQLObject-0.7.1dev_r1457-py2.4.egg/sqlobject/ manager/command.py, line 233, in run self.command() File /usr/lib64/python2.4/site-packages/SQLObject-0.7.1dev_r1457-py2.4.egg/sqlobject/ manager/command.py, line 569, in command soClass.createTable() File /usr/lib64/python2.4/site-packages/SQLObject-0.7.1dev_r1457-py2.4.egg/sqlobject/ main.py, line 1322, in createTable conn.createTable(cls) File /usr/lib64/python2.4/site-packages/SQLObject-0.7.1dev_r1457-py2.4.egg/sqlobject/ dbconnection.py, line 522, in createTable self.query(self.createTableSQL(soClass)) File /usr/lib64/python2.4/site-packages/SQLObject-0.7.1dev_r1457-py2.4.egg/sqlobject/ dbconnection.py, line 303, in query return self._runWithConnection(self._query, s) File /usr/lib64/python2.4/site-packages/SQLObject-0.7.1dev_r1457-py2.4.egg/sqlobject/ dbconnection.py, line 217, in _runWithConnection val = meth(conn, *args) File /usr/lib64/python2.4/site-packages/SQLObject-0.7.1dev_r1457-py2.4.egg/sqlobject/ dbconnection.py, line 300, in _query self._executeRetry(conn, conn.cursor(), s) File /usr/lib64/python2.4/site-packages/SQLObject-0.7.1dev_r1457-py2.4.egg/sqlobject/ dbconnection.py, line 295, in _executeRetry return cursor.execute(query) pysqlite2.dbapi2.OperationalError: near group: syntax error If I rename my class from Group to something else I get no error. Is the word Group reserved somehow? I haven't tested another database server yet as it does appear to be sqlite that is producing the final error. If Group is reserved somehow it would be nice if there were a pre-parse step to tg-admin sql create that created a better error message. Also, maybe we put a warning in ModelDesigner too of class names people can't use. Using Turbogears 0.9a1 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Trapping errors
Max Ischenko wrote: Simon Belak wrote: @dispatch_error.before(tg_exceptions is not None) will be applied only when handling an exception. Cool. One thing: how to get the traceback? When I tried to print it using standard log.exception I got: Traceback (most recent call last): File _speedups.pyx, line 279, in _speedups.__getitem__ KeyError: 8 If you just want to know what function raised the exception, tg_source should be of some help, otherwise I am afraid you need to look into inspect.trace or traceback module (perhaps print_last()). Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: Defaults for dicts?
Michele Cella wrote: Simon Belak wrote: Defaults for method parameters. More specifically, defaults for inputs. Currently it's well-nigh impossible to have meaningful defaults for nested forms. If we want that I think we (well, you :P) can easily do that using util.recursive_update and updating the method default dict by using the input values one, that's all it takes, as I said on the ticket we don't need the different notation, yep nested dict are a bit more painful but that's what python gives us and we are not using that notation even for value and options in widgets and I don't think we should provide 2 ways of doing it, in the controller side I'm more positive about exposing only regular python. ;-) Thanks! Ciao Michele I agree, we should reuse update_dict, however I still think it needs to be a part of every TG instance, not just my super-duper-hot-rod-custom. ;) Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
