date:20060507

[turbogears-commits] [1404] branches/1.0/turbogears/static: Widget browser now shows source code for widgets thanks to a great patch by Matt Good at #840

2006-05-07 Thread dangoor

Title: [1404] branches/1.0/turbogears/static: Widget browser now shows source code for widgets thanks to a great patch by Matt Good at #840








Revision 1404
Author alberto
Date 2006-05-07 15:43:04 -0500 (Sun, 07 May 2006)


Log Message
Widget browser now shows source code for widgets thanks to a great patch by Matt Good at #840

Modified Paths

branches/1.0/turbogears/toolbox/designer/modelDesigner.kid
branches/1.0/turbogears/toolbox/widgets.kid
branches/1.0/turbogears/widgets/base.py


Added Paths

branches/1.0/turbogears/static/sh/


Removed Paths

branches/1.0/turbogears/toolbox/designer/static/sh/




Diff

Copied: branches/1.0/turbogears/static/sh (from rev 1403, branches/1.0/turbogears/toolbox/designer/static/sh) ( => )

Modified: branches/1.0/turbogears/toolbox/designer/modelDesigner.kid
===
--- branches/1.0/turbogears/toolbox/designer/modelDesigner.kid	2006-05-07 18:38:56 UTC (rev 1403)
+++ branches/1.0/turbogears/toolbox/designer/modelDesigner.kid	2006-05-07 20:43:04 UTC (rev 1404)
@@ -14,7 +14,7 @@
 
 script type=text/_javascript_ src=""
 link type=text/css rel=stylesheet href="" /
-link type=text/css rel=stylesheet href="" /
+link type=text/css rel=stylesheet href="" /
 /head
 
 body
@@ -86,9 +86,9 @@
 /tr
 /table
 
-script type=text/_javascript_ src=""
-script type=text/_javascript_ src=""
-script type=text/_javascript_ src=""
+script type=text/_javascript_ src=""
+script type=text/_javascript_ src=""
+script type=text/_javascript_ src=""
 
 script type=text/_javascript_
 var dragsort = ToolMan.dragsort()


Modified: branches/1.0/turbogears/toolbox/widgets.kid (1403 => 1404)

--- branches/1.0/turbogears/toolbox/widgets.kid	2006-05-07 18:38:56 UTC (rev 1403)
+++ branches/1.0/turbogears/toolbox/widgets.kid	2006-05-07 20:43:04 UTC (rev 1404)
@@ -4,6 +4,7 @@
 head
 meta content=text/html; charset=UTF-8 http-equiv=content-type /
 link type=text/css rel=stylesheet href="" /
+link type=text/css rel=stylesheet href="" /
 link py:strip=1 py:for="" in widget_css${css.display()}/link
 link py:strip=1 py:for="" in widget_js_head${js.display()}/link
 titleTurboGears Widget Browser/title
@@ -44,6 +45,7 @@
 div class=sample py:if=widgetdesc.show_separately and not viewing_one
 pThis widget can only be a href="" name=widgetdesc.full_class_name.replace('.', '_'))}viewed separately/a/p
 /div
+textarea name=code class=py${widgetdesc.source}/textarea
 p class=description py:content=widgetdesc.description/p
 br /
 /div
@@ -51,5 +53,12 @@
 /center
 
 div py:strip=1 py:for="" in widget_js_bodybottom${js.display()}/div
+
+script type=text/_javascript_ src=""
+script type=text/_javascript_ src=""
+script type=text/_javascript_ src=""
+script type=text/_javascript_
+dp.SyntaxHighlighter.HighlightAll('code');
+/script
 /body
 /html


Modified: branches/1.0/turbogears/widgets/base.py (1403 => 1404)

--- branches/1.0/turbogears/widgets/base.py	2006-05-07 18:38:56 UTC (rev 1403)
+++ branches/1.0/turbogears/widgets/base.py	2006-05-07 20:43:04 UTC (rev 1404)
@@ -617,6 +617,11 @@
 return %s.%s % (cls.__module__, cls.__name__)
 full_class_name = property(_get_full_class_name)
 
+def _get_source(self):
+import inspect
+return inspect.getsource(self.__class__)
+source = property(_get_source)
+
 def retrieve_css(self):
 return self.for_widget.retrieve_css()
 





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups TurboGears Repository Commits group.  To post to this group, send email to turbogears-commits@googlegroups.com  To unsubscribe from this group, send email to [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/turbogears-commits  -~--~~~~--~~--~--~---

[turbogears-commits] [1406] branches/1.0: Add support for grouped options in a SelectionField widget, actually used by

2006-05-07 Thread dangoor

Title: [1406] branches/1.0: Add support for grouped options in a SelectionField widget, actually used by 








Revision 1406
Author michele
Date 2006-05-07 19:50:28 -0500 (Sun, 07 May 2006)


Log Message
Add support for grouped options in a SelectionField widget, actually used by 
SingleSelectField and MultipleSelectField.
Remove label and help_text from FormField's params, they can't be changed at
render/display time since they are usually accessed as attributes by a Form,
anyway we still provide them in the FormField's template as they can be useful
for some custom widgets.

Modified Paths

branches/1.0/CHANGELOG.txt
branches/1.0/turbogears/widgets/forms.py




Diff

Modified: branches/1.0/CHANGELOG.txt (1405 => 1406)

--- branches/1.0/CHANGELOG.txt	2006-05-07 20:45:28 UTC (rev 1405)
+++ branches/1.0/CHANGELOG.txt	2006-05-08 00:50:28 UTC (rev 1406)
@@ -27,6 +27,11 @@
   with `i18n.format.format_decimal` which needs to know the
   precision.)
 * tg-admin info shows which eggs require TurboGears
+* In widgets, SelectionField now supports grouped options, SingleSelectField
+  and MultipleSelectField widgets take advantage of this to provide an optgroup
+  tag. The format of a grouped options list is like the following:
+ 
+  options = [(None, [(1, a), (2, b)]), (Others, [(3, c), (4, d)])]
 
 *Changes*
 


Modified: branches/1.0/turbogears/widgets/forms.py (1405 => 1406)

--- branches/1.0/turbogears/widgets/forms.py	2006-05-07 20:45:28 UTC (rev 1405)
+++ branches/1.0/turbogears/widgets/forms.py	2006-05-08 00:50:28 UTC (rev 1406)
@@ -329,11 +329,11 @@
 #
 class FormField(InputWidget):
 _name = widget
-params = [field_class, label, css_classes, help_text]
-field_class = None
 label = None
-css_classes = None
 help_text = None
+params = [field_class, css_classes]
+field_class = None
+css_classes = []
 
 def _get_name(self):
 return self._name
@@ -360,9 +360,14 @@
 return build_name_from_path(self.path, '_', '_')
 field_id = property(_get_field_id)
 
-def __init__(self, *args, **kw):
-super(FormField, self).__init__(*args, **kw)
-self.field_class = self.__class__.__name__.lower()
+def __init__(self, name=None, label=None, help_text=None, **kw):
+super(FormField, self).__init__(name, **kw)
+if label:
+self.label = label
+if help_text:
+self.help_text = help_text
+if self.field_class is None:
+self.field_class = self.__class__.__name__.lower()
 
 def update_params(self, d):
 super(FormField, self).update_params(d)
@@ -370,6 +375,8 @@
 d[field_class] =  .join([d[field_class], requiredfield])
 if d[css_classes]:
 d[field_class] =  .join([d[field_class]] + d[css_classes])
+d[label] = self.label
+d[help_text] = self.help_text
 d[field_id] = self.field_id
 
 # A decorator that provides field_for functionality to the
@@ -693,9 +700,9 @@
 validator = None
 sample_option = self._get_sample_option()
 if sample_option is not None:
-if isinstance(sample_option[0], int):
+if isinstance(sample_option, int):
 validator = validators.Int()
-elif isinstance(sample_option[0], basestring):
+elif isinstance(sample_option, basestring):
 validator = validators.String()
 else:
 import warnings
@@ -705,18 +712,43 @@
 
 def _get_sample_option(self):
 if self.options:
-return self.options[0]
+if isinstance(self.options[0][1], list):
+sample = self.options[0][1][0]
+else:
+sample = self.options[0]
+return sample[0]
+else:
+return None
 
 def update_params(self, d):
 super(SelectionField, self).update_params(d)
-for i, option in enumerate(d[options]):
-if len(option) is 2:
-option_attrs = {}
-elif len(option) is 3:
-option_attrs = option[2]
-if self._is_option_selected(option[0], d['value']):
-option_attrs[self._selected_verb] = self._selected_verb
-d[options][i] = (option[0], option[1], option_attrs)
+grouped_options = []
+options = []
+for optgroup in d[options]:
+if isinstance(optgroup[1], list):
+group = True
+optlist = optgroup[1]
+else:
+group = False
+optlist = [optgroup]
+for i, option in enumerate(optlist):
+if len(option) is 2:
+option_attrs = {}
+elif len(option) is 3:
+option_attrs = option[2]
+if self._is_option_selected(option[0], d['value']):
+

[turbogears-commits] [1407] branches/1.0/turbogears/widgets: Change how a dict param is managed, now it's just replaced with a copy instead

2006-05-07 Thread dangoor

Title: [1407] branches/1.0/turbogears/widgets: Change how a dict param is managed, now it's just replaced with a copy instead








Revision 1407
Author michele
Date 2006-05-07 20:41:43 -0500 (Sun, 07 May 2006)


Log Message
Change how a dict param is managed, now it's just replaced with a copy instead
of updating the old one. Updating is usually useful for attrs like params, but
in this case you can just put the default values in the template and Kid will
take care of that, look at TableForm for an example.

