[TurboGears] Re: Kid templates not recompiled on change
Max Ischenko [EMAIL PROTECTED] writes: I'm not sure whose fault this is and thus decided to bring this issue to the mailing list. IMO, this is TurboKid that knows whether templates should be reloaded on change and then check this particular template needs refreshing and then signaling Kid to reload it (e.g. delete module from the sys.modules global). On the other hand, when I modify my templates here and just press reload on the browser then I get the new version... Are you modifying things on production or development mode? -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: Cleaned up widget API
Hi Alberto, Yes, it's not backward compatible in a way that it requires an SQLObject model beforehand instead of reading it from SelectResults. This is intentional and I think now is a good time to make this change. I probably should have indicated that explicitly, sorry for confusion. My non-authoritative opinion that in this case DataGrid flexibility of adapting to different model classes is actually harmful. Passing the model explicitly is IMO better and safer. Plus, only a trivial change required to DataController to init list_widget that way (it has sql_class available at ctor). OTOH, may be a good route could be to have a streamlined DataGrid class that knows nothing about SQLObject's model and/or SelectResults (and takes a single required ctor arg: fields) and then add, say, FastDataGrid subclass that can derive fields from model (like my NewDataGrid version did) or compute them at runtime (like yours version did).
[TurboGears] Re: Cleaned up widget API
It's not only for theadsafety but also to keep the logic outside of templates, just compare the new form template with the old one if you need an example. :-) Well, I don't think availability of 'widget' in template namespace is the reason. Plus, as history teaches us, assuming a user is less competent then the author and forcing particular behaviour upon him is no good. ;-) To summarize: 1. I don't like been forced to write boilerplate code like this: def update_data(self, d): d['headers'] = self.headers d['collist'] = self.collist d['getcol'] = self.getcol 2. I think using widget.collist or widget.headers from within template is clearer then simply collist or headers. No need to wonder where's particular variable come from. And less cluttering going on. Just my opinion. Max.
[TurboGears] Re: FastData coming along well.
Hmm...My experience was almost opposite. The formmaker is very rigid and hard to customize. In the end, I resorted to override generic column function for specific data items which is no more then a crude hack. Do you have any thoughts on what would be an easier interface for you? Here are a couple of thoughts 1) you can set a widget attribute on a column to specify how that column is generally displayed. (breaks MVC, but is terribly convenient). this should be a trivial change. Didn't know about that trick, thanks! 2) maybe we can make use of/extend the new WidgetDeclaration class to make it easy to customize the output. We could do something so that you don't have to declare *every* widget... just the ones you want to override. May be. Unfortunately I don't have any good thoughts about the 'better' interface right now but only can complain how rigit the current interface is wrt extention. ;-)
[TurboGears] Re: Kid templates not recompiled on change
On the other hand, when I modify my templates here and just press reload on the browser then I get the new version... Which version of Kid you're using? I've installed Kid from thirdparty, that's Kid 0.9a. Are you modifying things on production or development mode? development.
[TurboGears] Re: Cleaned up widget API
Max Ischenko [EMAIL PROTECTED] writes: My non-authoritative opinion that in this case DataGrid flexibility of adapting to different model classes is actually harmful. Passing the model explicitly is IMO better and safer. Plus, only a trivial change required to DataController to init list_widget that way (it has sql_class available at ctor). So, if we pass it directly, how can we filter results? Lets suppose I want to filter data by sex or age or something else. If I pass a SelectResult then I can filter by any field and using anything supported by SQLObject. If we pass the model directly and it isn't possible to filter results before using them on the grid one would have to create several views and put those on the model... OTOH, may be a good route could be to have a streamlined DataGrid class that knows nothing about SQLObject's model and/or SelectResults (and takes a single required ctor arg: fields) and then add, say, FastDataGrid subclass that can derive fields from model (like my NewDataGrid version did) or compute them at runtime (like yours version did). I think that subclassing for filtering results is not a good design here, specially because it is very simple to have these results filtered and in the form of an iterator. -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: Cleaned up widget API
Max Ischenko [EMAIL PROTECTED] writes: 1. I don't like been forced to write boilerplate code like this: def update_data(self, d): d['headers'] = self.headers d['collist'] = self.collist d['getcol'] = self.getcol 2. I think using widget.collist or widget.headers from within template is clearer then simply collist or headers. No need to wonder where's particular variable come from. And less cluttering going on. I'm not, yet, writing my own widgets -- I may do something like that soon, though -- but I agree with Max here. It looks more obvious to what is being used on the template and the update_data method seems unnecessary... But then, I'm new to all this web stuff and I don't know the repercussions of this change, though. -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: Kid templates not recompiled on change
Max Ischenko [EMAIL PROTECTED] writes: On the other hand, when I modify my templates here and just press reload on the browser then I get the new version... Which version of Kid you're using? Everything from TG trunk. So it is whatever Kevin has flagged to be used with the trunk. I've installed Kid from thirdparty, that's Kid 0.9a. That's what I use. [EMAIL PROTECTED] ~/desenvolvimento/python/TurboGears/trunk/thirdparty/kid % LANG= svn info Path: . URL: svn://lesscode.org/kid/trunk Repository UUID: 2e2b2306-ebee-0310-be8d-abc9dabbc1eb Revision: 265 Node Kind: directory Schedule: normal Last Changed Author: cito Last Changed Rev: 265 Last Changed Date: 2006-01-30 11:17:20 -0200 (Mon, 30 Jan 2006) Properties Last Updated: 2006-01-10 19:39:30 -0200 (Tue, 10 Jan 2006) [EMAIL PROTECTED] ~/desenvolvimento/python/TurboGears/trunk/thirdparty/kid % Are you modifying things on production or development mode? development. Same as here with me. And I have the feeling that templates on development mode are recompiled everytime. -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: Cleaned up widget API
Hi Max, On Feb 5, 2006, at 1:02 PM, Max Ischenko wrote: My non-authoritative opinion that in this case DataGrid flexibility of adapting to different model classes is actually harmful. Passing the model explicitly is IMO better and safer. Plus, only a trivial change required to DataController to init list_widget that way (it has sql_class available at ctor). I don't see why it can be harmful. Computing headers, etc... at runtime opens the possibility to a non-model-specific grid which can be used for displaying any kind of SelectResults with the same controller/grid. Anyway, I haven't got a real use-case for this right now so I can't back up my opinion any further. My intention when porting it was to keep the interface and behaviour intact, so no functionallity I wasn't using (but somene might be, like non-SO grids) was lost. This way migration wouldn't be so painful (probably Randall doesn't think alike, though ;) OTOH, may be a good route could be to have a streamlined DataGrid class that knows nothing about SQLObject's model and/or SelectResults (and takes a single required ctor arg: fields) and then add, say, FastDataGrid subclass that can derive fields from model (like my NewDataGrid version did) or compute them at runtime (like yours version did). I agree with this. I can see that DataGrid as it's currently impemented could be used also for a non SO grid, which isn't very specific... I favor a refactoring out of the grid basic stuff into a separate subclass that could be used for displaying any kind of gridded data structure (like a parsed logfile, for example) and have a different grid for SO SelectResults. Anyway, I *believe* the current behaviour (overriding fields at display time) should be preserved, as I think would keep in line with the new widgets' capabilities, quoting Kevin previuously in this thread: The other plus that came out of this plan (which is not yet implemented, but also not hard) is the ability to override everything at display() time. Regards, Alberto
[TurboGears] Re: Cleaned up widget API
Max Ischenko [EMAIL PROTECTED] writes:
1. I don't like been forced to write boilerplate code like this:
def update_data(self, d):
d['headers'] = self.headers
d['collist'] = self.collist
d['getcol'] = self.getcol
2. I think using widget.collist or widget.headers from within
template is clearer then simply collist or headers. No need to
wonder where's particular variable come from. And less cluttering
going
on.
I agree that the boiler-plate code is unnecesary and ugly.
But Michele made a good point on this: it encourages coding logic at
the python side (at update_data) and just sending placeholder-
fillers and iterables (selectresults, option lists, etc..) to the
template... it's more MVCish.
On Feb 5, 2006, at 1:47 PM, Jorge Godoy wrote:
I'm not, yet, writing my own widgets -- I may do something like
that soon,
though -- but I agree with Max here. It looks more obvious to what
is being
used on the template and the update_data method seems
unnecessary... But
then, I'm new to all this web stuff and I don't know the
repercussions of this
change, though.
--
Jorge Godoy [EMAIL PROTECTED]
The update_data method *IS* needed. Without it we wouldn't be able to
override widget attributes at display time (which I think is
essential) or to pass new variables to the template for each render
(like passing a new css class for changing a textfield's background
color, etc).
It's what makes the new widgets thread-safer too: a new dictionary is
built at each render for the values needed for EACH request. And
gives more control of what actually is being sent to the template
(think of it as a mini-controller for a mini-template :)
I still think something must be done to reduce the boiler-plate code
though, maybe something like this:
def update_data(self, d):
self.update_data_from_self(d, ['headers', 'colist', 'getcol'])
...
It's still, boilerplate, but shorter...
this idea could even be factored out into the Widget class so it
does it implicitly on every update_data, something like:
class MyWidget(Widget):
update_template_with = ['headers', 'colist', 'getcol']
.
the code handling this could be something like (at Widget.display():
d = {}
for attr in self.update_template_with:# or
self.__class__.update_template_with
d[attr] = getattr(self, attr, None)
self.update_data(kw)
return view.transform(kw, template=self.template)
This last approach would reduce the boilerplate while preserving the
all-goodness ;) of update_data.
If full qualification is preferred (a là widget.name) it shouldn't be
too difficult to implement either.
What I'm positive about is that the widget instance should NOT be
passed to the template, just to emphasize that the template variables
are updated at every render (plus all the, now diminished, thread-
safety issues).
Regards, Alberto
[TurboGears] Re: ip address in visit?
The only thing I'd point out is that you didn't check whether your extension was enabled in `start_extension`. I updated the the tutorial to make that check. Thanks.
[TurboGears] Re: Kid templates not recompiled on change
This should work find for the top level templates. Base templates are a little harder. I had a fix in at one time that made it work, but unfortunately an least 25% of the people who tried it had other issues. Since I could never reproduce on my system I could not debug it. I had to roll out the change since those that did have the problem could not debug it. Try adding kid.reloadbases = True to your config file and see it that helps. Random idea and I am not sure why I didn't think of this sooner...maybe restart cherry after each request in development mode. Why wait to detect that something has changed?-- Davidhttp://www.traceback.org
[TurboGears] Re: Anyone using py:layout or py:slot ?
On 2/5/06, Dan Jacob [EMAIL PROTECTED] wrote: I've noticed that the latest SVN of Kid has new tags for handlinglayout templates, py:layout and py:slot. Has anyone used these orwritten any documentation about them ? How do they work with py:matchand py:def for example ? I have used py:layout quite a bit because I am trying to expand on the unit testing. I actually like it better that py:match for many things. Since the documentation is only published for releases you will have to use the RST source doc[0] from SVN. [0] http://lesscode.org/projects/kid/file/trunk/doc/language.txt -- Davidhttp://www.traceback.org
[TurboGears] Re: Anyone using py:layout or py:slot ?
2006/2/5, David Stanek [EMAIL PROTECTED]: On 2/5/06, Dan Jacob [EMAIL PROTECTED] wrote: I've noticed that the latest SVN of Kid has new tags for handling layout templates, py:layout and py:slot. Has anyone used these or written any documentation about them ? How do they work with py:match and py:def for example ? I have used py:layout quite a bit because I am trying to expand on the unit testing. I actually like it better that py:match for many things. Since the documentation is only published for releases you will have to use the RST source doc[0] from SVN. The problem I've noticed with py:layout in TG is that the layout template doesn't have std variables available. I wonder if it can be fixed -- Ksenia
[TurboGears] Re: Cleaned up widget API
Alberto Valverde [EMAIL PROTECTED] writes: The update_data method *IS* needed. Without it we wouldn't be able to override widget attributes at display time (which I think is essential) or to pass new variables to the template for each render (like passing a new css class for changing a textfield's background color, etc). It's what makes the new widgets thread-safer too: a new dictionary is built at each render for the values needed for EACH request. And gives more control of what actually is being sent to the template (think of it as a mini-controller for a mini-template :) This is exactly what I needed to know ;-) Thanks for your explanation. I still think something must be done to reduce the boiler-plate code though, Reduce: yes! But please make it simple and legible as well. I'd rather have 10 lines of code that are easy to maintain than having to decypher 3 or 4 lines. It will also make it clear for newcomers. What I'm positive about is that the widget instance should NOT be passed to the template, just to emphasize that the template variables are updated at every render (plus all the, now diminished, thread- safety issues). Now that I understand it, this sounds like it is the better, indeed. And would also avoid having people - like me ;-) - hurting themselves. :-) -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: Cleaned up widget API
Small fix to the code I posted:
On Feb 5, 2006, at 2:58 PM, Alberto Valverde wrote:
the code handling this could be something like (at Widget.display():
d = {}
for attr in self.update_template_with:# or
self.__class__.update_template_with
d[attr] = getattr(self, attr, None)
self.update_data(kw)
return view.transform(kw, template=self.template)
should be:
the code handling this could be something like (at Widget.display():
d = {}
for attr in self.update_template_with:# or
self.__class__.update_template_with
d[attr] = getattr(self, attr, None)
d.update(kw)
self.update_data(d)
return view.transform(d, template=self.template)
[TurboGears] Re: Identity: Attaching permissions directly to users (Ticket #505)
Jeff Watkins [EMAIL PROTECTED] writes: Now if you have a VERY small user community, applying permissions directly to the user isn't a bad model. And I run into this a lot with clients. Mostly when I encounter this model it's after they've grown from a small number of users to many hundreds or even thousands. In these cases, the permissions are often controlled by different application specialists and no one quite knows what the definitive set of permissions actually is for a given group or role. I prefer using groups even for small ammounts of users. One can, then, create one group per user if it is needed. When groups of users need one common permission, then a new group can be created and users can be assigned to it. I find that this -- one user/groups and several users/group with permissions dealt with by group -- are the best approach. -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: New 0.9 error handling checked in, watch for weirdness
Jorge Godoy [EMAIL PROTECTED] writes: It did here. At least I'm still getting the error I reported on 498, with the following traceback: Traceback (most recent call last): File /usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/_cphttptools.py, line 99, in _run self.main() File /usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/_cphttptools.py, line 247, in main body = page_handler(*virtual_path, **self.params) File string, line 3, in index File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/controllers.py, line 215, in expose func, tg_format, html, fragment, **kw) File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/database.py, line 193, in run_with_transaction retval = func(*args, **kw) File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/controllers.py, line 243, in _execute_func output = dispatch_error(func, self, **kw) File string, line 5, in dispatch_error File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/controllers.py, line 295, in _default_error_handler return getattr(self, error_source.__name__ )(**kw) File string, line 3, in index File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/controllers.py, line 211, in expose output = _execute_func(self, func, tg_format, html, fragment, **kw) File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/controllers.py, line 240, in _execute_func raise error TypeError: unsupported operand type(s) for +: 'lazystring' and 'str' I've closed the bug a while ago, as it was fixed in SVN r.645. -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: Identity: Attaching permissions directly to users (Ticket #505)
Since this seems to come up occasionally, I'm sharing my response to this ticket with the entire TG community. I'm certain at least one person will tell me that's the stupidest thing I've ever heard... Doesn't sound stupid at all :) On Feb 5, 2006, at 4:19 PM, Jeff Watkins wrote: There is nothing preventing you from creating a Model that better suits your needs, however, experience with large user communities shows that you're almost always better off modelling via Users- Groups-Permissions rather than applying permissions directly to a particular User. It's essential for user management (when there are more, than let's say 10 users :). As you pointed out. I have a little semantic quirk though: I have subclassed for one of my apps a small variation of TGs default identity scheme in which I substitute TG_Group for Role (as It fits better in my head: Permissions tied to Roles), for example, GROUP_ADMIN (which has permissions can create user, can edit user, etc...). Then it have a different Group class (which isn't the same concept as TG_Group) which models different groups in wihch users are grouped into as to limit the scope in which a GROUP_ADMIN has priviileges on, for example. These Groups have no permissions attached to them whatsoever, theyre just to relate users among themselves. Just wanted to share it with you. Regards, Alberto
[TurboGears] Using XMLRPC filter
Hi there. I was wondering, since the _cpFilterList will be deprecated in future versions of CherryPy, can someone please provide a clear example on how to impement a XMLRPC handling controller that is mounted to the Root one? Somethis to make this work: class RPCController(controllers.Root): @turbogears.expose() def test(self, i): return i+1 class Root(controllers.Root): RPC = RPCController() Thanks, Eli
[TurboGears] Request: identity example app, paging list recipe
Hi, I'm still learning TurboGears and all the other related frameworks. There are two things I'd really like to see, which I guess would be helpful for a lot of other developer,s, too. One is a properly maintained identity example application. I'm thinking of something that tracks the SVN trunk and is supposed to work and not go out of date. Another thing is that would be really helpful is an example showing a long list of records from the database in split into pages with next and prev buttons. This is also a very common feature in web applications. If there was a recipe for this in the Wiki, it'd be great. Thanks and keep up the good work, nyenyec
[TurboGears] Re: Request: identity example app, paging list recipe
To answer your second request about paging, I've been using this snippet of code: http://turbogears.blogspot.com/2005/11/simple-pager-decorator.html
[TurboGears] svn 645 sitetemplate not found error coming up again
Hi all, Here's the error, if it tells you anything. I have gone into the plugins/kid directory and run python setup.py develop and python setup.py install. Neither changed it. I had it working with 645 earlier today, but now even a complete reinstall of python and everything else always repeats this error. I had been trying to get rid of the nonetype not callable error, which is still a huge issue for me. Did the fix in turbokid 0.8 get lost in 0.9a? -Mike Traceback (most recent call last): File /home/.castor/mikez0r/lib/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/_cphttptools.py, line 99, in _run self.main() File /home/.castor/mikez0r/lib/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/_cphttptools.py, line 247, in main body = page_handler(*virtual_path, **self.params) File string, line 3, in index File /home/.castor/mikez0r/lib/lib/python2.4/site-packages/TurboGears-0.9a0dev_r645-py2.4.egg/turbogears/controllers.py, line 218, in expose func, tg_format, html, fragment, *args, **kw) File /home/.castor/mikez0r/lib/lib/python2.4/site-packages/TurboGears-0.9a0dev_r645-py2.4.egg/turbogears/database.py, line 193, in run_with_transaction retval = func(*args, **kw) File /home/.castor/mikez0r/lib/lib/python2.4/site-packages/TurboGears-0.9a0dev_r645-py2.4.egg/turbogears/controllers.py, line 253, in _execute_func return _process_output(tg_format, output, html, fragment) File /home/.castor/mikez0r/lib/lib/python2.4/site-packages/TurboGears-0.9a0dev_r645-py2.4.egg/turbogears/controllers.py, line 66, in _process_output fragment=fragment) File /home/.castor/mikez0r/lib/lib/python2.4/site-packages/TurboGears-0.9a0dev_r645-py2.4.egg/turbogears/view.py, line 60, in render return engine.render(info, format, fragment, template) File /home/.castor/mikez0r/download/trunk/plugins/kid/turbokid/kidsupport.py, line 88, in render tclass = self.load_template(template) File /home/.castor/mikez0r/download/trunk/plugins/kid/turbokid/kidsupport.py, line 42, in load_template self.load_template(self.stname, True) File /home/.castor/mikez0r/download/trunk/plugins/kid/turbokid/kidsupport.py, line 56, in load_template mod = kid.load_template(classname) File /home/.castor/mikez0r/lib/lib/python2.4/site-packages/kid-0.9a0-py2.4.egg/kid/__init__.py, line 112, in load_template raise Exception, Template not found: %s (in %s) % ( Exception: Template not found: turbogears.fastdata.templates.sitetemplate (in /home/.castor/mikez0r/elementarycatastrophe.com, /)
[TurboGears] Re: Identity: Attaching permissions directly to users (Ticket #505)
Using Users-Groups-Permissions is definitely better for any system with more than 100 users. I inherited a system (over 100 users) where permissions were managed directly to users. It was very easy and quick to fix/modify one Users permissions. However, we never could find the time to rationalize the overall permissions as most users with the same job requirements had over time evolved different permissions. Why? We never knew for sure although we ended up spending considerable time for each change trying to resolve differences. Using Users-Groups-Permissions forces one to spend more time up- front keeping permissions rationalized. Rational permissions may or may not be important in a given installation. I agree with Jeff that it should be the heavily favored option. It can be used for small user communities without a lot of additional overhead (just a little thinking beforehand). So I don't really see a downside. Neil On Feb 5, 2006, at 9:19 AM, Jeff Watkins wrote: hi, i recently start to play with the identity frameworks from turbogears and i really dont get the point of linking permission to groups. if the 'write' permission is linked against the 'admin' group, all users in admin group have write permission. if i need diferente parmission for a specific user, i need to create another group. so, what is the point? i really think that 'permissions' should be linked against 'users'. this way the 'group' should say which objects u can access and permission what u can do with given objects. There is nothing preventing you from creating a Model that better suits your needs, however, experience with large user communities shows that you're almost always better off modelling via Users- Groups-Permissions rather than applying permissions directly to a particular User. If for no other reason, provisioning new users becomes a huge problem. Consider the following example: Sally, the nurse retires and her replacement Sam needs to be provisioned in the new system. In an environment where permissions are applied via groups, Sam is made a member of the Nurse group and he immediately acquires *every* applicable permission. If permissions are applied directly to the user, you need to explicitly apply every permission in order to provision Sam. Six months later, you role out new functionality for nurses. This new functionality includes new permissions -- all nurses should have these permissions. If you've modelled your users using groups, you add the permissions to the nurses group and immediately every nurse, including Sam, can now access the new functionality. If you haven't modelled your data using groups, you need to add the permissions to every single nurse. Now ask yourself, if you don't have groups, how do you know who all the nurses are? Now if you have a VERY small user community, applying permissions directly to the user isn't a bad model. And I run into this a lot with clients. Mostly when I encounter this model it's after they've grown from a small number of users to many hundreds or even thousands. In these cases, the permissions are often controlled by different application specialists and no one quite knows what the definitive set of permissions actually is for a given group or role.
[TurboGears] Re: Cleaned up widget API
I've posted a patch for the new widgets API which you can use to avoid it: http://trac.turbogears.org/turbogears/attachment/ticket/490/ newbase_widget_vars.2.patch The discussion is at: http://trac.turbogears.org/turbogears/ticket/490 Hope i helps, Alberto. On Feb 5, 2006, at 1:09 PM, Max Ischenko wrote: 1. I don't like been forced to write boilerplate code like this: def update_data(self, d): d['headers'] = self.headers d['collist'] = self.collist d['getcol'] = self.getcol
[TurboGears] TypeError: dispatch_error() got multiple values for keyword argument 'tg_errors'
Hi! After submitting a form I get the following TraceBack: Traceback (most recent call last): File /usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/_cphttptools.py, line 99, in _run self.main() File /usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/_cphttptools.py, line 247, in main body = page_handler(*virtual_path, **self.params) File string, line 3, in default File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/controllers.py, line 218, in expose func, tg_format, html, fragment, *args, **kw) File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/database.py, line 193, in run_with_transaction retval = func(*args, **kw) File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/controllers.py, line 248, in _execute_func output = dispatch_error(func, self, *args, **kw) TypeError: dispatch_error() got multiple values for keyword argument 'tg_errors' In this page I have a DataGrid and a FormTable. I'm running Path: . URL: http://www.turbogears.org/svn/turbogears/trunk Repository UUID: 77541ad4-5f01-0410-9ede-a1b63cd9a898 Revision: 645 Node Kind: directory Schedule: normal Last Changed Author: kevin Last Changed Rev: 645 Last Changed Date: 2006-02-05 02:11:53 -0200 (Sun, 05 Feb 2006) Properties Last Updated: 2006-01-30 11:59:23 -0200 (Mon, 30 Jan 2006) Is there something I can do in my code to avoid that? -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Starting with widgets - how and where?
Hello list, could anybody please give (here or at wiki) any references how to start with widgets? I'm following SVN right now, and have read initial Kevin's posts, but things are going pretty fast here, and for somebody who (like myself) couldn't follow the google group very carefully and can only code on weekends that become an issue. I fully understand that there is no 'official doc' yet; but probably some non-trivial working examples and/or some sequence of TurboGears group postings, updated at wiki, would be enough. Thanks a lot, Victor.
[TurboGears] Re: Starting with widgets - how and where?
I would find this extremely helpful as well. But I can understand if this doesn't get done until The Release.
[TurboGears] Re: Starting with widgets - how and where?
Probably the best method is to read the source at newforms.py and newbase.py (I'm afraid). Some links that could be useful: http://groups.google.com/group/turbogears/browse_thread/thread/ d2979c2fdc937b74 http://groups.google.com/group/turbogears/browse_thread/thread/ 82b26e20576efc92 http://trac.turbogears.org/turbogears/ticket/490 http://trac.turbogears.org/turbogears/ticket/502 http://trac.turbogears.org/turbogears/wiki/WidgetsBrainStorming Hope it helps, Alberto On Feb 5, 2006, at 9:26 PM, Victor Kryukov wrote: Hello list, could anybody please give (here or at wiki) any references how to start with widgets? I'm following SVN right now, and have read initial Kevin's posts, but things are going pretty fast here, and for somebody who (like myself) couldn't follow the google group very carefully and can only code on weekends that become an issue. I fully understand that there is no 'official doc' yet; but probably some non-trivial working examples and/or some sequence of TurboGears group postings, updated at wiki, would be enough. Thanks a lot, Victor.
[TurboGears] Re: Cleaned up widget API
On 2/5/06, Max Ischenko [EMAIL PROTECTED] wrote: It's not only for theadsafety but also to keep the logic outside of templates, just compare the new form template with the old one if you need an example. :-) Well, I don't think availability of 'widget' in template namespace is the reason. Plus, as history teaches us, assuming a user is less competent then the author and forcing particular behaviour upon him is no good. ;-) I agree with this, in general. The argument could be made that the new locking behavior of widgets that prevents you from setting self.foo after you've started using a widget could be viewed as forcing behavior, but I view it more as preventing a bug. The availability of widget in the template namespace is different because that's getting more into good design vs. bad design, which is a more slushy (soft) topic. From the standpoint of widget authoring, just dropping widget into the namespace is appealing: it's the least amount of work possible. However, from the standpoint of widget *users*, there is an advantage to explicitly listing out the variables from the widget that should be available: *all* variables that the widget uses and defines in the constructor can also be overridden at display() time. For consistency's sake, it's nice to think that people wouldn't have to play a guessing game about whether they can override something. To summarize: 1. I don't like been forced to write boilerplate code like this: def update_data(self, d): d['headers'] = self.headers d['collist'] = self.collist d['getcol'] = self.getcol I'm proposing something similar to what was suggested elsewhere in the thread: a class variable that lists the attributes that should be copied from the widget to the template. template_vars = [headers, collist, getcol] It's a little more typing than just having widget available, but it provides the ability to override. There would be a method that copies those over to the dict that is called from display()... so nothing else is required if you don't override display(). 2. I think using widget.collist or widget.headers from within template is clearer then simply collist or headers. No need to wonder where's particular variable come from. And less cluttering going on. Granted with just collist you don't know if the value came from the widget, or from the template which called display(). But, there should only be a couple places that people need to check to figure out where the value they're seeing came from, and the override-per-request capability from display() overrides is important in a number of cases. Kevin
[TurboGears] Re: setlike behavior
There's a question in your patch about setlike. The purpose of the setlike class is to act like a set (things only appear once), but remember the order that things were added in. setlike is a bad name, but orderedset isn't such a great idea either. setlike exists specifically for handling JSLink, CSSLInk, etc. objects. You only want them to appear once per page, but you want them to appear in the order requested (because it matters sometimes). Kevin On 2/5/06, Alberto Valverde [EMAIL PROTECTED] wrote: I've posted a patch for the new widgets API which you can use to avoid it: http://trac.turbogears.org/turbogears/attachment/ticket/490/ newbase_widget_vars.2.patch The discussion is at: http://trac.turbogears.org/turbogears/ticket/490 Hope i helps, Alberto. On Feb 5, 2006, at 1:09 PM, Max Ischenko wrote: 1. I don't like been forced to write boilerplate code like this: def update_data(self, d): d['headers'] = self.headers d['collist'] = self.collist d['getcol'] = self.getcol -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: Cleaned up widget API
On Feb 5, 2006, at 11:06 PM, Kevin Dangoor wrote: On 2/5/06, Alberto Valverde [EMAIL PROTECTED] wrote: I've posted a patch for the new widgets API which you can use to avoid it: http://trac.turbogears.org/turbogears/attachment/ticket/490/ newbase_widget_vars.2.patch Err... that's interesting. In the email I just wrote, I suggested template_vars and that's exactly what you named it! Kevin Scary :/
[TurboGears] Re: Quickstart broken, recent?
Hi Kevin, thanks for the heads up. Unfortunately I've moved on, copying an existing project and morphing it into a new one, so I'm reluctant to touch the configuration until after Feb 9th. I'll be sure to upgrade to the latest SVN copy after the 9th, then give it a whirl. Cheers, - Aaron.
[TurboGears] Re: Starting with widgets - how and where?
Alberto Valverde wrote: Probably the best method is to read the source at newforms.py and newbase.py (I'm afraid). Some links that could be useful: http://groups.google.com/group/turbogears/browse_thread/thread/ d2979c2fdc937b74 http://groups.google.com/group/turbogears/browse_thread/thread/ 82b26e20576efc92 http://trac.turbogears.org/turbogears/ticket/490 http://trac.turbogears.org/turbogears/ticket/502 http://trac.turbogears.org/turbogears/wiki/WidgetsBrainStorming Hey, please don't look at WidgetsBrainStorming!! :-) Is totally on crack, I've written it some times ago with no complete understanding of the widgets API (please someone can remove this crap! :D). One of the best place to understand how to use widgets are the tests: http://trac.turbogears.org/turbogears/browser/trunk/turbogears/widgets/tests/test_widgets.py Ciao Michele Hope it helps, Alberto On Feb 5, 2006, at 9:26 PM, Victor Kryukov wrote: Hello list, could anybody please give (here or at wiki) any references how to start with widgets? I'm following SVN right now, and have read initial Kevin's posts, but things are going pretty fast here, and for somebody who (like myself) couldn't follow the google group very carefully and can only code on weekends that become an issue. I fully understand that there is no 'official doc' yet; but probably some non-trivial working examples and/or some sequence of TurboGears group postings, updated at wiki, would be enough. Thanks a lot, Victor.
[TurboGears] Re: Quickstart broken, recent?
On 2/5/06, OTri [EMAIL PROTECTED] wrote: Hi Kevin, thanks for the heads up. Unfortunately I've moved on, copying an existing project and morphing it into a new one, so I'm reluctant to touch the configuration until after Feb 9th. I'll be sure to upgrade to the latest SVN copy after the 9th, then give it a whirl. If you've got something coming up, that's very wise. Kevin
[TurboGears] Re: Kid templates not recompiled on change
This will work for sure, but on my system CherryPy takes 2 sec. to restart so I will find it quite annoying and not *turbo* if it restarts on every request. ;-) Ciao Michele David Stanek wrote: This should work find for the top level templates. Base templates are a little harder. I had a fix in at one time that made it work, but unfortunately an least 25% of the people who tried it had other issues. Since I could never reproduce on my system I could not debug it. I had to roll out the change since those that did have the problem could not debug it. Try adding kid.reloadbases = True to your config file and see it that helps. Random idea and I am not sure why I didn't think of this sooner...maybe restart cherry after each request in development mode. Why wait to detect that something has changed? -- David http://www.traceback.org
[TurboGears] Re: Kid templates not recompiled on change
On 2/5/06, David Stanek [EMAIL PROTECTED] wrote: Random idea and I am not sure why I didn't think of this sooner...maybe restart cherry after each request in development mode. Why wait to detect that something has changed? As Michele said, it could take some time to restart... *and* a single page view may require multiple hits to CherryPy, which could get ugly. 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: Kid templates not recompiled on change
for me it takes 0.2 sec to restart cherrypy, even if it takes much longer to start it. On 2/5/06, Kevin Dangoor [EMAIL PROTECTED] wrote: On 2/5/06, David Stanek [EMAIL PROTECTED] wrote: Random idea and I am not sure why I didn't think of this sooner...maybe restart cherry after each request in development mode. Why wait to detect that something has changed? As Michele said, it could take some time to restart... *and* a single page view may require multiple hits to CherryPy, which could get ugly. Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com -- cheers elvelind grandin
[TurboGears] Re: setlike behavior
uniquelist describes what it means better than orderedset does... orderedset usually means something else. -bob On Feb 5, 2006, at 2:09 PM, Kevin Dangoor wrote: There's a question in your patch about setlike. The purpose of the setlike class is to act like a set (things only appear once), but remember the order that things were added in. setlike is a bad name, but orderedset isn't such a great idea either. setlike exists specifically for handling JSLink, CSSLInk, etc. objects. You only want them to appear once per page, but you want them to appear in the order requested (because it matters sometimes). Kevin On 2/5/06, Alberto Valverde [EMAIL PROTECTED] wrote: I've posted a patch for the new widgets API which you can use to avoid it: http://trac.turbogears.org/turbogears/attachment/ticket/490/ newbase_widget_vars.2.patch The discussion is at: http://trac.turbogears.org/turbogears/ticket/490 Hope i helps, Alberto. On Feb 5, 2006, at 1:09 PM, Max Ischenko wrote: 1. I don't like been forced to write boilerplate code like this: def update_data(self, d): d['headers'] = self.headers d['collist'] = self.collist d['getcol'] = self.getcol -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: TypeError: dispatch_error() got multiple values for keyword argument 'tg_errors'
Hi Jorge, I've run into it too. Maybe you should file a ticket on this as i think it's a bug... I'm too busy trying to get all widgets to at least display so I haven't bothered yet to test the input (even forgot to report it). Regards, Alberto. On Feb 5, 2006, at 4:51 PM, Jorge Godoy wrote: Hi! After submitting a form I get the following TraceBack: == == Traceback (most recent call last): File /usr/lib/python2.4/site-packages/CherryPy-2.2.0beta- py2.4.egg/cherrypy/_cphttptools.py, line 99, in _run self.main() File /usr/lib/python2.4/site-packages/CherryPy-2.2.0beta- py2.4.egg/cherrypy/_cphttptools.py, line 247, in main body = page_handler(*virtual_path, **self.params) File string, line 3, in default File /home/godoy/desenvolvimento/python/TurboGears/trunk/ turbogears/controllers.py, line 218, in expose func, tg_format, html, fragment, *args, **kw) File /home/godoy/desenvolvimento/python/TurboGears/trunk/ turbogears/database.py, line 193, in run_with_transaction retval = func(*args, **kw) File /home/godoy/desenvolvimento/python/TurboGears/trunk/ turbogears/controllers.py, line 248, in _execute_func output = dispatch_error(func, self, *args, **kw) TypeError: dispatch_error() got multiple values for keyword argument 'tg_errors' == == In this page I have a DataGrid and a FormTable. I'm running == == Path: . URL: http://www.turbogears.org/svn/turbogears/trunk Repository UUID: 77541ad4-5f01-0410-9ede-a1b63cd9a898 Revision: 645 Node Kind: directory Schedule: normal Last Changed Author: kevin Last Changed Rev: 645 Last Changed Date: 2006-02-05 02:11:53 -0200 (Sun, 05 Feb 2006) Properties Last Updated: 2006-01-30 11:59:23 -0200 (Mon, 30 Jan 2006) == == Is there something I can do in my code to avoid that? -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: TypeError: dispatch_error() got multiple values for keyword argument 'tg_errors'
Yes, it's a bug. I have a fix ready, but to be on the safe side, would you mind posting signatures of caller and error handler. Thanks, Simon Alberto Valverde wrote: Hi Jorge, I've run into it too. Maybe you should file a ticket on this as i think it's a bug... I'm too busy trying to get all widgets to at least display so I haven't bothered yet to test the input (even forgot to report it). Regards, Alberto. On Feb 5, 2006, at 4:51 PM, Jorge Godoy wrote: Hi! After submitting a form I get the following TraceBack: Traceback (most recent call last): File /usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/_cphttptools.py, line 99, in _run self.main() File /usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/_cphttptools.py, line 247, in main body = page_handler(*virtual_path, **self.params) File string, line 3, in default File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/controllers.py, line 218, in expose func, tg_format, html, fragment, *args, **kw) File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/database.py, line 193, in run_with_transaction retval = func(*args, **kw) File /home/godoy/desenvolvimento/python/TurboGears/trunk/turbogears/controllers.py, line 248, in _execute_func output = dispatch_error(func, self, *args, **kw) TypeError: dispatch_error() got multiple values for keyword argument 'tg_errors' In this page I have a DataGrid and a FormTable. I'm running Path: . URL: http://www.turbogears.org/svn/turbogears/trunk Repository UUID: 77541ad4-5f01-0410-9ede-a1b63cd9a898 Revision: 645 Node Kind: directory Schedule: normal Last Changed Author: kevin Last Changed Rev: 645 Last Changed Date: 2006-02-05 02:11:53 -0200 (Sun, 05 Feb 2006) Properties Last Updated: 2006-01-30 11:59:23 -0200 (Mon, 30 Jan 2006) Is there something I can do in my code to avoid that? --Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: TypeError: dispatch_error() got multiple values for keyword argument 'tg_errors'
Alberto Valverde [EMAIL PROTECTED] writes: Hi Jorge, I've run into it too. Maybe you should file a ticket on this as i think it's a bug... I'm too busy trying to get all widgets to at least display so I haven't bothered yet to test the input (even forgot to report it). Regards, Alberto. It's ticket #516. I've tagged it as blocker, since it doesn't allow using widgets... (I haven't traced which widgets but I have textfields, checkboxes and calendars on this form table) -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: TypeError: dispatch_error() got multiple values for keyword argument 'tg_errors'
Simon Belak [EMAIL PROTECTED] writes: Yes, it's a bug. I have a fix ready, but to be on the safe side, would you mind posting signatures of caller and error handler. It is the same function I posted before with the identity.require and that you helped with the two selfs... -- Jorge Godoy [EMAIL PROTECTED]
[TurboGears] Re: Specifying list of objects for DataGrid
Hi, try http://trac.turbogears.org/turbogears/wiki/DataGridWidget and as the widget API is going through some surgery, be sure to let us know if you find anything broken ;) Alberto. On Feb 5, 2006, at 9:59 PM, Iain wrote: Hello, Quick DataGrid question for the list. I am attempting to embed a DataGrid widget in my edit page in order to allow the user to modify the properties of a related list of objects. From the code that I have seen on using a DataGrid widget in a non-fastdata environment, there appears to be a bit of magic involved in getting data to the widget. According to the (excellent) DataGridWidget page in the wiki, it is possible to provide DataGrid with a custom list of objects but I haven't been able to find an example. I've also tried using a DataController but since I would like to include other widgets on the same page this does not seem to be an option. Would someone be able to provide an example of how to specify the list of objects to a DataGrid or point me in the right direction? Any help would be greatly appreciated. Iain
[TurboGears] Re: Just want to say thanks for a great product!
That's great. Looking forward to seeing TG go gold soon! :-) Regards. --Arsalan
[TurboGears] Re: Using XMLRPC filter
reflog wrote: Hi there. I was wondering, since the _cpFilterList will be deprecated in future versions of CherryPy, can someone please provide a clear example on how to impement a XMLRPC handling controller that is mounted to the Root one? Somethis to make this work: class RPCController(controllers.Root): @turbogears.expose() def test(self, i): return i+1 class Root(controllers.Root): RPC = RPCController() I tried to do this and had no success. I concluded that I was better off just running SimpleXMLRPCServer in another process until TG supports @turbogears.expose(xmlrpc=True) or similar. -- Regards, Stephen Thorne Development Engineer Scanned by the NetBox from NetBox Blue (http://netboxblue.com/)
[TurboGears] Re: Cleaned up widget API
On 2/5/06, Kevin Dangoor [EMAIL PROTECTED] wrote: From the standpoint of widget authoring, just dropping widget into the namespace is appealing: it's the least amount of work possible. However, from the standpoint of widget *users*, there is an advantage to explicitly listing out the variables from the widget that should be available: *all* variables that the widget uses and defines in the constructor can also be overridden at display() time. For consistency's sake, it's nice to think that people wouldn't have to play a guessing game about whether they can override something. This is how I know TurboGears is in good hands. The widget author only has to write the code once. The widget user has to use the API again and again in every site. The more concise the better, provided it doesn't get cryptic. I don't understand the threading issues so I'm staying out of that. Reusing a widget instance has just never been an issue in Quixote. A widget instance is specific to a particular widget on the screen in one transaction. If two identical forms are on the page, they'd use different form instances with different widget instances. It's not smart enough to choose the correct form from the input, but you can do that manually by examining a hidden field or submit value and then telling the code which form object to use. Quixote is multiprocess rather than multithreaded so threading issues don't come up. But I still don't see why you'd want to share a widget instance between threads, which would imply it's being used on multiple forms, and thus must be thread safe. In Cheetah we purposely made Template instances not threadsafe because it's much more convenient to store state in the instance. And the overhead of instantiating extra instances is so small it doesn't matter. -- Mike Orr [EMAIL PROTECTED] ([EMAIL PROTECTED] address is semi-reliable)
[TurboGears] Re: svn 645 sitetemplate not found error coming up again
Fixed somehow in 646, with complete re-install
[TurboGears] Re: Found the source of Kid's TypeError: 'NoneType' object is not callable error
This error is still a showstopper for my site, even with SVN 646. David, if you'd like, I will give you the login for my dreamhost site, if it will help you track down the bug. Mike
[TurboGears] Re: Found the source of Kid's TypeError: 'NoneType' object is not callable error
Also, running a python setup.py develop in plugins/kid brings up the sitetemplate not found error: Traceback (most recent call last): File /home/.castor/mikez0r/lib/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/_cphttptools.py, line 99, in _run self.main() File /home/.castor/mikez0r/lib/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/cherrypy/_cphttptools.py, line 247, in main body = page_handler(*virtual_path, **self.params) File string, line 3, in index File /home/.castor/mikez0r/download/trunk/turbogears/controllers.py, line 218, in expose func, tg_format, html, fragment, *args, **kw) File /home/.castor/mikez0r/download/trunk/turbogears/database.py, line 193, in run_with_transaction retval = func(*args, **kw) File /home/.castor/mikez0r/download/trunk/turbogears/controllers.py, line 253, in _execute_func return _process_output(tg_format, output, html, fragment) File /home/.castor/mikez0r/download/trunk/turbogears/controllers.py, line 66, in _process_output fragment=fragment) File /home/.castor/mikez0r/download/trunk/turbogears/view.py, line 60, in render return engine.render(info, format, fragment, template) File /home/.castor/mikez0r/lib/lib/python2.4/site-packages/TurboKid-0.9.0-py2.4.egg/turbokid/kidsupport.py, line 88, in render tclass = self.load_template(template) File /home/.castor/mikez0r/lib/lib/python2.4/site-packages/TurboKid-0.9.0-py2.4.egg/turbokid/kidsupport.py, line 42, in load_template self.load_template(self.stname, True) File /home/.castor/mikez0r/lib/lib/python2.4/site-packages/TurboKid-0.9.0-py2.4.egg/turbokid/kidsupport.py, line 56, in load_template mod = kid.load_template(classname) File /home/.castor/mikez0r/lib/lib/python2.4/site-packages/kid-0.8-py2.4.egg/kid/__init__.py, line 108, in load_template raise Exception, Template not found: %s (in %s) % ( Exception: Template not found: turbogears.fastdata.templates.sitetemplate (in /home/.castor/mikez0r/elementarycatastrophe.com, /) I noticed that the kid version there is 0.8, so I ran python setup.py develop in thirdparty/kid That gives the same error, with the kid version changing to 0.9.
[TurboGears] Re: Using XMLRPC filter
Is that true? NO normal way of implementing this? That sounds very discouraging... :(
