[TurboGears] Re: Is there a convenient solution to object names in urls?
2006/1/30, Soni Bergraj [EMAIL PROTECTED]: I'm looking for a more convenient approach to this same problem myself too. I'm especially after a way I can do this: /persons/FooBar/addresses/Postal/edit As it is, I have to do a backflip or two in the default() handler in order to dispatch to the correct method. That really gets ugly... web.py (http://webpy.org/) offers a solution based on regular expressions. Works nicely so far:) I remember reading somewhere about use of Routes [1] with CherryPy. I think the addition of Routes to TG would be *very* welcome :) [1] http://routes.groovie.org/ -- Ksenia
[TurboGears] log on to www.ludhianawedding.com or get your copy of wedding planner now
log on to www.ludhianawedding.com or get your copy of wedding planner now
[TurboGears] Do any of the alternate template systems work with widgets?
Hi, I am using windows XP as my development system. The endless loop bug with extends in Kid is driving me crazy. Actually, it seems like Kid needs the all the templates to be in the same directory. Documentation seems insufficient on this point. I want to provide a standard set of forms and allow people to modify the theme behind it. I am almost ready to release version .1 of my CMS. I want it to sit as much as possible on top of Turbogears. Otherwise, I might as well roll my own framework, which would be stupid. I would prefer to use KID but I have to get this thing out since I have projects that depend on it. Thanks Alvin
[TurboGears] Re: Is there a convenient solution to object names in urls?
On 1/30/06, Ksenia Marasanova [EMAIL PROTECTED] wrote: I think the addition of Routes to TG would be *very* welcome :) Routes has already got a non-working implimentation for TG in the wiki[1]. Unfortunately I'm not sure how to actually get the recipe working and it was abandoned as hacking a custom default method was quicker to get working. I'm still a big advocate of routes. I'd also like to know the actual reason why the decorators no longer work when using the method used to make routes work... I know that I return exposed functions in my other default methods and the decorator works. Lee
[TurboGears] Re: Is there a convenient solution to object names in urls?
Sorry, I missed the link[1] ;) [1] http://trac.turbogears.org/turbogears/wiki/RoutesIntegration
[TurboGears] Re: log to screen in 'development' mode
Max Ischenko [EMAIL PROTECTED] writes: Hello, TurboGears startup.py contains the following code: isdev = cherrypy.config.get('server.environment') == 'development' if isdev: # configure logging module to log to sys.stdout OTOH, there is server.log_to_screen setting. Shouldn't logging configuration be dependent on that setting instead of server.environment? After all, it's a bit confusing when I set server.log_to_screen to False and server.environment is 'development' and I still see the log on the console. Maybe an AND for the environment but with an obligatory setup for the config option. -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: kid templates with accented characters
2006/1/30, Petro Verkhogliad [EMAIL PROTECTED]: Thanks that does help. The only thing that worked is the following: unicode(book.author.decode('latin1').encode('utf8'), 'utf-8') a little hackish. but it works. i'll have to clean up the output before it gets to kid templates. I do think that Kid's inability to use non-ascii-encoded strings is a bug. Right now Kid accepts either unicode objects, or ascii-encoded strings. IMHO when it comes to strings, Kid should decode them using document's encoding (latin1 in your case). -- Ksenia
[TurboGears] turbogears.url and std.url
Hi, Need some help... I have the latest turbogears revision, kid revision and turbokid revision installed and every time I use: 1- raise cherrypy.HTTPRedirect(turbogears.url(/SomePage)) # inside controller or 2- ${std.url('/SomePage' + MoreParam)}# inside Kid I have de error you can see above. Thanks, Helio Pereira 500 Internal error The server encountered an unexpected condition which prevented it from fulfilling the request. Page handler: bound method Root.index of testurl.controllers.Root object at 0x0112E250 Traceback (most recent call last): File c:\python24\lib\site-packages\CherryPy-2.2.0beta-py2.4.egg\cherrypy\_cphttptools.py, line 98, in _run self.main() File c:\python24\lib\site-packages\CherryPy-2.2.0beta-py2.4.egg\cherrypy\_cphttptools.py, line 246, in main body = page_handler(*virtual_path, **self.params) File c:\python24\lib\site-packages\TurboGears-0.9a0dev_r595-py2.4.egg\turbogears\controllers.py, line 241, in newfunc html, fragment, *args, **kw) File c:\python24\lib\site-packages\TurboGears-0.9a0dev_r595-py2.4.egg\turbogears\database.py, line 189, in run_with_transaction retval = func(*args, **kw) File c:\python24\lib\site-packages\TurboGears-0.9a0dev_r595-py2.4.egg\turbogears\controllers.py, line 258, in _execute_func output = func(self, *args, **kw) File C:\Projectos\TG\Testes\testurl\testurl\controllers.py, line 10, in index raise cherrypy.HTTPRedirect(turbogears.url(/login)) File c:\python24\lib\site-packages\TurboGears-0.9a0dev_r595-py2.4.egg\turbogears\util.py, line 95, in url if cherrypy.request.app_path != /: File c:\python24\lib\site-packages\CherryPy-2.2.0beta-py2.4.egg\cherrypy\__init__.py, line 41, in __getattr__ return getattr(childobject, name) AttributeError: 'Request' object has no attribute 'app_path'
[TurboGears] Re: turbogears.url and std.url
works fine thanks :-)
[TurboGears] Re: kid templates with accented characters
You have to pass a Unicode string to Kid if it may contain non-ascii character. Also, you you pass your SQLObject model instances to Kid you may declare corresponding field as UnicodeCol so that it will be encoded automatically.
[TurboGears] Re: AttributeError: 'thread._local' object has no attribute 'request'
I'm having the same problem as Jorge, which I think is gettext + widgets? related, as it's the only think I've changed in my project and I didn't have the problem before. I think it has nothing to do with Ivo's problem as his is mpcp related (though the final excpetion looks the same, Ivo how's your modpython_gateway script going?) Jorge, have you found a cure already? If not, i'll post my traceback to see if we can hunt the bug (I'll start hunting tomorrow though, as I'm leaving work in 5 minutes) Traceback (most recent call last): File ./start-n50cpanel.py, line 25, in ? from n50cpanel.controllers import Root File /home/alberto/src/n50cpanel/n50cpanel/controllers.py, line 7, in ? import n50cpanel.widgets as panelwidgets File /home/alberto/src/n50cpanel/n50cpanel/widgets.py, line 5, in ? class NewPassValidator(V.FancyValidator): File /home/alberto/src/n50cpanel/n50cpanel/widgets.py, line 7, in NewPassValidator messages = { 'too_short' : File /home/alberto/src/turbogears/turbogears/i18n/tg_gettext.py, line 45, in gettext return gettext_f(key, locale, domain) File /home/alberto/src/turbogears/turbogears/i18n/tg_gettext.py, line 54, in _gettext if locale is None:locale = get_locale() File /home/alberto/src/turbogears/turbogears/i18n/utils.py, line 64, in get_locale locale = get_locale_f() File /home/alberto/src/turbogears/turbogears/i18n/utils.py, line 77, in _get_locale locale = cherrypy.session.get(locale_key) File /usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/filters/sessionfilt er.py, line 413, in __getattr__ sess = cherrypy.request._session File /usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/__init__.py, line 42, in __getattr__ childobject = getattr(serving, self.__attrname__) AttributeError: 'thread._local' object has no attribute 'request' Regards, Alberto
[TurboGears] Re: kid templates with accented characters
I do think that Kid's inability to use non-ascii-encoded strings is a bug. It's not true. From kid 0.8 there is no problem. Example of working minimal template: ?xml version=1.0 encoding=iso-8859-1? html xmlns=http://www.w3.org/1999/xhtml; xmlns:py=http://purl.org/kid/ns#; head titleàòèìù/title /head body pKid è buono e bravo./p /body /html Rocco
[TurboGears] Re: AttributeError: 'thread._local' object has no attribute 'request'
Ok, I've just seen you've filed a ticket (http://trac.turbogears.org/turbogears/ticket/485) on this. Alberto
[TurboGears] Re: setting up errors setuptools (=0.6a9) not found
You may want to look for earlier versions of setuptools in your path. If you have a lower numbered version in your path somewhere it may be found and run rather than the one you want. If this is the case, just move, rename, or delete the old version and everything should work. --Mark Ramm On 1/29/06, viyyer [EMAIL PROTECTED] wrote: I have setuptools 0.6a9 installed output of dpkg -l|grep setuptools|grep 2.4 is ii python2.4-setuptools 0.6a9-1 Python Distutils Enhancements and when I run python2.4 setup.py I get this error The required version of setuptools (=0.6a9) is not available, and can't be installed while this script is running. Please install a more recent version first. cheers Vivek -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog
[TurboGears] Re: What is a KeyError and how do I fix it
It looks as sqlobject doesn't know about your mfg column (weird, as your DB has it and you're reading fromDatabase). I have no experience with fromDatabase classes but you could try: 1) tg-admin shell 2) print vehicle.sqlmeta.columns.keys() To see what columns SO does see on your DB. Alberto
[TurboGears] Re: kid templates with accented characters
2006/1/30, Rocco [EMAIL PROTECTED]: I do think that Kid's inability to use non-ascii-encoded strings is a bug. It's not true. From kid 0.8 there is no problem. Example of working minimal template: ?xml version=1.0 encoding=iso-8859-1? html xmlns=http://www.w3.org/1999/xhtml; xmlns:py=http://purl.org/kid/ns#; head titleàòèìù/title /head body pKid è buono e bravo./p /body /html What I meant is that you can't pass non-ascii encoded *variables* to the template. So in your example put u'àòèìù' in an unicode variable, encode it as iso-8859-1, pass to the template, and you'll get UnicodeDecodeError. -- Ksenia
[TurboGears] DynamicSelectField widget
http://trac.turbogears.org/turbogears/ticket/475 Comments and discussion please. I think that this is a good addition to the base widgets. If not then I'll add it as a recipe for a custom widget on the wiki. (Copied from the ticket) Sometimes you don't know what a SelectField's options are going to be before you .insert() it and changing the options on the fly isn't threadsafe. Attached is a patch with a new widget called DynamicSelectField?. It's essentially the same as a normal SelectField? except it pulls out it's options from widget_value on .insert(). Examples: div ${testwidget.insert(value=(3, [(1,Apple),(2,Banana),(3,Pear)]))} /div div ${testwidget.insert(value=(2, [(1,Audi),(2,VW),(3,Ford)]))} /div The first argument in the value tuple is the value of the option you want to be selected and the second is a list of tuples containing the options and their respective values and text. With this method the data can still be passed when the widget is nested in a Form Widget (or subclass thereof). Lee
[TurboGears] Re: Any body know how to build self foreign key model
2006/1/30, TerryH [EMAIL PROTECTED]: class Cat(SQLObject): sub_category = MultipleJoin('Cat') par_category = ForeignKey('Cat') category_name = UnicodeCol(alternateID=True, length=30) The trick is to specify joinColumn: class Cat(SQLObject): sub_category = MultipleJoin('Cat', joinColumn='par_category') par_category = ForeignKey('Cat') category_name = UnicodeCol(alternateID=True, length=30) Note that joinColumn must be the database column's name, not the Python name. In your naming style they are probably the same. -- Ksenia
[TurboGears] Re: toolbox does not work if tg.defaultview is set to an other template engine
Hi, I've set ticket 483 to deal with the larger issue of isolating the Toolbox configuration from the user's app configuration. Thanks for bringing this up! Kevin On 1/20/06, Soni Bergraj [EMAIL PROTECTED] wrote: Hello, the toolbox does not work if tg.defaultview is set to an other template engine. I opened a ticket for it: http://trac.turbogears.org/turbogears/ticket/428 The attached patch changes all expose stuff to kid:.. but it does not work for the Widget Browser for some curios reason (AttributeError: TurboCheetah instance has no attribute 'transform'). There may be an even more convenient way to solve it (maybe not using the project config for the toolbox at all). I'm not really accustomed to the toolbox nor to the TG source so far, sorry. Cheers, -- Soni Bergraj -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: note to those following svn: nose now required
Hi Mike, Sorry to be catching this more than a week later. Do you still have this problem? nosetests runs fine for me. Kevin On 1/21/06, Mike Kent [EMAIL PROTECTED] wrote: Hmm. This morning, following an update to TG release 584, nosetests no longer works. Running it gets: [EMAIL PROTECTED] turbogears]$ nosetests E == ERROR: test module turbogears in /home/mike/Work/projects/turbogears/turbogears -- Traceback (most recent call last): File /usr/local/lib/python2.4/site-packages/nose-0.8.4-py2.4.egg/nose/core.py, line 409, in run self.setUp() ## LOTS OF LINES ELIDED ## File /usr/local/lib/python2.4/site-packages/kid-0.8-py2.4.egg/kid/pull.py, line 407, in feed raise e ExpatError: mismatched tag: line 22, column 2 -- Ran 0 tests in 0.629s FAILED (errors=1) -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: turbogears.widgets.grid should probably go away
On 1/30/06, Lee McFadden [EMAIL PROTECTED] wrote: This should definately be culled. It's causing confusion as both turbogears.widgets.grid and turbogears.fastdata.datawidgets have a widget called DataGrid. Moreover, the old DataGrid will happily take all the args that the new and improved one does and just shows the default data. :) http://trac.turbogears.org/turbogears/ticket/487 Ticket and patch so things don't get lost in the hubub. Thanks, Lee. The file is gone in [606]. Kevin
[TurboGears] Re: Do any of the alternate template systems work with widgets?
Thanks, however, Your link does not work. Alvin
[TurboGears] Re: Do any of the alternate template systems work with widgets?
On 1/30/06, Alvin Wang [EMAIL PROTECTED] wrote: I am using windows XP as my development system. The endless loop bug with extends in Kid is driving me crazy. Actually, it seems like Kid needs the all the templates to be in the same directory. Documentation seems insufficient on this point. I want to provide a standard set of forms and allow people to modify the theme behind it. Though this won't help you right this second, I think that using a template search path (something that will come not long after 0.9, I think), will make this easier. When you say that Kid needs all the templates to be in the same directory, do you mean that you can't do things like py:extends='../master.kid'? I thought there had been some progress on the endless loop problem (there were people reporting that their systems were fine now, iirc). Just to double check, you've got the latest Kid trunk and TurboKid installed, right? Kevin
[TurboGears] Re: [patch] The grid widget has an embedded css link
Hi Mike, I've just killed off this widget, because it doesn't generally follow current conventions. Kevin On 1/21/06, Mike Kent [EMAIL PROTECTED] wrote: The grid widget has an embedded css link in its template, making it very difficult to override its css. Here's a very simple patch to remove that link. I'd submit this to Trac, but it's down again. Index: grid.py === --- grid.py (revision 548) +++ grid.py (working copy) @@ -8,7 +8,6 @@ class Grid(Widget): template = div xmlns:py=http://purl.org/kid/ns#; -link href=/tg_static/css/widget.css type=text/css rel=stylesheet / table id=${widget.name} class=grid form_container ${' '.join(widget.css_classes)} cellpadding=0 cellspacing=1 border=0 thead py:if=widget.headers td py:for=head in widget.headers -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: DynamicSelectField widget
Kevin Dangoor wrote: Hi Lee, This functionality is definitely something we need, in one form or another. I'm hesitant to commit another widget right this moment, because there are some good suggestions for API cleanup ongoing from David Bernard and Michele Cella. Now is really the last chance to do that kind of cleanup. I'd rather not combine the value with the set of options. You should be able to pass another keyword to insert() to hold the options list. And, the main select widget can probably support both styles of working: up-front definition and render-time definition. Yes, that's exactly how I've done it. Any widgets can provide additional options using a constructor argument (options) and the same argument at render/insert time. For a selection widgets those options are managed as the possible choiches. Ciao Michele Thanks for the patch and ticket... we do need this in some form, without question... (I *think* the current widget may take a callable for the options list, which is the current mechanism for handling this, but that's not always as pleasant.) Kevin On 1/30/06, Lee McFadden [EMAIL PROTECTED] wrote: http://trac.turbogears.org/turbogears/ticket/475 Comments and discussion please. I think that this is a good addition to the base widgets. If not then I'll add it as a recipe for a custom widget on the wiki. (Copied from the ticket) Sometimes you don't know what a SelectField's options are going to be before you .insert() it and changing the options on the fly isn't threadsafe. Attached is a patch with a new widget called DynamicSelectField?. It's essentially the same as a normal SelectField? except it pulls out it's options from widget_value on .insert(). Examples: div ${testwidget.insert(value=(3, [(1,Apple),(2,Banana),(3,Pear)]))} /div div ${testwidget.insert(value=(2, [(1,Audi),(2,VW),(3,Ford)]))} /div The first argument in the value tuple is the value of the option you want to be selected and the second is a list of tuples containing the options and their respective values and text. With this method the data can still be passed when the widget is nested in a Form Widget (or subclass thereof). Lee -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: turbogears.widgets.grid should probably go away
On this regard, after looking at DataGrid, I think it should be fixed since it seems to not be threadsafe, it's using instance attributes (self.) inside the update_dict method in this way: self.dynfields = {} Am I right Kevin? Ciao Michele Kevin Dangoor wrote: On 1/30/06, Lee McFadden [EMAIL PROTECTED] wrote: This should definately be culled. It's causing confusion as both turbogears.widgets.grid and turbogears.fastdata.datawidgets have a widget called DataGrid. Moreover, the old DataGrid will happily take all the args that the new and improved one does and just shows the default data. :) http://trac.turbogears.org/turbogears/ticket/487 Ticket and patch so things don't get lost in the hubub. Thanks, Lee. The file is gone in [606]. Kevin
[TurboGears] Re: setting up errors setuptools (=0.6a9) not found
viyyer wrote: I have setuptools 0.6a9 installed output of dpkg -l|grep setuptools|grep 2.4 is ii python2.4-setuptools 0.6a9-1 Python Distutils Enhancements You might want to check to make sure there is a setuptools*.egg-info or setuptools*.egg file or directory present on your sys.path. If setuptools was packaged without an .egg or .egg-info, it will not work correctly, and the problem should be reported to the packager. In particular, there *must* be an .egg/EGG-INFO/entry_points.txt or an .egg-info/entry_points.txt file, or it won't work at all.
[TurboGears] Re: Do any of the alternate template systems work with widgets?
Yes, I update TG daily. I would like to do something like py:extends='scaffolding.templates.master.kid' Thanks Alvin
[TurboGears] Re: note to those following svn: nose now required
I'm also still getting problems (errors=1): Ciao Michele == ERROR: test module tests.test_i18n in /home/michele/Progetti/TurboGears/svn/turb ogears -- Traceback (most recent call last): File /usr/local/lib/python2.4/site-packages/nose-0.8.5-py2.4.egg/nose/core.py , line 404, in run self.setUp() File /usr/local/lib/python2.4/site-packages/nose-0.8.5-py2.4.egg/nose/core.py , line 583, in setUp self.module = self.loader._import(self.module_name, self.path) File /usr/local/lib/python2.4/site-packages/nose-0.8.5-py2.4.egg/nose/core.py , line 261, in _import return nose.importer._import(name, [path]) File /usr/local/lib/python2.4/site-packages/nose-0.8.5-py2.4.egg/nose/importe r.py, line 64, in _import mod = load_module(fqname, fh, filename, desc) File /home/michele/Progetti/TurboGears/svn/turbogears/tests/test_i18n.py, li ne 31, in ? sogettext.create_so_catalog([en,fi], messages) File /home/michele/Progetti/TurboGears/svn/turbogears/i18n/sogettext/__init__ .py, line 58, in create_so_catalog TG_Message.dropTable(ifExists=True) File /usr/local/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1457-py2.4.eg g/sqlobject/main.py, line 1308, in dropTable conn = connection or cls._connection File /usr/local/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1457-py2.4.eg g/sqlobject/dbconnection.py, line 856, in __get__ return self.getConnection() File /home/michele/Progetti/TurboGears/svn/turbogears/database.py, line 42, in getConnection raise AttributeError( AttributeError: No connection has been defined for this thread or process -- Ran 73 tests in 3.127s FAILED (errors=1) Unhandled exception in thread started by Error in sys.excepthook: Kevin Dangoor wrote: Hi Mike, [snip]
[TurboGears] Re: note to those following svn: nose now required
Michele Cella wrote: ERROR: test module tests.test_i18n in /home/michele/Progetti/TurboGears/svn/turb ogears -- [...] AttributeError: No connection has been defined for this thread or process This seems to happen if nosetests imports the i18n.sogettext.model module *before* importing and running tests.test_i18n. The solution I found is to run nosetests inside the turbogears/tests directory.
[TurboGears] Widgets redux, call for testers
Hi, I the last few days I've been working on an API cleanup (not yet finished but mostly so) for the widgets system. I tried to make them intuitive to use, to customize (very simple templates, compare them with what TG is actually using) by moving a lot of logic from templates to where it belongs and provide good default widgets for forms managing. What I mean with the last thing? That for example you get: SingleSelectField MultipleSelectField RadioButtonList CheckBoxList they all work in the same way: - SingleSelectField and RadioButtonList for a single choiche - MultipleSelectField and CheckBoxList for multiple choiches the only difference stands in their lookfeel. I would like interested people to try them, I've tried to keep them compatible with the old ones but some things had to be changed. You can play with my work using a small TG project I've attached here: http://trac.turbogears.org/turbogears/attachment/ticket/490/NewWidgets-0.5.tar.gz?format=raw You find forms widgets inside forms.py. :-) Give it a try and report here your opinions, I'm going to have few time to do any other work. Ciao Michele PS Date* are not there.
[TurboGears] Re: Template plugins
Kevin Dangoor wrote: Coming back to some old mail here: is everyone fine with David's proposal below? Yes. I like the looks of that. On a side note, has anyone been successful in using the Myghty or XSLT templating plugins with TG? I just haven't heard anything. Maybe no news is good news :-) Christian http://www.dowski.com On 1/20/06, David Bernard [EMAIL PROTECTED] wrote: Ian Bicking a écrit : The only concern I have is that it might be harder to implement or map to systems that already have a concept of a search path. It shouldn't be implemented purely on the frontend, because all templates (including included or extended templates) should be found with the same mechanism. Right suggestion 6. doesn't work for include and extends by suggestion 7 works for every case. 7. instead of set/copy configuration data into the template engine, initialisation sets/injects the function. function with 2 parameters : the template-location and the file extension for template file. In this case I prefer the **kw (2) for injecting the function. class TemplatePlugin: def __init__(self, extra_vars_func = None, options = {}, find_template = None, **kw): ... self.find_template = find_template ... def load_template(self, templatename): template_path = find_template(templatename, .tmpl) With this TG could choose the strategie/implementation for the find_template function. Current implementation is: def pkg_template(templatename, ext): divider = templatename.rfind(.) if divider -1: package = templatename[0:divider] basename = templatename[divider+1:] return pkg_resources.resource_filename(package, %s.%s % (basename, ext)) And Plugin could choose to have an other mecanisme. -- -- David Dwayne BernardFreelance Developer -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: DynamicSelectField widget
WARN : if you use server side validation, the validation is done against values provide during widget's construction (as paramater or through the validator). Michele Cella a écrit : Kevin Dangoor wrote: Hi Lee, This functionality is definitely something we need, in one form or another. I'm hesitant to commit another widget right this moment, because there are some good suggestions for API cleanup ongoing from David Bernard and Michele Cella. Now is really the last chance to do that kind of cleanup. I'd rather not combine the value with the set of options. You should be able to pass another keyword to insert() to hold the options list. And, the main select widget can probably support both styles of working: up-front definition and render-time definition. Yes, that's exactly how I've done it. Any widgets can provide additional options using a constructor argument (options) and the same argument at render/insert time. For a selection widgets those options are managed as the possible choiches. Ciao Michele Thanks for the patch and ticket... we do need this in some form, without question... (I *think* the current widget may take a callable for the options list, which is the current mechanism for handling this, but that's not always as pleasant.) Kevin On 1/30/06, Lee McFadden [EMAIL PROTECTED] wrote: http://trac.turbogears.org/turbogears/ticket/475 Comments and discussion please. I think that this is a good addition to the base widgets. If not then I'll add it as a recipe for a custom widget on the wiki. (Copied from the ticket) Sometimes you don't know what a SelectField's options are going to be before you .insert() it and changing the options on the fly isn't threadsafe. Attached is a patch with a new widget called DynamicSelectField?. It's essentially the same as a normal SelectField? except it pulls out it's options from widget_value on .insert(). Examples: div ${testwidget.insert(value=(3, [(1,Apple),(2,Banana),(3,Pear)]))} /div div ${testwidget.insert(value=(2, [(1,Audi),(2,VW),(3,Ford)]))} /div The first argument in the value tuple is the value of the option you want to be selected and the second is a list of tuples containing the options and their respective values and text. With this method the data can still be passed when the widget is nested in a Form Widget (or subclass thereof). Lee -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com -- David Dwayne BernardFreelance Developer mailto:[EMAIL PROTECTED] \|/ http://dwayne.java-fan.com --o0O @.@ O0o- signature.asc Description: OpenPGP digital signature
[TurboGears] Re: Widgets redux, call for testers
Hi Michele, Cool, just a nit: Could you use and underscore instead of '-' betwen widget.field_id and value? I don't like to see price-2 as a radio option. Underscores make it clear (in the HTML/javascript/css) that we are talking about strings. I told you this was a nit =) Cheers. Ronald On Jan 30, 2006, at 7:40 PM, Michele Cella wrote: Hi, I the last few days I've been working on an API cleanup (not yet finished but mostly so) for the widgets system. I tried to make them intuitive to use, to customize (very simple templates, compare them with what TG is actually using) by moving a lot of logic from templates to where it belongs and provide good default widgets for forms managing. What I mean with the last thing? That for example you get: SingleSelectField MultipleSelectField RadioButtonList CheckBoxList they all work in the same way: - SingleSelectField and RadioButtonList for a single choiche - MultipleSelectField and CheckBoxList for multiple choiches the only difference stands in their lookfeel. I would like interested people to try them, I've tried to keep them compatible with the old ones but some things had to be changed. You can play with my work using a small TG project I've attached here: http://trac.turbogears.org/turbogears/attachment/ticket/490/ NewWidgets-0.5.tar.gz?format=raw You find forms widgets inside forms.py. :-) Give it a try and report here your opinions, I'm going to have few time to do any other work. Ciao Michele PS Date* are not there. Ronald Jaramillo mail: ronald AT checkandshare DOT com blog: http://www.checkandshare.com/blog
[TurboGears] Re: turbogears.widgets.grid should probably go away
Absolutely. And I just opened a ticket to make sure that we stop people from setting an attribute after a widget is initialized: http://trac.turbogears.org/turbogears/ticket/492 Kevin On 1/30/06, Michele Cella [EMAIL PROTECTED] wrote: On this regard, after looking at DataGrid, I think it should be fixed since it seems to not be threadsafe, it's using instance attributes (self.) inside the update_dict method in this way: self.dynfields = {} Am I right Kevin? Ciao Michele Kevin Dangoor wrote: On 1/30/06, Lee McFadden [EMAIL PROTECTED] wrote: This should definately be culled. It's causing confusion as both turbogears.widgets.grid and turbogears.fastdata.datawidgets have a widget called DataGrid. Moreover, the old DataGrid will happily take all the args that the new and improved one does and just shows the default data. :) http://trac.turbogears.org/turbogears/ticket/487 Ticket and patch so things don't get lost in the hubub. Thanks, Lee. The file is gone in [606]. Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: note to those following svn: nose now required
On 1/30/06, Michele Cella [EMAIL PROTECTED] wrote: FAILED (failures=4) [EMAIL PROTECTED]:~/Progetti/TurboGears/svn/turbogears/tests$ Why 4 failures here and 1 from the project root? :-/ I get 4 failures when running in that directory as well. But I don't get any failures at the project root. Kevin
[TurboGears] Re: wiki got spammed
On 1/30/06, Alberto [EMAIL PROTECTED] wrote: It's sad... but I think we need some sort of authentication at the Trac. Or put some sort of Hacker Page a là vserver ;) (http://linux-vserver.org/Hacker+Page). I just turned on the account manager plugin again so that people can register. People had reported that they weren't seeing their accounts become active immediately, which would be the primary concern there, but let's give that another try. If all goes well, I may then make all updates require authentication. Kevin
[TurboGears] Re: wiki got spammed
On 1/30/06, Kevin Dangoor [EMAIL PROTECTED] wrote: If all goes well, I may then make all updates require authentication. Oh, and I'll say it again: what would be really great is some kind of turing test style question or CAPTCHA instead of requiring authentication. If anyone happens to spot or write a Trac plugin that does this, let me know! Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: Do any of the alternate template systems work with widgets?
On 1/30/06, Alvin Wang [EMAIL PROTECTED] wrote: Yes, I update TG daily. I would like to do something like py:extends='scaffolding.templates.master.kid' When the extends value is a string (it's in quotes), Kid looks around with file paths relative to where that template is. To look in a completely different place, you'd need to precompile the template to a .pyc file or put it in baseTemplates in turbogears.view. Then you can ?python import scaffolding.templates.master ? ... py:extends=scaffolding.templates.master Note that the py:extends *doesn't* have quotes around it in that usage. Kevin
[TurboGears] Re: DynamicSelectField widget
David Bernard wrote: WARN : if you use server side validation, the validation is done against values provide during widget's construction (as paramater or through the validator). I updated my example app to show how you use dynamic options. http://trac.turbogears.org/turbogears/ticket/490 For a single field we should use the validator provided if any (if it's not there I try to add a good default), for multiple field it's wrapped inside a ForEach validator that returns a validate list (you can also pass a list as default at constructor) to you method. I'm not using OneOf since it expects to be inizialized with values and you will not be able to change it dynamically (threadsafety), anyway for these widgets the input value will always be one of the possible choiche so the real use of a validator in that case is just the conversion from/to python, so I can't see any problem. On the other hand I don't except someone so crazy to change a option list to be totally dirrent from the default one. I mean, if you construct with: options = [(1, python), (2, java), (3, ruby)] you will probably add or remove some options but not provide a totally different thing like: options = [(cool, python), (2, java), (again, ruby)] that's mixing string and int values, if someone is going to do it I would like to take a look at its controller method. :-) Ciao Michele Michele Cella a écrit : Kevin Dangoor wrote: Hi Lee, This functionality is definitely something we need, in one form or another. I'm hesitant to commit another widget right this moment, because there are some good suggestions for API cleanup ongoing from David Bernard and Michele Cella. Now is really the last chance to do that kind of cleanup. I'd rather not combine the value with the set of options. You should be able to pass another keyword to insert() to hold the options list. And, the main select widget can probably support both styles of working: up-front definition and render-time definition. Yes, that's exactly how I've done it. Any widgets can provide additional options using a constructor argument (options) and the same argument at render/insert time. For a selection widgets those options are managed as the possible choiches. Ciao Michele Thanks for the patch and ticket... we do need this in some form, without question... (I *think* the current widget may take a callable for the options list, which is the current mechanism for handling this, but that's not always as pleasant.) Kevin On 1/30/06, Lee McFadden [EMAIL PROTECTED] wrote: http://trac.turbogears.org/turbogears/ticket/475 Comments and discussion please. I think that this is a good addition to the base widgets. If not then I'll add it as a recipe for a custom widget on the wiki. (Copied from the ticket) Sometimes you don't know what a SelectField's options are going to be before you .insert() it and changing the options on the fly isn't threadsafe. Attached is a patch with a new widget called DynamicSelectField?. It's essentially the same as a normal SelectField? except it pulls out it's options from widget_value on .insert(). Examples: div ${testwidget.insert(value=(3, [(1,Apple),(2,Banana),(3,Pear)]))} /div div ${testwidget.insert(value=(2, [(1,Audi),(2,VW),(3,Ford)]))} /div The first argument in the value tuple is the value of the option you want to be selected and the second is a list of tuples containing the options and their respective values and text. With this method the data can still be passed when the widget is nested in a Form Widget (or subclass thereof). Lee -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com -- David Dwayne BernardFreelance Developer mailto:[EMAIL PROTECTED] \|/ http://dwayne.java-fan.com --o0O @.@ O0o-
[TurboGears] Re: A couple of database puzzles
On 1/29/06, Mark Ramm [EMAIL PROTECTED] wrote: Let's start with the windows weirdness. I'm using TurboGears Rev 591 with a freshly quickstarted project. When I use the shell to make a database update hub.commit seems to run fine, but there is no SQL generated to actually update the database. If however I import the database module and run database.commit_all() the database IS updated. I noticed however, that hub.commit seems to be using AutoConnectHub rather than PackageHub. For example a simple hub.commit at the tg-admin shell gives me: hub.commit bound method AutoConnectHub.commit of turbogears.database.AutoConnectHub object at 0x012BAA50 I just tried this on my PowerBook, quite possibly on the same project you're using (or at least one that I know you were recently working on :). For me, hub.commit() worked fine for adding a new record. I had debug=1 on my dburi and I saw the INSERT happen, and the COMMIT happen on the same connection. If you look at hub in your shell, you'll find that it's a PackageHub. When you do hub.commit, you're actually talking to the AutoConnectHub that's responsible for doing the work (PackageHub has a __getattr__ that delegates to the AutoConnectHub underneath). So, this may be related to my other problem, which is that on my Ubuntu Laptop I can't use notrans_ to connect to a mysql database, because it is not getting stripped off. (Ticket #346). Make sure that hub, when displayed in the shell, is in fact a PackageHub. Just to confirm something else: you are running tg-admin shell from the top level directory of your project, right? It's worth making sure that the config that's coming through is the one that's desired. You can always run cherrypy.config.get() statements to see if sqlobject.dburi is what you'd expect. Kevin
[TurboGears] Re: Widgets redux, call for testers
Ronald Jaramillo wrote: Hi Michele, Hi Ronald, Cool, just a nit: Could you use and underscore instead of '-' betwen widget.field_id and value? I don't like to see price-2 as a radio option. Underscores make it clear (in the HTML/javascript/css) that we are talking about strings. I told you this was a nit =) Done in 0.6 (also with an example of using dynamic options). By the way I would love to hear more of these nits, regarding id and classes we should try to provide the best defaults IMHO, so if you (or anyone) have others nits don't esitate to point them out. For example, in this widgets every field embedded inside a form has and id of the type form-name_field-id (just to avoid possible ids collisions, like footer and so on). So for a form whose name is page you get, for example: id=page_name Ciao Michele
[TurboGears] Re: RhubarbTart
Simon Belak wrote: http://rhubarbtart.org/index.html RhubarbTart is a light object publishing web framework built on WSGI and Paste. RhubarbTart is based on the CherryPy object publishing model. It is light and simple, using WSGI components from Paste to compliment the object publishing system with other features typical of a web framework This could be an interesting alternative to CherryPaste, provided we (I for one centenary do) want Paste before CherryPy 3.0. Cheers, Simon I'm not the only one who noticed this then. :-) I tried it out last week and finally got around to play out of the box with EvalException (really cool and helpful, and the server doesn't stop executing for a typo). Very nice plus WSGI/Paste plus CherryPy way of working (that I like a lot). Probably not ready yet, anyway there is already a lot that it can reuse from Paste. Looking forward to it myself. :-) Ciao Michele
[TurboGears] Re: Selenium4Gears
Hello Ronald, I've watched the screencast and it looks very promising. Although when I try to import the selenium4gears provided by you I only get the following error: Traceback (most recent call last): File ./prototyp2-start.py, line 20, in ? from prototyp2.controllers import Root File /home/faer/workspace/prototyp3/prototyp2/controllers.py, line 8, in ? from selenium4gears import Selenium File /home/faer/workspace/prototyp3/__init__.py, line 20, in ? File /home/faer/workspace/turbogears/turbogears/i18n/tg_gettext.py, line 45, in gettext return gettext_f(key, locale, domain) File /home/faer/workspace/turbogears/turbogears/i18n/tg_gettext.py, line 54, in _gettext if locale is None:locale = get_locale() File /home/faer/workspace/turbogears/turbogears/i18n/utils.py, line 64, in get_locale locale = get_locale_f() File /home/faer/workspace/turbogears/turbogears/i18n/utils.py, line 77, in _get_locale locale = cherrypy.session.get(locale_key) File /usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/filters/sessionfilter.py, line 391, in __getattr__ sess = cherrypy.request._session File /usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/__init__.py, line 41, in __getattr__ childobject = getattr(serving, self.__attrname__) AttributeError: 'thread._local' object has no attribute 'request' Do you have an idea what I should change? Thanks for your help in advance. Regards, Fabian
[TurboGears] Re: RhubarbTart
On 1/30/06, Bob Ippolito [EMAIL PROTECTED] wrote: This seems like a much simpler and more robust platform to build on top of. It'd probably help out with performance too, since it doesn't have all of that filter crap on every hit (which belongs in middleware or decorators anyway, not per-object). I'd trade the advantages of WSGI for the stability/ancestry of CherryPy any day, but I'm not Kevin :) That may be, but you *are* Bob. I tend to pay attention to your opinions, because they're often pretty close to the mark. As an aside to this, Christian *dowski has put forth a minor update to the CP server that allows use of WSGI middleware with CherryPy: http://projects.dowski.com/projects/cp_middleware_server Something that struck me as a big gap in RhubarbTart is session handling. Earlier today, though, Christian linked to a WSGI session handler, so I guess there is something out there. Here's my philosophy on stuff like this: I aim for TurboGears to be best-of-breed. The definition of best-of-breed will change over time. (It'll also vary from person to person, but there's not much I can do about that.) As the best changes, I'd like to see TurboGears change with it. Of course, changes need to have reasonable migration paths and all of that, which is the primary limiting factor. But, the bigger the win, the easier it is to justify a slightly more painful transition. Kevin
[TurboGears] Re: Selenium4Gears
Hi Fabian,You are running an older version of CherryPy, after doing a svn update on your TG development and the setup.py develop dance, run "easy_install ." in CP's source directory (under thirdparty/cheerypy)Cheers.RonaldOn Jan 30, 2006, at 10:02 PM, [EMAIL PROTECTED] wrote:Hello Ronald,I've watched the screencast and it looks very promising. Although whenI try to import the selenium4gears provided by you I only get thefollowing error:Traceback (most recent call last): File "./prototyp2-start.py", line 20, in ? from prototyp2.controllers import Root File "/home/faer/workspace/prototyp3/prototyp2/controllers.py", line8, in ? from selenium4gears import Selenium File "/home/faer/workspace/prototyp3/__init__.py", line 20, in ? File "/home/faer/workspace/turbogears/turbogears/i18n/tg_gettext.py",line 45, in gettext return gettext_f(key, locale, domain) File "/home/faer/workspace/turbogears/turbogears/i18n/tg_gettext.py",line 54, in _gettext if locale is None:locale = get_locale() File "/home/faer/workspace/turbogears/turbogears/i18n/utils.py", line64, in get_locale locale = get_locale_f() File "/home/faer/workspace/turbogears/turbogears/i18n/utils.py", line77, in _get_locale locale = cherrypy.session.get(locale_key) File"/usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/filters/sessionfilter.py",line 391, in __getattr__ sess = cherrypy.request._session File"/usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/__init__.py",line 41, in __getattr__ childobject = getattr(serving, self.__attrname__)AttributeError: 'thread._local' object has no attribute 'request'Do you have an idea what I should change?Thanks for your help in advance.Regards,Fabian Henriksvej 15 2400 København NV +45 22 27 85 11 [EMAIL PROTECTED]
[TurboGears] Re: RhubarbTart
It could be interesting to see how TG supports such a migration and see Paste and WSGI in real life cases :) - Sylvain Kevin Dangoor a écrit : On 1/30/06, Bob Ippolito [EMAIL PROTECTED] wrote: This seems like a much simpler and more robust platform to build on top of. It'd probably help out with performance too, since it doesn't have all of that filter crap on every hit (which belongs in middleware or decorators anyway, not per-object). I'd trade the advantages of WSGI for the stability/ancestry of CherryPy any day, but I'm not Kevin :) That may be, but you *are* Bob. I tend to pay attention to your opinions, because they're often pretty close to the mark. As an aside to this, Christian *dowski has put forth a minor update to the CP server that allows use of WSGI middleware with CherryPy: http://projects.dowski.com/projects/cp_middleware_server Something that struck me as a big gap in RhubarbTart is session handling. Earlier today, though, Christian linked to a WSGI session handler, so I guess there is something out there. Here's my philosophy on stuff like this: I aim for TurboGears to be best-of-breed. The definition of best-of-breed will change over time. (It'll also vary from person to person, but there's not much I can do about that.) As the best changes, I'd like to see TurboGears change with it. Of course, changes need to have reasonable migration paths and all of that, which is the primary limiting factor. But, the bigger the win, the easier it is to justify a slightly more painful transition. Kevin
[TurboGears] Re: RhubarbTart
Myghty has a session system thats usable outside of Myghty: http://www.myghty.org/trac/wiki/ContainerAPI I should also note that this ContainerAPI is not only used for sessions, but also for caching pages and sub-sections of pages for blazing speed. Since you can cache anything thats pickle-able, there's a lot of caching flexibility. This system also has not had any of the deadlock issues that seem to have plagued CP's session filter, I've been using Myghty sessions for over a year now on a moderately high traffic site without a prob. Ideally we could split the Container caching system into a small bit of middleware to make to make it easier for all our uses, it's only a few files. It's also worth noting that in Perl, HTML::Mason (Myghty's a port of it) uses Cache::Cache. That is, the Perl folks have a Cache library they can plug-in to other apps/webapps. Mike Bayer (creator of Myghty) has indicated he has no problem with this, as long as the Cache library doesn't become too generic as that made Perl's Cache::Cache a bit of a hassle. - Ben
[TurboGears] Re: AttributeError: 'thread._local' object has no attribute 'request'
Jorge Godoy [EMAIL PROTECTED] writes: Alberto [EMAIL PROTECTED] writes: Ok, I've just seen you've filed a ticket (http://trac.turbogears.org/turbogears/ticket/485) on this. I've also tested it with TG 570, besides what is in the bug report -- that was what I had working before switching to using widgets -- and the same problem... So, this is something *old* in the code (as in the bug, it was present in r.485)... It looks like the problem was with the use of _ instead of lazy_gettext when instantiating widgets. So, just to open another discussion, what would be the drawbacks of having _ to use lazy_gettext all the time or just for widgets? _ is a standard and having it using the right function all the time looks like a plus to me. What do you think about it? -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: RhubarbTart
Paste is used for deployment of the following Pylons (heavily WSGI/Paste integrated) webapp: http://hellanzb.com/trac/wiki/HellaHella This webapp has been downloaded and deployed by dozens of users on a variety of different platforms without issues. When it comes to a production setup, Paste really isn't doing much, it's just starting flup's fcgi/scgi server which then calls your WSGI setup. It does give you some handy daemonizing functionality as well. - Ben
[TurboGears] Re: RhubarbTart
On 1/30/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: It could be interesting to see how TG supports such a migration and see Paste and WSGI in real life cases :) That would be interesting :) Note that I didn't say that I'm going to check in a switch to RhubarbTart today :) Things like this are interesting and useful for experimentation, but there's definitely a lot of work before something like this has proved its mettle. Kevin
[TurboGears] Re: RhubarbTart
How about a Paste branch targeted for merging by 1.0 if it proves successful? Simon Kevin Dangoor wrote: On 1/30/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: It could be interesting to see how TG supports such a migration and see Paste and WSGI in real life cases :) That would be interesting :) Note that I didn't say that I'm going to check in a switch to RhubarbTart today :) Things like this are interesting and useful for experimentation, but there's definitely a lot of work before something like this has proved its mettle. Kevin
[TurboGears] Re: RhubarbTart
On 1/30/06, Simon Belak [EMAIL PROTECTED] wrote: How about a Paste branch targeted for merging by 1.0 if it proves successful? I wouldn't have the bandwidth personally for such an undertaking in that timeframe... I'd be happy to create a branch, though, if someone wants to experiment with it. Kevin
[TurboGears] Re: RhubarbTart
On 1/30/06, Ben Bangert [EMAIL PROTECTED] wrote: Myghty has a session system thats usable outside of Myghty: http://www.myghty.org/trac/wiki/ContainerAPI I should also note that this ContainerAPI is not only used for sessions, but also for caching pages and sub-sections of pages for blazing speed. Since you can cache anything thats pickle-able, there's a lot of caching flexibility. This system also has not had any of the deadlock issues that seem to have plagued CP's session filter, I've been using Myghty sessions for over a year now on a moderately high traffic site without a prob. This looks like a nice API. I think the only thing that session middleware would do on top of that API is automatically assign a session ID. Kevin
[TurboGears] Re: RhubarbTart
Kevin Dangoor wrote: On 1/30/06, Bob Ippolito [EMAIL PROTECTED] wrote: This seems like a much simpler and more robust platform to build on top of. It'd probably help out with performance too, since it doesn't have all of that filter crap on every hit (which belongs in middleware or decorators anyway, not per-object). I'd trade the advantages of WSGI for the stability/ancestry of CherryPy any day, but I'm not Kevin :) Hopefully filter dispatching will be improved in the future. That may be, but you *are* Bob. I tend to pay attention to your opinions, because they're often pretty close to the mark. As an aside to this, Christian *dowski has put forth a minor update to the CP server that allows use of WSGI middleware with CherryPy: http://projects.dowski.com/projects/cp_middleware_server I am hoping that this will be adopted into the CP core. Here is the open ticket with a patch and and example that uses EvalException and Allan Saddi's session middleware. http://www.cherrypy.org/ticket/455 If it is not included in the CP core, I will release it separately. This can be used in conjunction with my wsgi_filter module so that CP can dispatch to other wsgi applications. http://projects.dowski.com/projects/wsgi_filter Incidentally, WSGI filter should work with stock CP 2.2beta. Christian Wyglendowski (not *dowski ;-) http://www.dowski.com
[TurboGears] Re: RhubarbTart
Kevin Dangoor wrote: On 1/30/06, Bob Ippolito [EMAIL PROTECTED] wrote: This seems like a much simpler and more robust platform to build on top of. It'd probably help out with performance too, since it doesn't have all of that filter crap on every hit (which belongs in middleware or decorators anyway, not per-object). I'd trade the advantages of WSGI for the stability/ancestry of CherryPy any day, but I'm not Kevin :) That may be, but you *are* Bob. I tend to pay attention to your opinions, because they're often pretty close to the mark. As an aside to this, Christian *dowski has put forth a minor update to the CP server that allows use of WSGI middleware with CherryPy: http://projects.dowski.com/projects/cp_middleware_server Something that struck me as a big gap in RhubarbTart is session handling. Earlier today, though, Christian linked to a WSGI session handler, so I guess there is something out there. There's lots of things out there for sessions; I think this is a relatively minor point, since RhubarbTart should be adaptable to any WSGI session setup, and all it takes to WSGIify a session library is very minor glue. The only session middleware I've really looked at is flup, and there are some problems with it (mostly that the session is loaded on every request, not on demand). Paste's built-in sessions are also fairly crude. But stuff is out there, and how it is integrated or what is chosen isn't dependent on RhubarbTart. Generally speaking the design provides more free variables for best-of-breed selection. No one piece is critically central (except for the WSGI protocol, but that's a protocol, not an API). Even Paste is used in relative minor ways -- the imports are all basic utilities (e.g., parse form variables), or applying a default (and optional) set of middleware to form the typical featureset of a framework. I think additionally that the growing work and number of contributors in TG makes it critical that there be more internal decoupling, with possibly differing release schedules. Also, regarding stability, Julian has been adding very good test coverage for RT, so I think it will be quite stable. Testability is aided by the fact that RT is very small. Here's my philosophy on stuff like this: I aim for TurboGears to be best-of-breed. The definition of best-of-breed will change over time. (It'll also vary from person to person, but there's not much I can do about that.) As the best changes, I'd like to see TurboGears change with it. Of course, changes need to have reasonable migration paths and all of that, which is the primary limiting factor. But, the bigger the win, the easier it is to justify a slightly more painful transition. We talked about this stuff some in a private email. I didn't propose anything before 0.9, except hopefully some changes so that applications written against 0.9 won't require major updates (maybe any updates) to work with a possible future TG+RhubarbTart combo. My experience with CherryPaste showed a couple different problems: * Identifying the base of the application. request.app_url is really easy to support (and RhubarbTart includes that). I think there was a proposal about an additional attribute on controllers (is_root_app or something), and that would also be easy to support. I'm baffled how tree.mount is supposed to be used, though I suspect it will be hard to support. * Serving static files. Static file serving as a filter seems rather weird to me. Ideally, I'd like to see: static_dir = os.path.join(os.path.dirname(__file__), 'static') class Foo: static = turbogears.StaticDir(static_dir) # or maybe, for using pkg_resources: static = turbogears.StaticDir(__name__, 'static') I don't know what's considered best practice right now, but CatWalk's registering of static-file-related configuration when you get the index page was particularly hard to deal with. * Imports of CP HTTP-related exceptions, and cherrypy.request/response. These are fairly trivial, since changing cherrypy to rhubarbtart will mostly work (and whatever differences are there can and should be fixed). If TG insulated this (e.g., you import turbogears.request), then applications might require zero changes. RhubarbTart could also provide a cherrypy module for backward compatibility, but I'd really rather not (unless perhaps it was explicitly enabled by the app and spewed warnings). * Filters. CP-style filters could be implemented in RhubarbTart, but I'd rather just not. The filters in TG could be reworked or have extra interfaces to be phrased as WSGI middleware. I think the actual application-facing interface to things like Identity don't need to be changed, so this might not be an issue. Since TG uses decorators more than filters (for app-visible APIs), I think this is mostly OK as-is. There might be other aspects, but those are what I hit. I think most of these changes have
[TurboGears] Re: wiki got spammed
There's a recipe at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440588 that generates CAPTCHAS (though they're certainly quite odd looking!). If this recipe is fine I could try to write a Trac plugin using it (or a variation) when I have some time. I need to write a CAPTCHA generator somewhen for a project im working on so I could join efforts. Alberto. Kevin Dangoor wrote: On 1/30/06, Kevin Dangoor [EMAIL PROTECTED] wrote: If all goes well, I may then make all updates require authentication. Oh, and I'll say it again: what would be really great is some kind of turing test style question or CAPTCHA instead of requiring authentication. If anyone happens to spot or write a Trac plugin that does this, let me know! Kevin
[TurboGears] Re: RhubarbTart
On Jan 30, 2006, at 2:25 PM, Ian Bicking wrote: Kevin Dangoor wrote: Here's my philosophy on stuff like this: I aim for TurboGears to be best-of-breed. The definition of best-of-breed will change over time. (It'll also vary from person to person, but there's not much I can do about that.) As the best changes, I'd like to see TurboGears change with it. Of course, changes need to have reasonable migration paths and all of that, which is the primary limiting factor. But, the bigger the win, the easier it is to justify a slightly more painful transition. ... * Filters. CP-style filters could be implemented in RhubarbTart, but I'd rather just not. The filters in TG could be reworked or have extra interfaces to be phrased as WSGI middleware. I think the actual application-facing interface to things like Identity don't need to be changed, so this might not be an issue. Since TG uses decorators more than filters (for app-visible APIs), I think this is mostly OK as-is. In my experience, filters are a bad API anyway. Every time I've ever wanted to use a filter, it was for a particular URL, which isn't really supported without lots of jiggering. -bob
[TurboGears] Re: Any body know how to build self foreign key model
well, I'm a BIG newbie with sqlobject and I have tryed this one. Doing debug I see that this example don't create 'sub_category' column: 1/Query : CREATE TABLE cat ( id INTEGER PRIMARY KEY, par_category_id INT, category_name VARCHAR(30) NOT NULL UNIQUE ) 1/QueryR : CREATE TABLE cat ( id INTEGER PRIMARY KEY, par_category_id INT, category_name VARCHAR(30) NOT NULL UNIQUE Have I missed something? Thanks for your help... Helio Pereira
[TurboGears] cElementTree 1.0.5 for windows requires a compiler?
Hi, r605 upgraded cElementTree from 1.0.2 to 1.0.5 but my windows machine, running setup.py develop barf an error: 'error: Python was built with version 7.1 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed.' Hu? Cheers. Ronald Ronald Jaramillo mail: ronald AT checkandshare DOT com blog: http://www.checkandshare.com/blog
[TurboGears] Re: wiki got spammed
Kevin Dangoor wrote: On 1/30/06, Alberto [EMAIL PROTECTED] wrote: It's sad... but I think we need some sort of authentication at the Trac. Or put some sort of Hacker Page a là vserver ;) (http://linux-vserver.org/Hacker+Page). I just turned on the account manager plugin again so that people can register. People had reported that they weren't seeing their accounts become active immediately, which would be the primary concern there, but let's give that another try. If all goes well, I may then make all updates require authentication. I still have a little polishing to do (mostly in the login screen), but I'm going to be using openid for authentication in front of trac: http://trac.pythonpaste.org/ You can get openid accounts from a few places; myopenid.com and videntity.org seem the best options right now (videntity has more features). This way I won't have to handle user management at all. This doesn't stop all spam necessarily, but I assume it will stop it until openid becomes popular ;) Hopefully complimentary trust-based systems will also emerge before that happens. Plus you get single-signon, which doesn't matter yet (single-signon only works if sites use it, and not many use openid yet) -- but if openid catches on in open source circles that would be enough to provide real utility to users. I'm planning on leaving ticket modification open, but closing wiki modification and ticket creation. (I'd actually prefer a simple/flatter system than a wiki for document contributions, so I'm mostly trying to ignore Trac's wiki.) -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
[TurboGears] Re: cElementTree 1.0.5 for windows requires a compiler?
Ronald, I ran into a similar issue with cElementTree. In my case, it was asking for the .Net compiler. I found that running setup.py install (rather than setup.py develop) on the SVN code fixed the problem. Sean
[TurboGears] combined scgiserver + xmlrpcFilter?
I'm running the following bit of code: from cherrypy._cpwsgi import wsgiApp from paste.util.scgiserver import serve_application if useScgi: cherrypy.server.start(initOnly=True, serverClass=None) serve_application(application=wsgiApp, prefix=/, port=4080) else: cherrypy.server.start() Adding xmlrpcFilter to the mix fails when useScgi == True. Any ideas on how I might get a CherryPy application working with scgiserver + xmlrpcFilter?
[TurboGears] Re: A couple of database puzzles
For me, hub.commit() worked fine for adding a new record. I had debug=1 on my dburi and I saw the INSERT happen, and the COMMIT happen on the same connection. If you look at hub in your shell, you'll find that it's a PackageHub. When you do hub.commit, you're actually talking to the AutoConnectHub that's responsible for doing the work (PackageHub has a __getattr__ that delegates to the AutoConnectHub underneath). So, this may be related to my other problem, which is that on my Ubuntu Laptop I can't use notrans_ to connect to a mysql database, because it is not getting stripped off. (Ticket #346). Make sure that hub, when displayed in the shell, is in fact a PackageHub. It is definitely seems to be. Help(hub) shows PackageHub information Just to confirm something else: you are running tg-admin shell from the top level directory of your project, right? Absolutely. Anything else causes problems ;) It's worth making sure that the config that's coming through is the one that's desired. You can always run cherrypy.config.get() statements to see if sqlobject.dburi is what you'd expect. I've attached the output of an interactive session where I get the dburi from cherrypy.config.get and try some database connection stuff. For some reason that I can't quite figure out the ?debug=true link seems to work here, where it did not on my computer at home. I'll check into that later tonight. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog C:\TURBOG~1\LINK-K~1tg-admin shell Python 2.4.1 (#65, Jun 20 2005, 17:01:55) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. (InteractiveConsole) import cherrypy cherrypy.config.get(sqlobject.dburi) 'sqlite:///c|/turbogears/Link-Keeper/book.db?debug=1' b=Bookmarks.select() for a in b: ...print a.link ... 1/Select : SELECT bookmarks.id, bookmarks.name, bookmarks.link, bookmarks.description FROM bookmarks WHERE 1 = 1 1/QueryR : SELECT bookmarks.id, bookmarks.name, bookmarks.link, bookmarks.description FROM bookmarks WHERE 1 = 1 http://compoundthinking.com/blog http://google.com http://www.turbogears.org Bookmarks(name=1, link=http://one.com;, description=random link) 1/QueryIns: INSERT INTO bookmarks (link, description, name) VALUES ('http://one.com', 'random link', '1') 1/QueryOne: SELECT name, link, description FROM bookmarks WHERE id = 4 1/QueryR : SELECT name, link, description FROM bookmarks WHERE id = 4 Bookmarks 4 name='1' link='http://one.com' description='random link' hub.commit bound method AutoConnectHub.commit of turbogears.database.AutoConnectHub object at 0x012BABF0 ^Z C:\TURBOG~1\LINK-K~1tg-admin shell Python 2.4.1 (#65, Jun 20 2005, 17:01:55) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. (InteractiveConsole) b=Bookmarks.select() for a in b: ...print a.link ... 1/Select : SELECT bookmarks.id, bookmarks.name, bookmarks.link, bookmarks.description FROM bookmarks WHERE 1 = 1 1/QueryR : SELECT bookmarks.id, bookmarks.name, bookmarks.link, bookmarks.description FROM bookmarks WHERE 1 = 1 http://compoundthinking.com/blog http://google.com http://www.turbogears.org
[TurboGears] Re: Any body know how to build self foreign key model
Including models that illustrate a tricky SQLObject construct in ModelDesigner is a great idea, I will accept those gladly, people can send them to me directly or paste their model to a track tricket (label enhancement) Cheers. Ronald ps. hm. the inheritance example from the SQLObject documentation is probably a good one to have On Jan 31, 2006, at 1:24 AM, Joost Moesker wrote: This seems to be frequent question on the list. Maybe its a good a idea to add a catagory model to the ModelDesigner webshop example? Ronald Jaramillo mail: ronald AT checkandshare DOT com blog: http://www.checkandshare.com/blog
[TurboGears] Re: wiki got spammed
You could also try http://captchas.net/sample/python/ Alberto a écrit : There's a recipe at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440588 that generates CAPTCHAS (though they're certainly quite odd looking!). If this recipe is fine I could try to write a Trac plugin using it (or a variation) when I have some time. I need to write a CAPTCHA generator somewhen for a project im working on so I could join efforts. Alberto. Kevin Dangoor wrote: On 1/30/06, Kevin Dangoor [EMAIL PROTECTED] wrote: If all goes well, I may then make all updates require authentication. Oh, and I'll say it again: what would be really great is some kind of turing test style question or CAPTCHA instead of requiring authentication. If anyone happens to spot or write a Trac plugin that does this, let me know! Kevin -- -- David Dwayne BernardTurboHtmlPy creator signature.asc Description: OpenPGP digital signature