Modified Paths

branches/1.0/turbogears/widgets/base.py
branches/1.0/turbogears/widgets/forms.py
branches/1.0/turbogears/widgets/tests/test_widgets.py




Diff

Modified: branches/1.0/turbogears/widgets/base.py (1406 => 1407)

--- branches/1.0/turbogears/widgets/base.py	2006-05-08 00:50:28 UTC (rev 1406)
+++ branches/1.0/turbogears/widgets/base.py	2006-05-08 01:41:43 UTC (rev 1407)
@@ -131,29 +131,28 @@
 (self.template_c, self.template) = load_kid_template(template)
 if default:
 self.default = default
-# make sure we don't alter mutable class attributes
+# logic for managing the params attribute
 for param in self.__class__.params:
-value = getattr(self.__class__, param, None)
-if isinstance(value, dict):
-setattr(self, param, value.copy())
-elif isinstance(value, list):
-setattr(self, param, value[:])
-for param in self.__class__.params:
 if param in params:
-# make sure we don't pass references 
-# to mutable class attributes
+# make sure we don't keep references to mutables
 value = params.pop(param)
 if isinstance(value, dict):
-new_dict = getattr(self, param, {})
-new_dict.update(value)
-setattr(self, param, new_dict)
+setattr(self, param, value.copy())
 elif isinstance(value, list):
 setattr(self, param, value[:])
 else:
 setattr(self, param, value)
-elif not hasattr(self, param):
-setattr(self, param, None)
-for unused in params.keys():
+else:
+if hasattr(self, param):
+# make sure we don't alter mutable class attributes
+value = getattr(self.__class__, param)
+if isinstance(value, dict):
+setattr(self, param, value.copy())
+elif isinstance(value, list):
+setattr(self, param, value[:])
+else:
+setattr(self, param, None)
+for unused in params.iterkeys():
 warnings.warn('keyword argument %s is unused at %r instance' % (
 unused, self.__class__.__name__))
 
@@ -212,25 +211,23 @@
 if not getattr(self, 'template_c', False):
 warnings.warn(Widget instance '%r' has no template defined % self)
 return None
-# use the class' params list as this list should be specified
-# when sublassing, not on construction time.
-for attr_name in self.__class__.params:
-if callable(params.get(attr_name)):
-params[attr_name] = params[attr_name]()
-attr = getattr(self, attr_name, None)
-if isinstance(attr, dict):
-# values in d take preference, update a copy of the dict bound
-# to self.
-new_dict = dict(attr)
-new_dict.update(params.get(attr_name, {}))
-params[attr_name] = new_dict
-# kw arguments passsed to display should be already in d,
-# only insert them if they're not there.
-elif not attr_name in params:
-if isinstance(attr, list):
-params[attr_name] = attr[:]
+# logic for managing the params attribute
+for param in self.__class__.params:
+if param in params:
+if callable(params[param]):
+params[param] = params[param]()
+else:
+# if the param hasn't been overridden (passed as a keyword
+# argument inside **params) put the corresponding instance
+# value inside params, also make sure we don't pass a 
+# reference to mutables
+param_value = getattr(self, param, None)
+if isinstance(param_value, dict):
+params[param] = param_value.copy()
+elif isinstance(param_value, list):
+params[param] = param_value[:]
 else:
-params[attr_name] = attr
+params[param] = param_value
 params[name] = self.name
 params[value] =

[turbogears-commits] [1408] branches/1.0/CHANGELOG.txt: Add a note in the ChangeLog regarding r1407.

2006-05-07 Thread dangoor

Title: [1408] branches/1.0/CHANGELOG.txt: Add a note in the ChangeLog regarding r1407.








Revision 1408
Author michele
Date 2006-05-07 20:54:56 -0500 (Sun, 07 May 2006)


Log Message
Add a note in the ChangeLog regarding r1407.

Modified Paths

branches/1.0/CHANGELOG.txt




Diff

Modified: branches/1.0/CHANGELOG.txt (1407 => 1408)

--- branches/1.0/CHANGELOG.txt	2006-05-08 01:41:43 UTC (rev 1407)
+++ branches/1.0/CHANGELOG.txt	2006-05-08 01:54:56 UTC (rev 1408)
@@ -18,6 +18,11 @@
   database.so_to_dict().
 * CompoundWidgets (specially Forms) should now *always* receive a dict as value.
   (see comments on fastdata above).
+* In widgets, if you were using a dictionary as a params be aware that now the
+  dictionary is not updated at construction or display/render time but simply
+  replaced with the new one. 
+  If you were using it to provide default attributes for your widget, take a 
+  look at how the TableForm does that.
 
 *Features*
 





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups TurboGears Repository Commits group.  To post to this group, send email to turbogears-commits@googlegroups.com  To unsubscribe from this group, send email to [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/turbogears-commits  -~--~~~~--~~--~--~---

[turbogears-commits] [1409] trunk: Merged 1405:1408 from 1.0 to trunk

2006-05-07 Thread dangoor

Title: [1409] trunk: Merged 1405:1408 from 1.0 to trunk








Revision 1409
Author michele
Date 2006-05-07 20:58:14 -0500 (Sun, 07 May 2006)


Log Message
Merged 1405:1408 from 1.0 to trunk

Modified Paths

trunk/CHANGELOG.txt
trunk/turbogears/widgets/base.py
trunk/turbogears/widgets/forms.py
trunk/turbogears/widgets/tests/test_widgets.py




Diff

Modified: trunk/CHANGELOG.txt (1408 => 1409)

--- trunk/CHANGELOG.txt	2006-05-08 01:54:56 UTC (rev 1408)
+++ trunk/CHANGELOG.txt	2006-05-08 01:58:14 UTC (rev 1409)
@@ -33,6 +33,11 @@
   database.so_to_dict().
 * CompoundWidgets (specially Forms) should now *always* receive a dict as value.
   (see comments on fastdata above).
+* In widgets, if you were using a dictionary as a params be aware that now the
+  dictionary is not updated at construction or display/render time but simply
+  replaced with the new one. 
+  If you were using it to provide default attributes for your widget, take a 
+  look at how the TableForm does that.
 
 *Features*
 
@@ -42,6 +47,11 @@
   with `i18n.format.format_decimal` which needs to know the
   precision.)
 * tg-admin info shows which eggs require TurboGears
+* In widgets, SelectionField now supports grouped options, SingleSelectField
+  and MultipleSelectField widgets take advantage of this to provide an optgroup
+  tag. The format of a grouped options list is like the following:
+ 
+  options = [(None, [(1, a), (2, b)]), (Others, [(3, c), (4, d)])]
 
 *Changes*
 


Modified: trunk/turbogears/widgets/base.py (1408 => 1409)

--- trunk/turbogears/widgets/base.py	2006-05-08 01:54:56 UTC (rev 1408)
+++ trunk/turbogears/widgets/base.py	2006-05-08 01:58:14 UTC (rev 1409)
@@ -131,29 +131,28 @@
 (self.template_c, self.template) = load_kid_template(template)
 if default:
 self.default = default
-# make sure we don't alter mutable class attributes
+# logic for managing the params attribute
 for param in self.__class__.params:
-value = getattr(self.__class__, param, None)
-if isinstance(value, dict):
-setattr(self, param, value.copy())
-elif isinstance(value, list):
-setattr(self, param, value[:])
-for param in self.__class__.params:
 if param in params:
-# make sure we don't pass references 
-# to mutable class attributes
+# make sure we don't keep references to mutables
 value = params.pop(param)
 if isinstance(value, dict):
-new_dict = getattr(self, param, {})
-new_dict.update(value)
-setattr(self, param, new_dict)
+setattr(self, param, value.copy())
 elif isinstance(value, list):
 setattr(self, param, value[:])
 else:
 setattr(self, param, value)
-elif not hasattr(self, param):
-setattr(self, param, None)
-for unused in params.keys():
+else:
+if hasattr(self, param):
+# make sure we don't alter mutable class attributes
+value = getattr(self.__class__, param)
+if isinstance(value, dict):
+setattr(self, param, value.copy())
+elif isinstance(value, list):
+setattr(self, param, value[:])
+else:
+setattr(self, param, None)
+for unused in params.iterkeys():
 warnings.warn('keyword argument %s is unused at %r instance' % (
 unused, self.__class__.__name__))
 
@@ -212,25 +211,23 @@
 if not getattr(self, 'template_c', False):
 warnings.warn(Widget instance '%r' has no template defined % self)
 return None
-# use the class' params list as this list should be specified
-# when sublassing, not on construction time.
-for attr_name in self.__class__.params:
-if callable(params.get(attr_name)):
-params[attr_name] = params[attr_name]()
-attr = getattr(self, attr_name, None)
-if isinstance(attr, dict):
-# values in d take preference, update a copy of the dict bound
-# to self.
-new_dict = dict(attr)
-new_dict.update(params.get(attr_name, {}))
-params[attr_name] = new_dict
-# kw arguments passsed to display should be already in d,
-# only insert them if they're not there.
-elif not attr_name in params:
-if isinstance(attr, list):
-params[attr_name] = attr[:]
+# logic for managing the params attribute
+for param in self.__class__.params:
+if param in params:
+if callable(params[param]):
+params[param] =

[turbogears-commits] [1410] branches/1.0/turbogears/widgets/base.py: Use the copy module to manage mutables inside params.

2006-05-07 Thread dangoor

Title: [1410] branches/1.0/turbogears/widgets/base.py: Use the copy module to manage mutables inside params.








Revision 1410
Author michele
Date 2006-05-07 21:16:38 -0500 (Sun, 07 May 2006)


Log Message
Use the copy module to manage mutables inside params.

Modified Paths

branches/1.0/turbogears/widgets/base.py




Diff

Modified: branches/1.0/turbogears/widgets/base.py (1409 => 1410)

--- branches/1.0/turbogears/widgets/base.py	2006-05-08 01:58:14 UTC (rev 1409)
+++ branches/1.0/turbogears/widgets/base.py	2006-05-08 02:16:38 UTC (rev 1410)
@@ -2,6 +2,7 @@
 import itertools
 import pkg_resources
 import warnings
+from copy import copy
 from turbogears import view, validators, startup, config
 from turbogears.util import Enum, setlike, to_unicode
 from turbogears.widgets.meta import MetaWidget, load_kid_template
@@ -136,20 +137,16 @@
 if param in params:
 # make sure we don't keep references to mutables
 value = params.pop(param)
-if isinstance(value, dict):
-setattr(self, param, value.copy())
-elif isinstance(value, list):
-setattr(self, param, value[:])
+if isinstance(value, dict) or isinstance(value, list):
+setattr(self, param, copy(value))
 else:
 setattr(self, param, value)
 else:
 if hasattr(self, param):
 # make sure we don't alter mutable class attributes
 value = getattr(self.__class__, param)
-if isinstance(value, dict):
-setattr(self, param, value.copy())
-elif isinstance(value, list):
-setattr(self, param, value[:])
+if isinstance(value, dict) or isinstance(value, list):
+setattr(self, param, copy(value))
 else:
 setattr(self, param, None)
 for unused in params.iterkeys():
@@ -222,10 +219,8 @@
 # value inside params, also make sure we don't pass a 
 # reference to mutables
 param_value = getattr(self, param, None)
-if isinstance(param_value, dict):
-params[param] = param_value.copy()
-elif isinstance(param_value, list):
-params[param] = param_value[:]
+if isinstance(param_value, dict) or isinstance(param_value, list):
+params[param] = copy(param_value)
 else:
 params[param] = param_value
 params[name] = self.name





--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups TurboGears Repository Commits group.  To post to this group, send email to turbogears-commits@googlegroups.com  To unsubscribe from this group, send email to [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/turbogears-commits  -~--~~~~--~~--~--~---

[tg-tickets] [TurboGears] #838: Traceback on identity login form submit: TypeError: argument 1 must be str, not unicode

2006-05-07 Thread TurboGears

#838: Traceback on identity login form submit: TypeError: argument 1 must be
str, not unicode
--+-
 Reporter:  fabian|   Owner:  anonymous
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:   
Component:  Identity  | Version:  0.9a5
 Severity:  normal|Keywords:   
--+-
 Hi,

 I tried to follow the IdentityManagement tutorial and get this traceback,
 when I try to login:

 {{{
 Traceback (most recent call last):
   File
 
/home/fabian/usr/lib/python2.4/CherryPy-2.2.1-py2.4.egg/cherrypy/_cphttptools.py,
 line 103, in _run
 applyFilters('before_main')
   File
 
/home/fabian/usr/lib/python2.4/CherryPy-2.2.1-py2.4.egg/cherrypy/filters/__init__.py,
 line 151, in applyFilters
 method()
   File /home/fabian/usr/lib/python2.4/TurboGears-0.9a5-
 py2.4.egg/turbogears/visit/api.py, line 154, in before_main
 plugin.record_request( visit )
   File /home/fabian/usr/lib/python2.4/TurboGears-0.9a5-
 py2.4.egg/turbogears/identity/visitor.py, line 162, in record_request
 identity= self.identity_from_request(visit.key)
   File /home/fabian/usr/lib/python2.4/TurboGears-0.9a5-
 py2.4.egg/turbogears/identity/visitor.py, line 86, in
 identity_from_request
 identity= source(visit_key)
   File /home/fabian/usr/lib/python2.4/TurboGears-0.9a5-
 py2.4.egg/turbogears/identity/visitor.py, line 143, in identity_from_form
 identity= self.provider.validate_identity( user_name, pw, visit_key )
   File /home/fabian/usr/lib/python2.4/TurboGears-0.9a5-
 py2.4.egg/turbogears/identity/soprovider.py, line 209, in
 validate_identity
 user= user_class.by_user_name( user_name )
   File string, line 1, in lambda
   File /home/fabian/usr/lib/python2.4/SQLObject-0.7.1dev_r1675-
 py2.4.egg/sqlobject/main.py, line 1266, in _SO_fetchAlternateID
 result, obj = cls._findAlternateID(name, dbName, value, connection)
   File /home/fabian/usr/lib/python2.4/SQLObject-0.7.1dev_r1675-
 py2.4.egg/sqlobject/main.py, line 1262, in _findAlternateID
 value), None
   File /home/fabian/usr/lib/python2.4/SQLObject-0.7.1dev_r1675-
 py2.4.egg/sqlobject/dbconnection.py, line 587, in _SO_selectOneAlt
 return self.queryOne(SELECT %s FROM %s WHERE %s = %s %
   File /home/fabian/usr/lib/python2.4/SQLObject-0.7.1dev_r1675-
 py2.4.egg/sqlobject/dbconnection.py, line 755, in queryOne
 return self._dbConnection._queryOne(self._connection, s)
   File /home/fabian/usr/lib/python2.4/SQLObject-0.7.1dev_r1675-
 py2.4.egg/sqlobject/dbconnection.py, line 341, in _queryOne
 self._executeRetry(conn, c, s)
   File /home/fabian/usr/lib/python2.4/SQLObject-0.7.1dev_r1675-
 py2.4.egg/sqlobject/dbconnection.py, line 297, in _executeRetry
 return cursor.execute(query)
 TypeError: argument 1 must be str, not unicode
 }}}

 I set component to Identity as it is where it appears. But from the
 traceback one could guess that sqlobject struggles with Unicode here.

-- 
Ticket URL: http://trac.turbogears.org/turbogears/ticket/838
TurboGears http://www.turbogears.org/
TurboGears front-to-back web development
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Tickets group.
To post to this group, send email to turbogears-tickets@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-tickets
-~--~~~~--~~--~--~---

[tg-tickets] Re: [TurboGears] #835: Installation (and Update) of RuleDispatch-0.5a0.dev-r2115 fails on Mac OS X 10.4.6

2006-05-07 Thread TurboGears

#835: Installation (and Update) of RuleDispatch-0.5a0.dev-r2115 fails on Mac OS 
X
10.4.6
--+-
 Reporter:  anonymous |Owner:  anonymous
 Type:  defect|   Status:  new  
 Priority:  normal|Milestone:  1.0b1
Component:  Installation  |  Version:  0.9a5
 Severity:  normal|   Resolution:   
 Keywords:|  
--+-
Comment (by anonymous):

 I just found another piece of information:

 There are two files:

  * RuleDispatch-0.5a0.dev-!r2115.tar.gz:
   This file contains the source code
  * RuleDispatch-0.5a0.dev_r2115-py2.4-macosx-10.4-ppc.egg:
   This file contains the binary

 It seems that only the first of these two files is downloaded ... since
 the binary file is in the second, it is never found ...
 (And I found the answer to question 1 ...)

-- 
Ticket URL: http://trac.turbogears.org/turbogears/ticket/835
TurboGears http://www.turbogears.org/
TurboGears front-to-back web development
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Tickets group.
To post to this group, send email to turbogears-tickets@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-tickets
-~--~~~~--~~--~--~---

[tg-tickets] Re: [TurboGears] #727: [PATCH] All widgets provided by TG should have a corresponding WidgetDescription

2006-05-07 Thread TurboGears

#727: [PATCH] All widgets provided by TG should have a corresponding
WidgetDescription
-+--
 Reporter:  michele  |Owner:  roger.demetrescu
 Type:  enhancement  |   Status:  assigned
 Priority:  normal   |Milestone:  0.9a6   
Component:  Widgets  |  Version:  0.9a4   
 Severity:  normal   |   Resolution:  
 Keywords:   |  
-+--
Changes (by kevin):

  * milestone:  = 0.9a6

-- 
Ticket URL: http://trac.turbogears.org/turbogears/ticket/727
TurboGears http://www.turbogears.org/
TurboGears front-to-back web development
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Tickets group.
To post to this group, send email to turbogears-tickets@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-tickets
-~--~~~~--~~--~--~---

[tg-tickets] Re: [TurboGears] #727: [PATCH] All widgets provided by TG should have a corresponding WidgetDescription

2006-05-07 Thread TurboGears

#727: [PATCH] All widgets provided by TG should have a corresponding
WidgetDescription
-+--
 Reporter:  michele  |Owner:  roger.demetrescu
 Type:  enhancement  |   Status:  closed  
 Priority:  normal   |Milestone:  0.9a6   
Component:  Widgets  |  Version:  0.9a4   
 Severity:  normal   |   Resolution:  fixed   
 Keywords:   |  
-+--
Changes (by kevin):

  * status:  assigned = closed
  * resolution:  = fixed

Comment:

 Committed in [1400]. Thanks!

-- 
Ticket URL: http://trac.turbogears.org/turbogears/ticket/727
TurboGears http://www.turbogears.org/
TurboGears front-to-back web development
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Tickets group.
To post to this group, send email to turbogears-tickets@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-tickets
-~--~~~~--~~--~--~---

[tg-tickets] Re: [TurboGears] #825: [PATCH] fix saprovider + finalize abstraction

2006-05-07 Thread TurboGears

#825: [PATCH] fix saprovider + finalize abstraction
+---
 Reporter:  [EMAIL PROTECTED]  |Owner:  anonymous
 Type:  defect  |   Status:  new  
 Priority:  normal  |Milestone:  1.0b1
Component:  TurboGears  |  Version:  0.9a5
 Severity:  normal  |   Resolution:   
 Keywords:  |  
+---
Comment (by [EMAIL PROTECTED]):

 a- _ is currently being used both in the PEP style word_seperation and as
 a semantic identifier for a join in visit_identity.   i don't care which
 one is more important to tg , but you can't use two conflicting naming
 conventions.  i'm just trying to clean it up -- some parts of code suggest
 use in one context, others in another.  if i look at a new db and i see a
 visit table, a identity table, and a visit_identity table, i'm going to
 assume that _ is being used to mark joins.  if i open up tg and see
 pep_style_variable_naming and then see visit_identity, i'm going to assume
 that visit_identity is not an associative table.  using both contexts is
 confusing.

 b- Removing classes because they are available in the model -- What about
 backwards compatibility?
 that was already decided in .9a5 to be irrelevant.  if you look at the
 SOprovider in trunk, you'll see that all the classes were already stripped
 out and forced into model.py necessitating an upgrade.  i migrated that
 change to SA.  also to note though, SO provider still has tg_permissions
 in there, which is also in model.py -- i think someone forgot to delete
 that.

 c- i used tbl _ _ as a prefix to show that the variable just held a
 table definition.  as the table was already prefixed with tg _, i
 thought it would be sloppy and misleading to prefix it tbl_tg_.  since
 the  class was named TG_Visit , i thought it would be even more confusing
 to name it tg_visit , so tbl__, which semantically says hey, its a
 table to the next person who looks at that code was an obvious choice.

 d- identity.on = False for static --This prevent people from direct
 linking to your static resources.
 no, it causes a database hit on every page for every resource.  have some
 gifs + css on your page?  there's a db query for each one.  i averaged 24
 database calls per page for identity alone.  Thats completely unnecessary.
 if you have static resources that you want to lock down, its 2 lines in
 app.config to lock it down to put it back in on a per-directory basis (
 some sort of image directory or otherwise ) .

 e- i didn't rename any classes. i just renamed some variables used to
 lookup classes

-- 
Ticket URL: http://trac.turbogears.org/turbogears/ticket/825
TurboGears http://www.turbogears.org/
TurboGears front-to-back web development
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Tickets group.
To post to this group, send email to turbogears-tickets@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-tickets
-~--~~~~--~~--~--~---

[tg-tickets] [TurboGears] #840: [PATCH] show source of Widget Browser examples

2006-05-07 Thread TurboGears

#840: [PATCH] show source of Widget Browser examples
--+-
 Reporter:  Matt Good [EMAIL PROTECTED]  |   Owner:  anonymous
 Type:  enhancement   |  Status:  new  
 Priority:  normal|   Milestone:   
Component:  Toolbox   | Version:  0.9a5
 Severity:  normal|Keywords:   
--+-
 To figure out how to use the examples in the Widget Browser you need to
 dig through the source for the associated `WidgetDescription`.  I've
 patched the Widget Browser to include the source for each
 `WidgetDescription` object below the example output.

 Along with the patch the source highlighting files need moved to the
 tg_static path:
 {{{
 svn mv turbogears/toolbox/designer/static/sh turbogears/static
 }}}

-- 
Ticket URL: http://trac.turbogears.org/turbogears/ticket/840
TurboGears http://www.turbogears.org/
TurboGears front-to-back web development
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Tickets group.
To post to this group, send email to turbogears-tickets@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-tickets
-~--~~~~--~~--~--~---

[tg-tickets] Re: [TurboGears] #840: [PATCH] show source of Widget Browser examples

2006-05-07 Thread TurboGears

#840: [PATCH] show source of Widget Browser examples
--+-
 Reporter:  Matt Good [EMAIL PROTECTED]  |Owner:  anonymous
 Type:  enhancement   |   Status:  closed   
 Priority:  normal|Milestone:   
Component:  Toolbox   |  Version:  0.9a5
 Severity:  normal|   Resolution:  fixed
 Keywords:|  
--+-
Changes (by alberto):

  * status:  new = closed
  * resolution:  = fixed

Comment:

 Great work! :)

 Comitted at [1404], thanks!

-- 
Ticket URL: http://trac.turbogears.org/turbogears/ticket/840
TurboGears http://www.turbogears.org/
TurboGears front-to-back web development
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Tickets group.
To post to this group, send email to turbogears-tickets@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-tickets
-~--~~~~--~~--~--~---

[tg-tickets] Re: [TurboGears] #727: [PATCH] All widgets provided by TG should have a corresponding WidgetDescription

2006-05-07 Thread TurboGears

#727: [PATCH] All widgets provided by TG should have a corresponding
WidgetDescription
-+--
 Reporter:  michele  |Owner:  roger.demetrescu
 Type:  enhancement  |   Status:  closed  
 Priority:  normal   |Milestone:  0.9a6   
Component:  Widgets  |  Version:  0.9a4   
 Severity:  normal   |   Resolution:  fixed   
 Keywords:   |  
-+--
Comment (by michele):

 GREAT WORK Roger. ;-)

-- 
Ticket URL: http://trac.turbogears.org/turbogears/ticket/727
TurboGears http://www.turbogears.org/
TurboGears front-to-back web development
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Tickets group.
To post to this group, send email to turbogears-tickets@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-tickets
-~--~~~~--~~--~--~---

[tg-tickets] Re: [TurboGears] #727: [PATCH] All widgets provided by TG should have a corresponding WidgetDescription

2006-05-07 Thread TurboGears

#727: [PATCH] All widgets provided by TG should have a corresponding
WidgetDescription
-+--
 Reporter:  michele  |Owner:  roger.demetrescu
 Type:  enhancement  |   Status:  closed  
 Priority:  normal   |Milestone:  0.9a6   
Component:  Widgets  |  Version:  0.9a4   
 Severity:  normal   |   Resolution:  fixed   
 Keywords:   |  
-+--
Comment (by roger.demetrescu):

 Thanks guys...

 I'll reopen this ticket as soon I prepare the Description for
 PaginateDataGrid...

 I'll be back !!   :)

 Cheers

 Roger

-- 
Ticket URL: http://trac.turbogears.org/turbogears/ticket/727
TurboGears http://www.turbogears.org/
TurboGears front-to-back web development
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Tickets group.
To post to this group, send email to turbogears-tickets@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-tickets
-~--~~~~--~~--~--~---

[tg-trunk] Retrieving data from function to decorators

2006-05-07 Thread Jorge Godoy



Hi.


I'd like to know if there's something I can do to pass data from inside my 
function to the decorator, more specifically pass a parameter that my code is 
expecting and passing it to the decorator.  Something like this:


@turbogears.expose()
@turbogears.error_handler(
turbogears.util.bind_args(segmento = kword['segmento_id'],
  tabela = kword['tabela_id'])(precos))
@turbogears.validate(form = formulario_precos_analises)
@identity.require(identity.conditions.in_any_group('latam_novo', 'admin'))
def save(self, **kword):
...


With this code I get a NameError exception saying that kword is not defined.  
If I try passing the names outside the dictionary I get the same error...  

Why this?  In this case, I want the page to go back to the same data it had 
when the form was submitted.  I am doing that, today, from inside the method 
and checking tg_errors, but I would really prefer using the decorator for 
that. 

Thanks for any tips, hints or it will never work messages ;-)

-- 
Jorge Godoy  [EMAIL PROTECTED]


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---

[tg-trunk] Re: Retrieving data from function to decorators

2006-05-07 Thread Simon Belak


Jorge Godoy wrote:
 
 Hi.
 
 
 I'd like to know if there's something I can do to pass data from inside my 
 function to the decorator, more specifically pass a parameter that my code is 
 expecting and passing it to the decorator.  Something like this:
 
 
 @turbogears.expose()
 @turbogears.error_handler(
 turbogears.util.bind_args(segmento = kword['segmento_id'],
   tabela = kword['tabela_id'])(precos))
 @turbogears.validate(form = formulario_precos_analises)
 @identity.require(identity.conditions.in_any_group('latam_novo', 'admin'))
 def save(self, **kword):
 ...
 
 
 With this code I get a NameError exception saying that kword is not 
 defined.  
 If I try passing the names outside the dictionary I get the same error...  
 
 Why this?  In this case, I want the page to go back to the same data it had 
 when the form was submitted.  I am doing that, today, from inside the method 
 and checking tg_errors, but I would really prefer using the decorator for 
 that. 
 
 Thanks for any tips, hints or it will never work messages ;-)

Considering the order of execution, in general you can't pass state from 
the function to the decorators at run-time.

Try using an intermediate function that extracts relevant data from 
kword or have the arguments for precos be named same as keys in kword 
and it should work automatically.

Cheers,
Simon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---

[tg-trunk] strange decoration behavior

2006-05-07 Thread Kevin Dangoor


Or, at least, it seems strange to me.

If I run nosetests on the whole suite, a create_request that calls this method:

[expose(turbogears.tests.simple)]
[expose(json, accept_format = text/javascript, as_format=json)]
def with_json_via_accept(self):
return dict(title=Foobar, mybool=False, someval=foo)

Gets called like this:
Calling function with_json_via_accept at 0x2560030 with *((function
with_json_via_accept at 0x255e9f0,
turbogears.tests.test_expose.ExposeRoot object at 0x2511c70)),
**({})

Interesting thing #1: this test doesn't fail when test_expose is run
by itself. I'm not sure at all why that would make a difference.

So, the problem that comes up, in case that cryptic log output doesn't
reveal it, is that the first argument passed is a different function
masquerading as the original one (note the ids), and the *second*
argument is the true self.

This is likely directed at Simon: my guess is that the problem here is
caused by having two decorators. Any idea why it works in one context
and not the other?

Kevin
--
Kevin Dangoor
TurboGears / Zesty News

email: [EMAIL PROTECTED]
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---

[tg-trunk] Re: strange decoration behavior

2006-05-07 Thread Simon Belak


Kevin Dangoor wrote:
 Or, at least, it seems strange to me.
 
 If I run nosetests on the whole suite, a create_request that calls this 
 method:
 
 [expose(turbogears.tests.simple)]
 [expose(json, accept_format = text/javascript, as_format=json)]
 def with_json_via_accept(self):
 return dict(title=Foobar, mybool=False, someval=foo)
 
 Gets called like this:
 Calling function with_json_via_accept at 0x2560030 with *((function
 with_json_via_accept at 0x255e9f0,
 turbogears.tests.test_expose.ExposeRoot object at 0x2511c70)),
 **({})
 
 Interesting thing #1: this test doesn't fail when test_expose is run
 by itself. I'm not sure at all why that would make a difference.

How it fails?

 
 So, the problem that comes up, in case that cryptic log output doesn't
 reveal it, is that the first argument passed is a different function
 masquerading as the original one (note the ids), and the *second*
 argument is the true self.

This is to be expected. By our convention decorators have the form:

def my_d(a):
   def entagle(func):
 def my_d(func, *args, **kw)

the inner my_d is what gets evoked on a call.

I like this naming convention because it allows us to see how decorators 
are getting called at run-time.


 This is likely directed at Simon: my guess is that the problem here is
 caused by having two decorators. Any idea why it works in one context
 and not the other?

It could be just something [new] expose() specific. Another possibility 
is a bug in decorator module which manifests only when the same 
decorator is applied multiple times. How the tests fails would be most 
helpful.


Cheers,
Simon


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---

[tg-trunk] Re: strange decoration behavior

2006-05-07 Thread Kevin Dangoor


On 5/7/06, Simon Belak [EMAIL PROTECTED] wrote:

 Kevin Dangoor wrote:
  Or, at least, it seems strange to me.
 
  If I run nosetests on the whole suite, a create_request that calls this 
  method:
 
  [expose(turbogears.tests.simple)]
  [expose(json, accept_format = text/javascript, as_format=json)]
  def with_json_via_accept(self):
  return dict(title=Foobar, mybool=False, someval=foo)
 
  Gets called like this:
  Calling function with_json_via_accept at 0x2560030 with *((function
  with_json_via_accept at 0x255e9f0,
  turbogears.tests.test_expose.ExposeRoot object at 0x2511c70)),
  **({})
 
  Interesting thing #1: this test doesn't fail when test_expose is run
  by itself. I'm not sure at all why that would make a difference.

 How it fails?

Picture that log output like this:

with_json_via_accept(function with_json_via_accept, ExposeRoot instance)

If you look at the method above, it only takes *1* argument... self
(which should be ExposeRoot). So, the exception that occurs is a
complaint about the method only taking 1 argument but getting 2.

Kevin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---

[tg-trunk] Making expose work the way I want

2006-05-07 Thread Kevin Dangoor


I really *want* to be able to do what Elvelind was originally suggesting:

@expose(path.to.some.template)
@expose(json)
def foo(...)

@expose(json)
def bar(...)


The bar case above works right now. The foo case does not (and I
recently made a change to explicitly throw an exception, rather than
just acting in unexpected ways -- specifically, the JSON one wins).

My thought for making this work is to defer the creation of the
generic function to the first request, just hanging on to the info
needed to build the rules as the decorators are called.

The *last* expose that is called as a default (which is the top most
decorator visually) is the one that is treated as the default. Any
other ones listed as a default will have the template engine name used
in place of as_format.

That would allow @expose(xmlrpc) to be added potentially as well...
It would be good if the template engines could specify the accept
headers that may be appropriate for their output.

Kevin

--
Kevin Dangoor
TurboGears / Zesty News

email: [EMAIL PROTECTED]
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---

[tg-trunk] Re: Making expose work the way I want

2006-05-07 Thread Simon Belak


Kevin Dangoor wrote:
 I really *want* to be able to do what Elvelind was originally suggesting:
 
 @expose(path.to.some.template)
 @expose(json)
 def foo(...)
 
 @expose(json)
 def bar(...)
 
 
 The bar case above works right now. The foo case does not (and I
 recently made a change to explicitly throw an exception, rather than
 just acting in unexpected ways -- specifically, the JSON one wins).
 
 My thought for making this work is to defer the creation of the
 generic function to the first request, just hanging on to the info
 needed to build the rules as the decorators are called.
 
 The *last* expose that is called as a default (which is the top most
 decorator visually) is the one that is treated as the default. Any
 other ones listed as a default will have the template engine name used
 in place of as_format.
 
 That would allow @expose(xmlrpc) to be added potentially as well...
 It would be good if the template engines could specify the accept
 headers that may be appropriate for their output.
 
 Kevin

Give me a ticket and I will give you code. ;)

I've been meaning to clean-up expose() anyway because this is getting 
unbearable.

Cheers,
Simon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---

[tg-trunk] Re: Making expose work the way I want

2006-05-07 Thread Kevin Dangoor


On 5/7/06, Simon Belak [EMAIL PROTECTED] wrote:
 Give me a ticket and I will give you code. ;)

Thanks for the offer, but I've done most of it already...

Kevin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---

[tg-trunk] Re: Small change to how params (a dict in particular) are managed

2006-05-07 Thread Michele Cella


Kevin Dangoor wrote:

 I think you (Michele) made the point a couple messages back, though,
 that default attrs can be handled directly in the template.

 input type=foo default=attrs go=here py:attrs=attrs/

 And then you can still pass in attrs at instantiation or display time
 to override, right? I think this makes good sense. attrs is then
 strictly for overrides.


Yep, in fact that's the point, updating is usually useful for attrs
like params, but you can achieve the exact same effect in this way
that's also more explicit. ;-)

I've commit this change (with a small cleanup of the code) at r1407.

  I think it would be better to wait because the change will most
  probably have some side effects (in TinyMCE, for example, I'm sure in
  other cases too...) which I think it's better for us to see and gauge
  in 1.0 branch before freezing them in a release. Just my opinion
  though, maybe it's better to release it and see how it affects in
  the wild :)

 Given that we're still in alpha mode, getting it out earlier is
 better. I can always release one more alpha if there's major havoc.
 I'd rather that the beta is not a shaky release.

Another good point, done. ;-)

At r1406 I've also added support for grouped options, ATM you get it
only for Single/MultipleSelectField, any markup idea for CheckBoxList
and RadioButtonList?

That's what I've done and then discarded:

ul
   divA Group/div
   li1/li
   li2/li
   divAnother Group/div
   li1/li
   li2/li
/ul

Ciao
Michele


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---

[TurboGears] Re: KID got error while process javascript operator

2006-05-07 Thread Robin Haswell



 Using comments to wrap something that you want to keep in the document 
 is a bad idea.  Sure, it might happen to work with Kid, but I still 
 wouldn't do it or recommend it.

That technique has been recommended for JS since day 1. It's the standard way 
of hiding JS from 
non-javascript-aware browser. You wrap it in a comment so if your user agent 
doesn't understand JS, 
it doesn't go printing it everywhere.

Not that you should be putting JS in your body/ though.

I'm fine with JS on-page when it only affects that page. Including it in a 
global JS file increases 
bandwidth. Including it in its own external file causes connection overhead (in 
HTTP/1.0)

 -bob

-Rob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Where to start the scheduler

2006-05-07 Thread Ronald Jaramillo


The new scheduler is surely a nice addition. Where is the recomended  
place to setup/start it?
The controllers Root __init__ method?
Is there any issue with it and autoreloading?
Cheers
Ronald


Ronald Jaramillo
mail: ronald AT checkandshare DOT com
blog: http://www.checkandshare.com/blog




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: SingleSelectField missing optgroup functionality

2006-05-07 Thread Robin Haswell



 Hi Matt,
 
 Thanks for pointing this out, your right indeed!
 I forgot that a dict doesn't preserve the order (sorry guys) (any news
 in the python world regarding this? I can't see how maintaining the
 order could ever hurt, while mixing it sometimes hurts, WidgetsList...
 :-().
 
 Your hybrid solution looks good but probably requires too much
 verbosity, for today I'm stopping here, let's see what other thinks, to
 recap:
 
 1) My solution n°1
 
 2) Matt solution
 
 vote please! ;-)
 
 Ciao
 Michele

Hey Michele, thanks for looking in to this. I was just about to cross Open 
ticket on optgroups on 
my todo list when I noticed that it seems a bit redundant now. Can I add my 
$0.02 on this?

Regarding SingleSelectField vs SingleSelectFieldWithOptgroups, I think this is 
unnecessary as the 
format of the parameter is going to make this rather obvious, and the two 
aren't necessarily exclusive.

I propose the solution of:

[
 (None, [Please choose an option]),
 ('Dynamic Languages',
 [(1, Python), (2, Ruby)]
 ),
 ('Others',
 [(3, Java), (4, C++)]
 ),
]

This gives us the advantage of allowing us to `zip` two lists - a list of 
optgroups and a list of 
options:

optgroups = [None, Dynamic Languages, Others]
options = [
 [Please choose an option],
 [(1, Python), (2, Ruby)],
 [(3, Java), (4, C++)]
]
select_options = zip(optgroups, options)

  print select_options
[(None, ['Please choose an option']), ('Dynamic Languages', [(1, 'Python'), (2, 
'Ruby')]), 
('Others', [(3, 'Java'), (4, 'C++')])]
 

I think my solution is more semantically accurate (and easier to generate the 
structure)3 than the 
equivalent dict option, however differentiating between what is supposed to be 
a regular single 
select field and what is supposed to have optgroups might be a bit messy:

for value, option in options:
 if type(option) is list:
 # optgroup code
 pass
 else:
 # just show an option/
 pass

However, this allows us to simplify our case of when we don't want an optgroup 
before some optgroups to:

[
 (None, Please choose an option), # The second value of this tuple is not 
a list
 ('Dynamic Languages',
 [(1, Python), (2, Ruby)]
 ),
 ('Others',
 [(3, Java), (4, C++)]
 ),
]

Of course, if detecting whether we want an optgroup or not is a bit messy, we 
could always have an 
OptGroup widget. I'm not a fan of this plan though as I think more class 
hoop-jumping is bad :-/

Cheers

-Rob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: KID got error while process javascript operator

2006-05-07 Thread lateef jackson

Couple points that seem to be bubbling up:1) Kid is XML so '' needs to be escaped amp;2) In general practice it is good to keep all your _javascript_ in a .js static file if they it can reduce network usage becuase the static content can be reused. Take care not to keep specific functions that only apply to a single or a couple pages out of the global _javascript_ file.
3) If you have some page specific code that is easiest to put on the page use ![CDATA[]]. Page variables that are initialized, small simple functions or dynamic _javascript_.
4) As always the use of !-- -- is advised for older browser compatability (ofcourse if your site is like mine, browsers that don't _javascript_ won't be able to use the site so no loss)In my limited experience some web pages I couldn't figure out any other way then to generate _javascript_ on the page. If this was a limitation of _javascript_, my knowledge or my time, it didn't really matter. 
I vote that this question go into the FAQ.On 5/7/06, Robin Haswell [EMAIL PROTECTED]
 wrote: Using comments to wrap something that you want to keep in the document
 is a bad idea.Sure, it might happen to work with Kid, but I still wouldn't do it or recommend it.That technique has been recommended for JS since day 1. It's the standard way of hiding JS from
non-_javascript_-aware browser. You wrap it in a comment so if your user agent doesn't understand JS,it doesn't go printing it everywhere.Not that you should be putting JS in your body/ though.I'm fine with JS on-page when it only affects that page. Including it in a global JS file increases
bandwidth. Including it in its own external file causes connection overhead (in HTTP/1.0) -bob-Rob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups TurboGears group.  To post to this group, send email to turbogears@googlegroups.com  To unsubscribe from this group, send email to [EMAIL PROTECTED]  For more options, visit this group at http://groups.google.com/group/turbogears  -~--~~~~--~~--~--~---

[TurboGears] Re: KID got error while process javascript operator

2006-05-07 Thread Robin Haswell


 In my limited experience some web pages I couldn't figure out any other 
 way then to generate javascript on the page. If this was a limitation of 
 javascript, my knowledge or my time, it didn't really matter.

In my fairly large experience of JavaScript, you only *really* need to generate 
JS when you need to 
include page-specific data structures in your JS. I don't believe there are any 
other cases where JS 
needs to be generated. The long-term solution to this is fetching your 
structures with XMLHTTP with 
window.onload, but I think for now embedded JSON is fine.

-Rob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Do you know ActiveRecord?

2006-05-07 Thread Kevin Dangoor


Hi,

I'm looking for someone that's fairly familiar with Rails'
ActiveRecord layer... if that someone is you, please send me a private
email.

Thanks,

Kevin

--
Kevin Dangoor
TurboGears / Zesty News

email: [EMAIL PROTECTED]
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: Where to start the scheduler

2006-05-07 Thread Kevin Dangoor


On 5/7/06, Ronald Jaramillo [EMAIL PROTECTED] wrote:

 The new scheduler is surely a nice addition. Where is the recomended
 place to setup/start it?

Set tg.scheduler = True in the [global] section of your config.

http://www.turbogears.org/preview/docs/scheduler.html

It will start up automaticallly when TG starts.

You can configure jobs wherever it makes the most sense for you to do
so. (You can even do it at the module level.)

One thing I just thought of: the scheduler is pretty much assuming a
multithreaded environment, rather than a multiprocess one.

 The controllers Root __init__ method?
 Is there any issue with it and autoreloading?

There shouldn't really be an issue with autoreloading. The scheduler
shouldn't start up in the master process, and it'll restart every
time a reload occurs.

Kevin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: KID got error while process javascript operator

2006-05-07 Thread Bob Ippolito



On May 7, 2006, at 6:07 AM, Robin Haswell wrote:



 Using comments to wrap something that you want to keep in the  
 document
 is a bad idea.  Sure, it might happen to work with Kid, but I still
 wouldn't do it or recommend it.

 That technique has been recommended for JS since day 1. It's the  
 standard way of hiding JS from
 non-javascript-aware browser. You wrap it in a comment so if your  
 user agent doesn't understand JS,
 it doesn't go printing it everywhere.

It's not standard practice for XML.  Standard practice for XML is to  
use CDATA.  Comments in XML are comments and shouldn't carry anything  
meaningful and shouldn't really be expected to survive some kind of  
document transform.

Either way, I highly doubt any browsers (or other HTML parsing  
software) still exist that have a problem ignoring script tags --  
they've been with us for *over ten years*.  Day 1 was a hell of a  
long time ago.

-bob


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: Where to start the scheduler

2006-05-07 Thread Jorge Godoy


Em Domingo 07 Maio 2006 13:42, Kevin Dangoor escreveu:

 There shouldn't really be an issue with autoreloading. The scheduler
 shouldn't start up in the master process, and it'll restart every
 time a reload occurs.

Are the scheduled events persisted somehow so that they are automatically 
re-added on each restart?

-- 
Jorge Godoy  [EMAIL PROTECTED]


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: Where to start the scheduler

2006-05-07 Thread Kevin Dangoor


On 5/7/06, Jorge Godoy [EMAIL PROTECTED] wrote:

 Em Domingo 07 Maio 2006 13:42, Kevin Dangoor escreveu:

  There shouldn't really be an issue with autoreloading. The scheduler
  shouldn't start up in the master process, and it'll restart every
  time a reload occurs.

 Are the scheduled events persisted somehow so that they are automatically
 re-added on each restart?

Nope.

Kevin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: Do you know ActiveRecord?

2006-05-07 Thread Robin Haswell


Plans are afoot! Sounds exciting. Come on, you can't post a message like that 
without letting slip 
some tantalising clues ;-) SO is dead, long live TurboRecord?

/nosey

-Rob

Kevin Dangoor wrote:
 Hi,
 
 I'm looking for someone that's fairly familiar with Rails'
 ActiveRecord layer... if that someone is you, please send me a private
 email.
 
 Thanks,
 
 Kevin
 
 --
 Kevin Dangoor
 TurboGears / Zesty News
 
 email: [EMAIL PROTECTED]
 company: http://www.BlazingThings.com
 blog: http://www.BlueSkyOnMars.com
 
  

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: Do you know ActiveRecord?

2006-05-07 Thread Kevin Dangoor


On 5/7/06, Robin Haswell [EMAIL PROTECTED] wrote:

 Plans are afoot! Sounds exciting. Come on, you can't post a message like that 
 without letting slip
 some tantalising clues ;-) SO is dead, long live TurboRecord?

Nah, nothing like that... Just switching over to Rails for my next app.

g

Seriously, though, as we approach TG 1.0 it's time to pump up the
marketing a bit.

Kevin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: Where to start the scheduler

2006-05-07 Thread Ronald Jaramillo


Thanks, that's great.
Btw. there is a typo on the right column in the preview docs,  Get  
invloved should probably be 'Get involved'. I couldn't find the  
culprit template in my working directory.
Cheers.
Ronald

On May 7, 2006, at 6:42 PM, Kevin Dangoor wrote:


 On 5/7/06, Ronald Jaramillo [EMAIL PROTECTED] wrote:

 The new scheduler is surely a nice addition. Where is the recomended
 place to setup/start it?

 Set tg.scheduler = True in the [global] section of your config.

 http://www.turbogears.org/preview/docs/scheduler.html

 It will start up automaticallly when TG starts.

 You can configure jobs wherever it makes the most sense for you to do
 so. (You can even do it at the module level.)

 One thing I just thought of: the scheduler is pretty much assuming a
 multithreaded environment, rather than a multiprocess one.

 The controllers Root __init__ method?
 Is there any issue with it and autoreloading?

 There shouldn't really be an issue with autoreloading. The scheduler
 shouldn't start up in the master process, and it'll restart every
 time a reload occurs.

 Kevin

 


Ronald Jaramillo
mail: ronald AT checkandshare DOT com
blog: http://www.checkandshare.com/blog




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: Where to start the scheduler

2006-05-07 Thread Kevin Dangoor


On 5/7/06, Ronald Jaramillo [EMAIL PROTECTED] wrote:

 Thanks, that's great.
 Btw. there is a typo on the right column in the preview docs,  Get
 invloved should probably be 'Get involved'. I couldn't find the
 culprit template in my working directory.

Good catch! Fixed.

Kevin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Exception reporting

2006-05-07 Thread Robin Haswell


Hey there

Does TG have any provisions for exception reporting (eg, E-mailing the 
developer), and if not, do 
you think this would be difficult to implement?

I'm coming up to BETA deployment soon and I'd like to have some notifications 
of errors :-)

Cheers

-Rob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: Exception reporting

2006-05-07 Thread Simon Belak


Robin Haswell wrote:
 Hey there
 
 Does TG have any provisions for exception reporting (eg, E-mailing the 
 developer), and if not, do 
 you think this would be difficult to implement?
 
 I'm coming up to BETA deployment soon and I'd like to have some notifications 
 of errors :-)

Built-in no, however it is pretty trivial to do so. You can either:

1) override method _cp_on_error in your Root controller

2) define a catch-all exception handler:

@dispatch_error.when(tg_exception is not None)
def notify(self, tg_source, tg_exception):
   return Holly exception Batman!

Cheers,
Simon

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: Exception reporting

2006-05-07 Thread Robin Haswell


 2) define a catch-all exception handler:
 
 @dispatch_error.when(tg_exception is not None)
 def notify(self, tg_source, tg_exception):
return Holly exception Batman!

Cheers, I think I'll go for this option, but it doesn't seem to work properly. 
Have I done something 
wrong?

[EMAIL PROTECTED]:~/obb$ ./start-obb.py
Traceback (most recent call last):
   File ./start-obb.py, line 26, in ?
 from obb.controllers import Root
   File /home/rob/obb/obb/controllers.py, line 33, in ?
 class Game(controllers.RootController):
   File /home/rob/obb/obb/controllers.py, line 350, in Game
 @turbogears.errorhandling.dispatch_error.when(tg_exception is not None)
   File 
/usr/local/lib/python2.4/site-packages/TurboGears-0.9a5-py2.4.egg/turbogears/genericfunctions.py,
 
line 20, in when
 return self._decorate(cond, primary%d % order)
   File build/bdist.linux-i686/egg/dispatch/functions.py, line 577, in 
_decorate
   File string, line 10, in parseRule
   File build/bdist.linux-i686/egg/dispatch/functions.py, line 440, in 
parseRule
   File build/bdist.linux-i686/egg/dispatch/functions.py, line 326, in parse
   File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 383, in 
parse_expr
   File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 378, in build
   File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 111, in 
comparison
   File build/bdist.linux-i686/egg/dispatch/predicates.py, line 576, in 
Compare
   File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 378, in build
   File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 10, in 
lambda
   File build/bdist.linux-i686/egg/dispatch/predicates.py, line 58, in Name
NameError: tg_exception

This the code I have:

def unhandled_exception(self, tg_source, tg_exception):
try:
# Spam me here
programmer_notified = True
pass
except:
programmer_notified = False
return dict(tg_template=.templates.unhandled_exception,
programmer_notified=programmer_notified)

Perhaps this is related to my broken .9a1-.9a5 project? I intend to fix it up 
soon, but I currently 
get these errors all over the bloody place (although never on startup, only on 
shutdown or page load):

2006-05-07 20:58:07,831 cherrypy.msg INFO HTTP: Serving HTTP on 
http://localhost:8080/
2006-05-07 20:58:11,723 cherrypy.msg INFO ENGINE: Ctrl-C hit: shutting down 
autoreloader
2006-05-07 20:58:11,763 cherrypy.msg INFO HTTP: HTTP Server shut down
2006-05-07 20:58:11,823 turbogears.visit INFO Visit Tracking shutting down
2006-05-07 20:58:11,864 turbogears.identity INFO Identity shutting down
2006-05-07 20:58:11,865 cherrypy.msg INFO ENGINE: CherryPy shut down
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
   File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
 func(*targs, **kargs)
   File /usr/lib/python2.4/logging/__init__.py, line 1332, in shutdown
 h.flush()
   File /usr/lib/python2.4/logging/__init__.py, line 718, in flush
 self.stream.flush()
AttributeError: 'str' object has no attribute 'flush'
Error in sys.exitfunc:
Traceback (most recent call last):
   File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
 func(*targs, **kargs)
   File /usr/lib/python2.4/logging/__init__.py, line 1332, in shutdown
 h.flush()
   File /usr/lib/python2.4/logging/__init__.py, line 718, in flush
 self.stream.flush()
AttributeError: 'str' object has no attribute 'flush'

I think it's related to having no logging directives or anything.

When I get this running I think a trac page is definitely in order.

 Cheers,
 Simon

Cheers

-Rob

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: Exception reporting

2006-05-07 Thread Simon Belak


Robin Haswell wrote:
 2) define a catch-all exception handler:

 @dispatch_error.when(tg_exception is not None)
 def notify(self, tg_source, tg_exception):
return Holly exception Batman!
 
 Cheers, I think I'll go for this option, but it doesn't seem to work 
 properly. Have I done something 
 wrong?
 
 [EMAIL PROTECTED]:~/obb$ ./start-obb.py
 Traceback (most recent call last):
File ./start-obb.py, line 26, in ?
  from obb.controllers import Root
File /home/rob/obb/obb/controllers.py, line 33, in ?
  class Game(controllers.RootController):
File /home/rob/obb/obb/controllers.py, line 350, in Game
  @turbogears.errorhandling.dispatch_error.when(tg_exception is not None)
File 
 /usr/local/lib/python2.4/site-packages/TurboGears-0.9a5-py2.4.egg/turbogears/genericfunctions.py,
  
 line 20, in when
  return self._decorate(cond, primary%d % order)
File build/bdist.linux-i686/egg/dispatch/functions.py, line 577, in 
 _decorate
File string, line 10, in parseRule
File build/bdist.linux-i686/egg/dispatch/functions.py, line 440, in 
 parseRule
File build/bdist.linux-i686/egg/dispatch/functions.py, line 326, in parse
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 383, in 
 parse_expr
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 378, in 
 build
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 111, in 
 comparison
File build/bdist.linux-i686/egg/dispatch/predicates.py, line 576, in 
 Compare
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 378, in 
 build
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 10, in 
 lambda
File build/bdist.linux-i686/egg/dispatch/predicates.py, line 58, in Name
 NameError: tg_exception

Sorry, I gave you the wrong name, in 0.9 (and 1.0) it's tg_exceptions 
(plural).

 
 Perhaps this is related to my broken .9a1-.9a5 project? I intend to fix it 
 up soon, but I currently 
 get these errors all over the bloody place (although never on startup, only 
 on shutdown or page load):
 
 2006-05-07 20:58:07,831 cherrypy.msg INFO HTTP: Serving HTTP on 
 http://localhost:8080/
 2006-05-07 20:58:11,723 cherrypy.msg INFO ENGINE: Ctrl-C hit: shutting down 
 autoreloader
 2006-05-07 20:58:11,763 cherrypy.msg INFO HTTP: HTTP Server shut down
 2006-05-07 20:58:11,823 turbogears.visit INFO Visit Tracking shutting down
 2006-05-07 20:58:11,864 turbogears.identity INFO Identity shutting down
 2006-05-07 20:58:11,865 cherrypy.msg INFO ENGINE: CherryPy shut down
 Error in atexit._run_exitfuncs:
 Traceback (most recent call last):
File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
  func(*targs, **kargs)
File /usr/lib/python2.4/logging/__init__.py, line 1332, in shutdown
  h.flush()
File /usr/lib/python2.4/logging/__init__.py, line 718, in flush
  self.stream.flush()
 AttributeError: 'str' object has no attribute 'flush'
 Error in sys.exitfunc:
 Traceback (most recent call last):
File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
  func(*targs, **kargs)
File /usr/lib/python2.4/logging/__init__.py, line 1332, in shutdown
  h.flush()
File /usr/lib/python2.4/logging/__init__.py, line 718, in flush
  self.stream.flush()
 AttributeError: 'str' object has no attribute 'flush'
 
 I think it's related to having no logging directives or anything.
 
 When I get this running I think a trac page is definitely in order.

This is probably due to changes in logging facilites [1].

Cheers,
Simon

[1] 
http://groups.google.com/group/turbogears-trunk/browse_thread/thread/501a6e4e5c952cfc/7049312e45cf4281

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: Exception reporting

2006-05-07 Thread Robin Haswell


Ah, thanks for the help. I put up a quick trac page at 
http://trac.turbogears.org/turbogears/wiki/ErrorReporting. There was one other 
bug in your code, the 
  controller method takes one more parameter: (self, tg_source, tg_errors, 
tg_exception)

Cheers

-Rob

Simon Belak wrote:
 Robin Haswell wrote:
 2) define a catch-all exception handler:

 @dispatch_error.when(tg_exception is not None)
 def notify(self, tg_source, tg_exception):
return Holly exception Batman!
 Cheers, I think I'll go for this option, but it doesn't seem to work 
 properly. Have I done something 
 wrong?

 [EMAIL PROTECTED]:~/obb$ ./start-obb.py
 Traceback (most recent call last):
File ./start-obb.py, line 26, in ?
  from obb.controllers import Root
File /home/rob/obb/obb/controllers.py, line 33, in ?
  class Game(controllers.RootController):
File /home/rob/obb/obb/controllers.py, line 350, in Game
  @turbogears.errorhandling.dispatch_error.when(tg_exception is not 
 None)
File 
 /usr/local/lib/python2.4/site-packages/TurboGears-0.9a5-py2.4.egg/turbogears/genericfunctions.py,
  
 line 20, in when
  return self._decorate(cond, primary%d % order)
File build/bdist.linux-i686/egg/dispatch/functions.py, line 577, in 
 _decorate
File string, line 10, in parseRule
File build/bdist.linux-i686/egg/dispatch/functions.py, line 440, in 
 parseRule
File build/bdist.linux-i686/egg/dispatch/functions.py, line 326, in 
 parse
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 383, in 
 parse_expr
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 378, in 
 build
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 111, in 
 comparison
File build/bdist.linux-i686/egg/dispatch/predicates.py, line 576, in 
 Compare
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 378, in 
 build
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 10, in 
 lambda
File build/bdist.linux-i686/egg/dispatch/predicates.py, line 58, in Name
 NameError: tg_exception
 
 Sorry, I gave you the wrong name, in 0.9 (and 1.0) it's tg_exceptions 
 (plural).
 
 Perhaps this is related to my broken .9a1-.9a5 project? I intend to fix it 
 up soon, but I currently 
 get these errors all over the bloody place (although never on startup, only 
 on shutdown or page load):

 2006-05-07 20:58:07,831 cherrypy.msg INFO HTTP: Serving HTTP on 
 http://localhost:8080/
 2006-05-07 20:58:11,723 cherrypy.msg INFO ENGINE: Ctrl-C hit: shutting 
 down autoreloader
 2006-05-07 20:58:11,763 cherrypy.msg INFO HTTP: HTTP Server shut down
 2006-05-07 20:58:11,823 turbogears.visit INFO Visit Tracking shutting down
 2006-05-07 20:58:11,864 turbogears.identity INFO Identity shutting down
 2006-05-07 20:58:11,865 cherrypy.msg INFO ENGINE: CherryPy shut down
 Error in atexit._run_exitfuncs:
 Traceback (most recent call last):
File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
  func(*targs, **kargs)
File /usr/lib/python2.4/logging/__init__.py, line 1332, in shutdown
  h.flush()
File /usr/lib/python2.4/logging/__init__.py, line 718, in flush
  self.stream.flush()
 AttributeError: 'str' object has no attribute 'flush'
 Error in sys.exitfunc:
 Traceback (most recent call last):
File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
  func(*targs, **kargs)
File /usr/lib/python2.4/logging/__init__.py, line 1332, in shutdown
  h.flush()
File /usr/lib/python2.4/logging/__init__.py, line 718, in flush
  self.stream.flush()
 AttributeError: 'str' object has no attribute 'flush'

 I think it's related to having no logging directives or anything.

 When I get this running I think a trac page is definitely in order.
 
 This is probably due to changes in logging facilites [1].
 
 Cheers,
 Simon
 
 [1] 
 http://groups.google.com/group/turbogears-trunk/browse_thread/thread/501a6e4e5c952cfc/7049312e45cf4281
 
  

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: Exception reporting

2006-05-07 Thread Simon Belak


Great, thanks!

Cheers,
Simon

P.S. let it be known, I always gladly trade buggy pseudo-code for nice 
docs like these. ;)


Robin Haswell wrote:
 Ah, thanks for the help. I put up a quick trac page at 
 http://trac.turbogears.org/turbogears/wiki/ErrorReporting. There was one 
 other bug in your code, the 
   controller method takes one more parameter: (self, tg_source, tg_errors, 
 tg_exception)
 
 Cheers
 
 -Rob
 
 Simon Belak wrote:
 Robin Haswell wrote:
 2) define a catch-all exception handler:

 @dispatch_error.when(tg_exception is not None)
 def notify(self, tg_source, tg_exception):
return Holly exception Batman!
 Cheers, I think I'll go for this option, but it doesn't seem to work 
 properly. Have I done something 
 wrong?

 [EMAIL PROTECTED]:~/obb$ ./start-obb.py
 Traceback (most recent call last):
File ./start-obb.py, line 26, in ?
  from obb.controllers import Root
File /home/rob/obb/obb/controllers.py, line 33, in ?
  class Game(controllers.RootController):
File /home/rob/obb/obb/controllers.py, line 350, in Game
  @turbogears.errorhandling.dispatch_error.when(tg_exception is not 
 None)
File 
 /usr/local/lib/python2.4/site-packages/TurboGears-0.9a5-py2.4.egg/turbogears/genericfunctions.py,
  
 line 20, in when
  return self._decorate(cond, primary%d % order)
File build/bdist.linux-i686/egg/dispatch/functions.py, line 577, in 
 _decorate
File string, line 10, in parseRule
File build/bdist.linux-i686/egg/dispatch/functions.py, line 440, in 
 parseRule
File build/bdist.linux-i686/egg/dispatch/functions.py, line 326, in 
 parse
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 383, in 
 parse_expr
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 378, in 
 build
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 111, in 
 comparison
File build/bdist.linux-i686/egg/dispatch/predicates.py, line 576, in 
 Compare
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 378, in 
 build
File build/bdist.linux-i686/egg/dispatch/ast_builder.py, line 10, in 
 lambda
File build/bdist.linux-i686/egg/dispatch/predicates.py, line 58, in 
 Name
 NameError: tg_exception
 Sorry, I gave you the wrong name, in 0.9 (and 1.0) it's tg_exceptions 
 (plural).

 Perhaps this is related to my broken .9a1-.9a5 project? I intend to fix it 
 up soon, but I currently 
 get these errors all over the bloody place (although never on startup, only 
 on shutdown or page load):

 2006-05-07 20:58:07,831 cherrypy.msg INFO HTTP: Serving HTTP on 
 http://localhost:8080/
 2006-05-07 20:58:11,723 cherrypy.msg INFO ENGINE: Ctrl-C hit: shutting 
 down autoreloader
 2006-05-07 20:58:11,763 cherrypy.msg INFO HTTP: HTTP Server shut down
 2006-05-07 20:58:11,823 turbogears.visit INFO Visit Tracking shutting down
 2006-05-07 20:58:11,864 turbogears.identity INFO Identity shutting down
 2006-05-07 20:58:11,865 cherrypy.msg INFO ENGINE: CherryPy shut down
 Error in atexit._run_exitfuncs:
 Traceback (most recent call last):
File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
  func(*targs, **kargs)
File /usr/lib/python2.4/logging/__init__.py, line 1332, in shutdown
  h.flush()
File /usr/lib/python2.4/logging/__init__.py, line 718, in flush
  self.stream.flush()
 AttributeError: 'str' object has no attribute 'flush'
 Error in sys.exitfunc:
 Traceback (most recent call last):
File /usr/lib/python2.4/atexit.py, line 24, in _run_exitfuncs
  func(*targs, **kargs)
File /usr/lib/python2.4/logging/__init__.py, line 1332, in shutdown
  h.flush()
File /usr/lib/python2.4/logging/__init__.py, line 718, in flush
  self.stream.flush()
 AttributeError: 'str' object has no attribute 'flush'

 I think it's related to having no logging directives or anything.

 When I get this running I think a trac page is definitely in order.
 This is probably due to changes in logging facilites [1].

 Cheers,
 Simon

 [1] 
 http://groups.google.com/group/turbogears-trunk/browse_thread/thread/501a6e4e5c952cfc/7049312e45cf4281

 
  
 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

[TurboGears] Re: SingleSelectField missing optgroup functionality

2006-05-07 Thread Michele Cella



Robin Haswell wrote:
  Hi Matt,
 
  Thanks for pointing this out, your right indeed!
  I forgot that a dict doesn't preserve the order (sorry guys) (any news
  in the python world regarding this? I can't see how maintaining the
  order could ever hurt, while mixing it sometimes hurts, WidgetsList...
  :-().
 
  Your hybrid solution looks good but probably requires too much
  verbosity, for today I'm stopping here, let's see what other thinks, to
  recap:
 
  1) My solution n°1
 
  2) Matt solution
 
  vote please! ;-)
 
  Ciao
  Michele

 Hey Michele, thanks for looking in to this. I was just about to cross Open 
 ticket on optgroups on
 my todo list when I noticed that it seems a bit redundant now. Can I add my 
 $0.02 on this?

 Regarding SingleSelectField vs SingleSelectFieldWithOptgroups, I think this 
 is unnecessary as the
 format of the parameter is going to make this rather obvious, and the two 
 aren't necessarily exclusive.

 I propose the solution of:

 [
  (None, [Please choose an option]),
  ('Dynamic Languages',
  [(1, Python), (2, Ruby)]
  ),
  ('Others',
  [(3, Java), (4, C++)]
  ),
 ]

 This gives us the advantage of allowing us to `zip` two lists - a list of 
 optgroups and a list of
 options:

 optgroups = [None, Dynamic Languages, Others]
 options = [
  [Please choose an option],
  [(1, Python), (2, Ruby)],
  [(3, Java), (4, C++)]
 ]
 select_options = zip(optgroups, options)

   print select_options
 [(None, ['Please choose an option']), ('Dynamic Languages', [(1, 'Python'), 
 (2, 'Ruby')]),
 ('Others', [(3, 'Java'), (4, 'C++')])]
  

 I think my solution is more semantically accurate (and easier to generate the 
 structure)3 than the
 equivalent dict option, however differentiating between what is supposed to 
 be a regular single
 select field and what is supposed to have optgroups might be a bit messy:

 for value, option in options:
  if type(option) is list:
  # optgroup code
  pass
  else:
  # just show an option/
  pass

 However, this allows us to simplify our case of when we don't want an 
 optgroup before some optgroups to:

 [
  (None, Please choose an option), # The second value of this tuple is 
 not a list
  ('Dynamic Languages',
  [(1, Python), (2, Ruby)]
  ),
  ('Others',
  [(3, Java), (4, C++)]
  ),
 ]

 Of course, if detecting whether we want an optgroup or not is a bit messy, we 
 could always have an
 OptGroup widget. I'm not a fan of this plan though as I think more class 
 hoop-jumping is bad :-/

 Cheers

 -Rob

Hi Robin,

Thanks for the feedback, incidentally this is the exact syntax I
ended-up to implement yesterday:

http://tinyurl.com/hpzbj

You will probably find this into 0.9a6 since I'm going to commit it...
;-)

Ciao
Michele


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---

45 matches

Mail list logo