[turbogears-ja:75] Re: さて、 自己紹介
皆様 はじめまして。 穗苅と申します。 自己紹介 Zope,Plone関係の開発をしています。 趣味でゲームプログラミングをしていて、その関係で Webゲームの制作に適したフレームワークを探している中 たまたまTurboGearsに出会いました。 やりたいこと = 仕事としても趣味としてもTurboGearsに興味を持っています。 現在、TurboGearsの勉強もかねて、社内で使うちょっとしたタスク管理システム のようなものを作っています。 CGIゲームのようなものも作ってみたいと思っています。 -- 穗苅実紀夫 --~--~-~--~~~---~--~~ これは、お客様が次の Google グループに申し込まれたことを確認するメッセー ジです。 Google Groups turbogears-ja group. To post to this group, send email to turbogears-ja@googlegroups.com このグループから退会するには、次へメールをお送りください。 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-ja -~--~~~~--~~--~--~---
[turbogears-ja:76] Re: Po stgreSQLとTGの安定性はどうなん でしょう?
おおたにです。 気になっていても時間がなくて放置していました。sqliteは割といい加減なので 気を付けないと他のDBにしたときに困りますね。 さて、Postgresでテーブルの作成に失敗することがあるという問題は、model.pyに soClasses = (table1, table2) のようにテーブルの作成順を指定する必要があるということですね。 調べてもらってありがとうございます。 因みに余談ですが、テーブルの作成順はtg-admin sql sqlで見る限りだとASCII ソートされているような印象があります。 Atsushi Shibata wrote: 柴田です。 やっばり気になったので，さらに調べてみました。 tg-admin sql createで，実際にテーブルを作っているのはSQLObjectのようで す。 http://svn.colorstudy.com/SQLObject/trunk/sqlobject/manager/command.py にあるコードで処理を行っています。ざっと見たところ， 1) モジュールを指定して，モジュールのファイル自体，あるいはその下の階層 をos.path.walkを使ってスキャン，Pythonのファイルを読み込む 2) soClassesというシーケンス(リスト，またはタプル)を探す。あったら，そこ にあるクラスを元にテーブルを作ろうとする 3) なかったら，モジュールをdirしてアトリビュートを総なめ，クラスを見つけ 出してテーブルを作成する 3)でクラスを見つけ出す場合，dirで帰ってくるのはハッシュのキーですので， 順番が不定になります。このため，リレーションが張ってあって依存関係のある テーブルの生成に失敗する場合があるようです。 soClassesというリスト(またはタプル)をmodelに定義すると，テーブル生成の順 番をコントロールできます。私の場合は，この方法で順番を指定したところ， tg-admin sql createで問題なくテーブルを作成できました。TG_Userなども， soClassesに指定することで作成してくれるようになりました。 MLの以下のスレッド(英文です)が参考になるかも知れません。 http://groups.google.com/group/turbogears/browse_thread/thread/8a06649c2e375e24/56191266e7cd6e8a ちょっと安心しました:-)。 取り急ぎ。。。 Atsushi Shibata (Webcore Corp.) [EMAIL PROTECTED] http://www.webcore.co.jp/ --~--~-~--~~~---~--~~ これは、お客様が次の Google グループに申し込まれたことを確認するメッセー ジです。 Google Groups turbogears-ja group. To post to this group, send email to turbogears-ja@googlegroups.com このグループから退会するには、次へメールをお送りください。 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-ja -~--~~~~--~~--~--~---
[tg-tickets] [TurboGears] #775: [PATH] quickstart templates is not valid html
#775: [PATH] quickstart templates is not valid html
+---
Reporter: Lazy| Owner: anonymous
Type: defect | Status: new
Priority: low | Milestone: 0.9a5
Component: TurboGears | Version: 0.9a4
Severity: minor |Keywords:
+---
Hello,
Login and main templates are missing type=text/css in stylesheet
definition.
Path follows
{{{
--- qstemplates/quickstart/+package+/templates/master.kid (revision
1210)
+++ qstemplates/quickstart/+package+/templates/master.kid (working
copy)
@@ -6,7 +6,7 @@
meta content=text/html; charset=UTF-8 http-equiv=content-type
py:replace=''/
title py:replace=''Your title goes here/title
meta py:replace=item[:]/
-style
+style type=text/css
#pageLogin
{
font-size: 10px;
--- qstemplates/quickstart/+package+/templates/login.kid(revision
1210)
+++ qstemplates/quickstart/+package+/templates/login.kid(working
copy)
@@ -8,7 +8,7 @@
meta content=text/html; charset=UTF-8
http-equiv=content-type py:replace=''/
titleLogin/title
-style
+style type=text/css
#loginBox
{
width: 30%;
}}}
--
Ticket URL: http://trac.turbogears.org/turbogears/ticket/775
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] #775: [PATH] quickstart templates is not valid html
#775: [PATH] quickstart templates is not valid html +--- Reporter: Lazy|Owner: anonymous Type: defect | Status: closed Priority: low |Milestone: 0.9a5 Component: TurboGears | Version: 0.9a4 Severity: minor | Resolution: duplicate Keywords: | +--- Changes (by Lazy): * status: new = closed * resolution: = duplicate Comment: Part of #768 -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/775 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] #724: Turn of automatic svn add behavior in quickstart
#724: Turn of automatic svn add behavior in quickstart +--- Reporter: kevin |Owner: anonymous Type: defect | Status: closed Priority: normal |Milestone: 0.9a5 Component: TurboGears | Version: 0.9a4 Severity: normal | Resolution: fixed Keywords: | +--- Changes (by alberto): * status: new = closed * resolution: = fixed Comment: I've bumped PasteScript to 0.5.1 in [1213]. However, I don't seem to find the switch you're talking about in create_distro.CreateDistroCommand. A svn_repository option seems to be there but it's not on by default (maybe this is the change form 0.5 to 0.5.1?) and not touched by quicstart. I've tried to reproduce the problem by tg-admin quickstarting an empry project inside a svn sandbox as the tickets described and nothing was automatically added to the repository. I guess it's safe to close the ticket. Please feel free to reopen if I've missed anything. Alberto P.S. Leaving the two tickets mentioned above open until someone reviews this in case I screwed up. :) -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/724 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] #776: Enhancements for CogBin
#776: Enhancements for CogBin -+-- Reporter: anonymous| Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: 1.0 Component: Docs | Version: 0.9a4 Severity: normal |Keywords: -+-- Here is a list of enhancements for CogBin: * A table of contents section should be added to the page to simplify navigation as the page grows larger. * Currently the project name and version columns are vertically centered and should be changed to align to the top to clean up the appearances of the tables. * Projects in each section should be sorted in alphabetical order. * A new column is needed for '''Supported TurboGears Versions'''. Not sure how this would be accomplished as this information is not available from the Cheese Shop. * Once '''Supported TurboGears Version''' is supported a filter on the top of the page should be added to show only the projects that are compatible for the version of TG the user is interested in. * For the Widgets section it would be nice if there was an image to make it easier for users to find Widgets of interest. Also, are there any links to the CogBin page outside of it's mention in the mailing list? I have not seen one so I assume most new users or those who don't search the list will not likely find the page. Maybe the links are there and I just have not come across them. -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/776 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] #777: Impossible to programatically set an AutoCompleteField default value
#777: Impossible to programatically set an AutoCompleteField default value
--+-
Reporter: godoy | Owner: anonymous
Type: defect| Status: new
Priority: high | Milestone: 0.9a5
Component: CherryPy | Version: 0.9a4
Severity: critical |Keywords:
--+-
Hi! With the following widget declaration I am not being able to set the
value of its text_field programatically:
{{{
endereco = widgets.AutoCompleteField(
search_controller=/clientes/search_endereco,
search_param=endereco,
result_name=enderecos,
text_field = widgets.TextField(name = 'endereco_text',
attrs = {'size':51},
label = _(u'Endereço'),
validator =
validators.UnicodeString(if_empty = None)),
)
}}}
I've tried attributing values to it using the following idioms:
* dict(endereco = value)
* dict(endereco_text = value)
* dict(text_field = value)
* dict(text = value)
* dict(widget = value)
* {'endereco.widget': value}
and some more combinations based on the generated HTML and the source
code. I can't precisely say when this started hapenning, but it was with
some of the latest changes.
Here I have:
{{{
% tg-admin info | sort
cElementTree 1.0.5-20051216
Cheetah 1.0
CherryPy 2.2.0
elementtree 1.2.6
elementtree 1.2.6
FormEncode 0.5.1
FormEncode 0.5.1
kid 0.9
nose 0.8.4
Paste 0.5
PasteDeploy 0.5
PasteScript 0.5
PyProtocols 1.0a0
RuleDispatch 0.5a0
setuptools 0.6a11
simplejson 1.3
SQLObject 0.7.1dev-r1707
TurboGears 0.9a5dev-r1207
TurboJson 0.9.2dev-r1204
TurboKid 0.9.4dev-r1123
}}}
This makes this kind of field unusable for editing data.
--
Ticket URL: http://trac.turbogears.org/turbogears/ticket/777
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] #777: Impossible to programatically set an AutoCompleteField default value
#777: Impossible to programatically set an AutoCompleteField default value
--+-
Reporter: godoy |Owner: anonymous
Type: defect| Status: new
Priority: high |Milestone: 0.9a5
Component: CherryPy | Version: 0.9a4
Severity: critical | Resolution:
Keywords:|
--+-
Changes (by godoy):
* component: Widgets = CherryPy
Comment:
In my controller I have this:
{{{
valores = dict(
# ...
endereco = dict(endereco_text = fornecedor.endereco),
# ...
)
return dict(
# ...
data = valores,
# ...
)
}}}
and in my Kid template I have:
{{{
span py:replace=formulario.display(value = data,
action='%s/update/' % root_link, method = 'post') /
}}}
So if you're asking about the nested dicts I believe I did, unless you
were asking about a third level -- mine only has two levels.
--
Ticket URL: http://trac.turbogears.org/turbogears/ticket/777
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] #777: Impossible to programatically set an AutoCompleteField default value
#777: Impossible to programatically set an AutoCompleteField default value --+- Reporter: godoy |Owner: anonymous Type: defect| Status: new Priority: high |Milestone: 0.9a5 Component: CherryPy | Version: 0.9a4 Severity: critical | Resolution: Keywords:| --+- Comment (by alberto): You're last example should be working... This is certainly a bug. -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/777 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] #777: Impossible to programatically set an AutoCompleteField default value
#777: Impossible to programatically set an AutoCompleteField default value
--+-
Reporter: godoy |Owner: anonymous
Type: defect| Status: new
Priority: high |Milestone: 0.9a5
Component: Widgets | Version: 0.9a4
Severity: critical | Resolution:
Keywords:|
--+-
Comment (by alberto):
{{
value = dict(endereco=dict(text=Something))
form.display(value=value)
}}}
--
Ticket URL: http://trac.turbogears.org/turbogears/ticket/777
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] #777: Impossible to programatically set an AutoCompleteField default value
#777: Impossible to programatically set an AutoCompleteField default value --+- Reporter: godoy |Owner: anonymous Type: defect| Status: new Priority: high |Milestone: 0.9a5 Component: Widgets | Version: 0.9a4 Severity: critical | Resolution: Keywords:| --+- Comment (by godoy): Nope, it didn't work. I even added a third level dictionary at my controller... I'll try reproducing it in a minimal application and I'll attach it here (if I don't find my mistake while doing that). -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/777 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] #778: [PATCH] Patch to make emailAddress and displayName optional in default soprovider
#778: [PATCH] Patch to make emailAddress and displayName optional in default soprovider ---+ Reporter: anonymous | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 0.9a5 Component: Identity | Version: 0.9a4 Severity: normal |Keywords: ---+ This patch makes the default soprovider more suitable for a wider range of uses by making the email address and display name optional. It does remove the alternateId status of emailAddress. Tim Lesher has rightly expressed some concern. ( http://tinyurl.com/rfwqu ) My thinking is that: 1. TG 1.0 will be used in internet apps, intranet apps, and apps in small mom and pop shops for which the term intranet would be overkill... as would be requiring an email address and (to a lesser extent) display name. The current tg_user enforces a decidedly Internet App flavor. 2. As Jorge Godoy pointed out on the Turbogears list, it's easier to add constraints than to remove them. 3. The TG 1.0 API will be fixed in stone and we will be living with it for a while. 4. The fields are useful to a large enough percentage of people that it makes sense to keep them for (optional) use than to remove them entirely. -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/778 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] #778: [PATCH] Patch to make emailAddress and displayName optional in default soprovider
#778: [PATCH] Patch to make emailAddress and displayName optional in default soprovider ---+ Reporter: anonymous |Owner: anonymous Type: defect | Status: new Priority: normal |Milestone: 0.9a5 Component: Identity | Version: 0.9a4 Severity: normal | Resolution: Keywords: | ---+ Comment (by [EMAIL PROTECTED]): The first patch is against 0.9a4. (Oops, selected the wrong file. Sorry.) The second ( ident_email_dispname_optional.patch ) is against the trunk. -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/778 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] #777: Impossible to programatically set an AutoCompleteField default value
#777: Impossible to programatically set an AutoCompleteField default value
--+-
Reporter: godoy |Owner: anonymous
Type: defect| Status: closed
Priority: high |Milestone: 0.9a5
Component: Widgets | Version: 0.9a4
Severity: critical | Resolution: worksforme
Keywords:|
--+-
Changes (by anonymous):
* status: new = closed
* resolution: = worksforme
Comment:
It's not a bug in AutoCompleteField but in you app. Try:
{{{
#!py
@turbogears.expose(html = 'ticket777.templates.clients')
def index(self):
values = dict(
endereco = dict(endereco_text = 'Default Value'),
)
}}}
In the Clients controller. You had 'addresses' instead of 'endereco' and
'text' instead of 'endereco_text'. A snippet form the form so you can
compare:
{{{
#!py
class widgets_clients_addresses(widgets.WidgetsList):
endereco = widgets.AutoCompleteField(
search_controller=/clients/search_address,
search_param=address,
result_name=addresses,
text_field = widgets.TextField(name = 'endereco_text',
attrs = {'size':51},
label = _(u'Endereço'),
validator =
validators.UnicodeString(if_empty = None)),
)
my_form_address = widgets.TableForm(fields = widgets_clients_addresses())
}}}
--
Ticket URL: http://trac.turbogears.org/turbogears/ticket/777
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] #777: Impossible to programatically set an AutoCompleteField default value
#777: Impossible to programatically set an AutoCompleteField default value --+- Reporter: godoy |Owner: anonymous Type: defect| Status: closed Priority: high |Milestone: 0.9a5 Component: Widgets | Version: 0.9a4 Severity: critical | Resolution: worksforme Keywords:| --+- Comment (by godoy): Silly me. Indeed it works and I haven't fully searched and replaced the text from my application to this test case. Sorry... So, it is some bug in my code that I need to find. Probably something as silly as this :-) Thanks for your time. -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/777 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] #778: [PATCH] Patch to make emailAddress and displayName optional in default soprovider
#778: [PATCH] Patch to make emailAddress and displayName optional in default soprovider ---+ Reporter: anonymous |Owner: anonymous Type: defect | Status: new Priority: normal |Milestone: 0.9a5 Component: Identity | Version: 0.9a4 Severity: normal | Resolution: Keywords: | ---+ Comment (by anonymous): Well, I really can't disagree with the idea of having tg_user defined in model.py, with username and password fields (and no others) being a requirement of the model. That would be heaven. Unfortunately, I'm not up to coding that and the fact is that we currently do have a default model with requirements that get in the way. It is much easier for the programmer to simply extend tg_user to add fields or constraints than it is to get around constraints that don't make sense for the particular app. Including some commonly used fields seems like a good idea to me. But *requiring* them is where they start to get in the way. Particularly when they are required to be unique. -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/778 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] #779: turbogears.util.DictObj improvement
#779: turbogears.util.DictObj improvement --+- Reporter: [EMAIL PROTECTED] |Owner: anonymous Type: enhancement | Status: new Priority: normal|Milestone: 0.9a5 Component: TurboGears| Version: 0.9a4 Severity: normal| Resolution: Keywords:| --+- Comment (by godoy): From discussions in the trunk mailing list I believe that this will be removed and Bunch will be the class that will be left. If somebody can confirm and close this bug as 'wontfix'/'invalid', I'd appreciate. -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/779 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] #780: patch attempt (non functional) at making identity more adaptable
#780: patch attempt (non functional) at making identity more adaptable +--- Reporter: [EMAIL PROTECTED] | Owner: anonymous Type: enhancement | Status: new Priority: normal | Milestone: Component: Identity| Version: 0.9a4 Severity: normal |Keywords: +--- The current Identity schema requires both a user_name and a user_email. I dislike that, because while on some projects I want users to have both, on many I want the user to have one or the other. Someone submitted a patch earlier that makes email not-required , which is great for their application, but doesn't work for mine - it still requires a unique user submitted id name. my attached patch doesn't work - I couldnt get things quite right, but it presents a different approach that hopefully someone else can take over or help me complete let me just elaborate on the idea a_ app.cfg the setting for identity.form.user_name is changed to 'account_identifier', which can either be 'user_name' or 'user_email' we add a 'identity.account_identifier' setting that can either be 'user_name' or 'user_email' . this represents the primary unique idfield. we add 'required.user_email' and 'required.user_name' boolean options - should these fields be required? b_ visitor.py references to user_name are replaced with account_identifier c_ so/sa providor essentially, _get_user_name becomes _get_account_identifier i tried to make things backwards compatible (perhaps too much) , so 'user_name' is still stored in some places (as is user_email'), but only in addition to account_identifier i upped user_name from 16 to 255 characters. user_email and display_name are both 255. I hope at least this idea is accepted - it would at least give people the chance to put an email address in user_name (although that would be really confusing) i wasn't sure if this would work or not, but if possible, i think we should set alternateId, alternateIdMethod in TG user based on the settings in app.cfg hopefully, an approach like this will accomplish the following: a- have no impact on people already using identity b- let people use user_name as the primary id (and omit user_email) c- let people use user_email as the primary id (and omit user_name) d- let people use both user_name and user_email -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/780 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] Re: Proposal: Events
Em Domingo 23 Abril 2006 09:49, Jeff Watkins escreveu: Well, my turn to confess: I haven't been following FirstClass at all. Me neither, but I believe this is a big change to go into 1.0 and this is why I asked. If it is not all that big, then I retreat my questioning :-) I'd envisioned the event mechanism to be a generic system for components to use to alert application code to certain actions. I like the idea that my application code could register to be alerted just before (or after) an HTTP request completes (just an example) or before a Visit is created. Sure! I also see some useful things with it. I was not questioning that just how and when would it be made available. :-) I still don't grasp WSGI and I should allocate some time to learn it as I envision that it would make a lot of things easier to me from what I've been reading, but... :-( -- 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: Proposal: Events
Yep. And you'd never understand *why* your login was rejected.On 23 Apr, 2006, at 1:57 pm, Simon Belak wrote:Were Identity based on generic functions (as was proposed using a very similar use case), one would get a very capable event system for free. ;) --Jeff Watkinshttp://newburyportion.com/"Just because you have the right to do something, doesn't mean it's the right thing to do."-- Fred Friendly, former president of CBS News --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears 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] Please flame me: I would like to move validator to InputWidget...
Ok, the subject is ironically talking about a flame since there is a bad hair ATM in the main mailing list but let's talk about things that matter. :D Fact: while reading Tim widgets introduction I noticed this thing (that I was sure to find at some point somewhere): You'll note that the template references value, which is the standard TurboGears name used to apply data to the widget. and in the template: tr py:for=player in value Now if I was the one to write such a widget I would never have used value but: params = [players] and: tr py:for=player in players So that's what I want to do: move the validator attribute to InputWidget along with: - default/value - adjust_value - value_for - convert - is_named - probably name? I never give a name to a non-form generic widget Reasons (very good IMHO): The base Widget class should be the most basic one and should present a general concept of component without making assumptions regarding the params that will be used (value is assumed in this case). The validator concept is pretty specific to Form validation and FormEncode, the value concept is also pretty specific to this thing I (for myself) will never use value in a non form widget and would like to encourage other people to not use it but use self explanatory names. What about from_python? Yes, I know a validator can be useful when you need to convert from_python to the web and don't need to_python, but if you need such a thing for a *non-form* widget *then* you will most probably need a custom FE validator and at this point I will not use a custom validator to just provide a from_python method but I will simply implement this logic inside update_data (that's what I'm doing with my generics widgets), otherwise you should explain to someone not only that value is *always* special treated but that he needs to implement a custom class like this one: class MyValidator(validators.FancyValidator): _from_python(self, value): ... and all the logic behind this class and FE concepts like FancyValidator instead of just putting some lines in update_data, why on hearth? and two ways of doing it? Other than that FormEncode as the name says is pretty much form oriented. Benefits: We have a nice, clean, slim and easy to use, explain and understand Widget base class that is *only* focused on the creation of reusable-components. TG show how you can use such a class to provide a very powerful form managing system, if you really want the validator you can use InputWidget directly. The base class becomes something like: class Widget(object): __metaclass__ = MetaWidget template = None params = [] css = [] javascript = [] def __init__(self, template=None, **params) def update_data(self, params) def display(self, **params) def render(self, format=html, **params) def retrieve_javascript() def retrieve_css() Just lovely IMHO (probably more with __javascript__ and __css__ :P:P). Ok, I know we shouldn't continue to touch things but I can't think of any backward incompatibility (please point them out if you can see them) and these functionalities are just shifted to InputWidget, that's where they really belong IMHO. Enough craziness for today? good night guys. 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Michele Cella wrote: class Widget(object): __metaclass__ = MetaWidget template = None params = [] css = [] javascript = [] def __init__(self, template=None, **params) def update_data(self, params) def display(self, **params) def render(self, format=html, **params) def retrieve_javascript() def retrieve_css() Just lovely IMHO (probably more with __javascript__ and __css__ :P:P). mmm while we are at it and since you will flame anyway, to be even more lovely I will also add that the ideal thing will be renaming update_data to update_params to enforce the strong relationship between the two things. Everything that's inside params ends up in the dict passed to update_data, so this should really be update_params, well Kevin named this method update_data before we introduced something like template_vars/params... 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Em Domingo 23 Abril 2006 21:22, Michele Cella escreveu: (...) The base Widget class should be the most basic one and should present a general concept of component without making assumptions regarding the params that will be used (value is assumed in this case). I don't believe we should try solving or enforcing good practices by making it harder for them to shoot themselves in their feet. We shouldn't change things just because of that. We have a nice, clean, slim and easy to use, explain and understand Widget base class that is *only* focused on the creation of reusable-components. This looks good to have... But it is achievable as of today. I've done that with Select-Shuttle and MochiInterpreter, both on CheeseShop... Ok, I know we shouldn't continue to touch things but I can't think of any backward incompatibility (please point them out if you can see them) and these functionalities are just shifted to InputWidget, that's where they really belong IMHO. Enough craziness for today? good night guys. If no test fails and nobody sees any trouble with that I have no objection. Besides, better doing that before 0.9a5 than later. But I really would like that this became more stable. If it is to make it easier, go for it. -- 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: Please flame me: I would like to move validator to InputWidget...
Em Domingo 23 Abril 2006 21:41, Michele Cella escreveu: mmm while we are at it and since you will flame anyway, to be even more lovely I will also add that the ideal thing will be renaming update_data to update_params to enforce the strong relationship between the two things. I have the same opinion. -- 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: Please flame me: I would like to move validator to InputWidget...
Em Domingo 23 Abril 2006 22:01, Michele Cella escreveu: - why should I name my grid? (mmm, to have more then one in the same page and distinguish them for javascript purpose, +1 for keeping name inside widget) ;-) We should always plan for more than one per page or per form. :-) It is safer and allows some unusual design. -- 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: Please flame me: I would like to move validator to InputWidget...
Jorge Godoy wrote: Em Domingo 23 Abril 2006 21:41, Michele Cella escreveu: mmm while we are at it and since you will flame anyway, to be even more lovely I will also add that the ideal thing will be renaming update_data to update_params to enforce the strong relationship between the two things. I have the same opinion. Mmm, but in a Compound update_data also receives member_widgets so it probably makes more a more generic name... But well, haven't I said that I should sleep? :D Good night, for real this time. 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 -~--~~~~--~~--~--~---
[tg-trunk] CompoundWidgets versus validators.Schema
Well... What should I validate in a compound widget such as the
AutoCompleteField? The syntax of a validator looks like:
name = validator
Where name is the parameter that is being returned from HTML. The problem is
that the name that is generated there is not tied to the name I provided.
Here's the HTML generated for the AutoCompleteField that I mentioned in #777:
===
DIV
SCRIPT TYPE=text/JavaScript LANGUAGE=JavaScript
AutoCompleteManagerform_endereco = new
AutoCompleteManager('form_endereco',
'form_endereco_endereco_text', 'form_endereco_hidden',
'/fornecedores/search_endereco', 'endereco', 'enderecos',false);
addLoadEvent(AutoCompleteManagerform_endereco.initialize);
/SCRIPT
INPUT NAME=endereco.endereco_text CLASS=textfield TYPE=text
ID=form_endereco_endereco_text VALUE=R. Poeta Francisco Ferreira Leite, 40
- 6 SIZE=51
IMG SRC2=/tg_widgets/turbogears.widgets/spinner.gif
SRC=/tg_widgets/turbogears.widgets/spinnerstopped.png
NAME=autoCompleteSpinnerendereco ID=autoCompleteSpinnerform_endereco
DIV CLASS=autoTextResults ID=autoCompleteResultsform_endereco
NAME=autoCompleteResultsendereco
/DIV
INPUT CLASS=hiddenfield TYPE=hidden ID=form_endereco_hidden
NAME=endereco.hidden
/DIV
===
I want to validate, e.g., the field that has the name endereco.endereco_text
-- the name I gave to the AutoCompleteField was endereco and the name for
the text_field was endereco_text. The code is:
===
endereco = widgets.AutoCompleteField(
search_controller=/fornecedores/search_endereco,
search_param=endereco,
result_name=enderecos,
text_field = widgets.TextField(name = 'endereco_text',
attrs = {'size':51},
label = _(u'Endereço'),))
===
The derived name is not obvious and one will always have to look at the output
to know the name of the field he'll be validating since it isn't anything he
typed in.
I'd expect to have to validate endereco_text or even just endereco since I
haven't specified a hidden field but have specified a text_field. But since
it is made of two separate widgets, I'd be fine validating the inner field.
What I want here? To write something like:
endereco.endereco_text = validators.UnicodeString()
But if I do that, then I'll receive an error message stating that there's no
'endereco' object or not 'endereco_text' attribute for the inexistent object.
Won't I? testing Yes, I get an error:
===
NameError: name 'endereco' is not defined
===
So, if the name there has a . in it, I can't create a Schema with that name
and this name is what is returned as the key in the key=value pair that we
receive from the web before any processing.
What should I write as the validator name to validate this field? And why are
validators for the form ignored when I declare them on the
widgets.WidgetsList and concatenate several of these into a form?
--
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
-~--~~~~--~~--~--~---
[TurboGears] Re: forms - question and a suggestion/critique
Michele Cella wrote: Ok, patch in svn and 1.0 branch, new package here: http://trac.turbogears.org/turbogears/attachment/wiki/SimpleWidgetForm/WeAreFlexible-0.9a5.tar.gz?format=raw You need svn or 0.9a5 when it comes out to use it, anyway I suggest you can already take a look to grasp the difference between this one that doesn't use a CompoundFormField. Thanks, I look forward to seeing it :-) I'm a release-only kind of guy. I know we are lacking doc, I'm trying to write some (but it's difficult for me since I'm not a native english speaker) anyway I hope you appreciated the fact that even if you haven't discovered them we are already providing these features, maybe now you can give us a better score card. ;-) I will :-) 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Is Identity too much? I think so.
On 22 Apr, 2006, at 3:54 pm, jvanasco wrote:The reason is that TurboGears is so Pythonic, probably too much so. Frankly, this is exactly why I've stopped following core development. There seems to be a current of thinking around generic functions and pythonic-magic that just confuses me. Everyone sounds off about how generic functions make things incredibly powerful and flexible, yet none of the adherents seem to recognise that it make the code absolutely impenetrable.I recently spent a half hour trying to understand the NEW expose operator before simply giving up. I'm loathe to speak ill of my fellow contributors (and I have no idea who's been working on this), but it simply wasn't important enough for me to understand it. I'd ALWAYS rather type a little more and understand what's going on than type less and hope the magic happens. Naturally, this has nothing to do with Identity, but it's been bothering me. --Jeff Watkinshttp://newburyportion.com/"Advertising directed at children is inherently deceptive and exploits children under eight years of age."-- American Academy of Pediatrics --~--~-~--~~~---~--~~ 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: large applications / tg-big
jvanasco wrote: After going insane trying to break up the default TG layout into something that can be mapped out into a directory tree for svn access and simultaneous development, I collected a bunch of newsgroup postings and applicaiton code and tossed it onto the Trac wiki so the next person doesn't go crazy: http://trac.turbogears.org/turbogears/wiki/LageApplication Did no-one notice this typo? I have CnP'd the contents to http://trac.turbogears.org/turbogears/wiki/LargeApplication and added a note on the original page. -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: Is Identity too much? I think so.
On 23 Apr, 2006, at 11:26 am, Alberto Valverde wrote:Also I should note that you don't *need* to undersand how they work in order to *use* them.On the other hand, if you need to understand the code that uses them, you'll NEVER actually know what the code does unless you understand EVERY instance of the generic function. It's impossible to look at the following code any actually know what it does:@generic()def flip_the_frobble(obj): pass...def clever_function(obj): flip_the_frobble(obj)What does clever_function actually do? It's impossible to tell, because you have no idea what versions of the generic flip_the_frobble have been created.When languages like C++ offer function overloading, they do it via type inspection. So you can very clearly understand whether the function will be invoked. However, generic functions have no such limitations. I've heard lots of arguments touting that generic functions increase the flexibility of code, and that's certainly true. However, no one has every cited an example that can only be achieved using generic functions. I've yet to hear an explanation similar to: "I've been looking for a way to flip my frobbles for ages, and thanks to generic functions, I now can!"No. I'm afraid I classify generic functions under "leads to bad software design". --Jeff Watkins[EMAIL PROTECTED]"We're growing the government at a pace that makes Democrats look thrifty."-- Senator Lindsey Graham, (R) South Carolina --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Identity Introspection
Either add it to func within (inner) require(), or to the result of decorator(): newfunc = decorator(require)(fn) newfunc._require = ... return newfunc Cheers, Simon Jeff Watkins wrote: Simon, I've been trying to add this feature and it doesn't seem to work correctly. The require decorator is presently defined as: def require(predicate, obj=None): ''' Function decorator that checks whether the current user is a member of the groups specified and has the permissions required. ''' def entangle(fn): def require(func, self, *args, **kwargs): try: errors= [] if predicate is None or \ predicate.eval_with_object(current, errors): return fn(self, *args, **kwargs) except IdentityException, e: errors= [str(e)] raise IdentityFailure(errors) return decorator(require)(fn) return entangle I've tried adding a _require attribute to entangle or the internal require, but in neither case is it visible as part of the decorated method. The magic seems to have failed. Any idea what I might be doing wrong? On 18 Feb, 2006, at 5:38 am, Simon Belak wrote: Jeff Watkins wrote: Wow. That's a really interesting idea. I could easily expose the permission predicate that the require decorator is using, however, I don't think that would work, because later decorators would hide that information. Anyone with deeper Python-fu who'd like to make a suggestion? Depends how you intend to expose it. It should work if you make it an attribute (as long as everyone is using well behaved decorators). We can of curse also tweak the decorator library if you have any special needs (preferably in a way useful to others as well). Cheers, Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Is Identity too much? I think so.
On 23/04/2006, at 17:44, Jeff Watkins wrote:On 23 Apr, 2006, at 11:26 am, Alberto Valverde wrote:Also I should note that you don't *need* to undersand how they work in order to *use* them.On the other hand, if you need to understand the code that uses them, you'll NEVER actually know what the code does unless you understand EVERY instance of the generic function. It's impossible to look at the following code any actually know what it does:@generic()def flip_the_frobble(obj): pass...def clever_function(obj): flip_the_frobble(obj)What does clever_function actually do? It's impossible to tell, because you have no idea what versions of the generic flip_the_frobble have been created.It's obvious to me from that example that "clever_function" will "flip_the_frobble" on "obj" ;) Now seriously (though that was a "half-joke", I mean, has some truth in it...). If the funtion is specialized properly, it should keep the semantics of the original function. To repeat the first "real-life" example of my previous post: "jsonify" should always return a JSON representation of it's argument, the only thing you don't see it's the actual implementation, which is a *good* point for me as that's all what encapsulation and abstraction is all about.If you need to follow the execution path taken you can use a debugger:In [8]: pdb.runcall(jsonify, 2) string(5)jsonify()(Pdb) s--Call-- /Users/alberto/build/bdist.darwin-8.4.0-Power_Macintosh/egg/dispatch/predicates.py(362)lambda()(Pdb) /Users/alberto/build/bdist.darwin-8.4.0-Power_Macintosh/egg/dispatch/predicates.py(362)lambda()(Pdb) --Return-- /Users/alberto/build/bdist.darwin-8.4.0-Power_Macintosh/egg/dispatch/predicates.py(362)lambda()-'__json__'(Pdb) --Call-- /Users/alberto/build/bdist.darwin-8.4.0-Power_Macintosh/egg/dispatch/predicates.py(491)dispatch_by_truth()(Pdb) /Users/alberto/build/bdist.darwin-8.4.0-Power_Macintosh/egg/dispatch/predicates.py(492)dispatch_by_truth()(Pdb) --Return-- /Users/alberto/build/bdist.darwin-8.4.0-Power_Macintosh/egg/dispatch/predicates.py(492)dispatch_by_truth()-[0, None, functio...x132b1f0, None](Pdb) --Call-- /sw/lib/python2.4/site-packages/TurboJson-0.9.1-py2.4.egg/turbojson/jsonify.py(20)jsonify_simple()- def jsonify_simple(obj):(Pdb) s /sw/lib/python2.4/site-packages/TurboJson-0.9.1-py2.4.egg/turbojson/jsonify.py(21)jsonify_simple()- return obj(Pdb) There you go, jsonify(2) actually is executed by jsonify_simple at line 21 of jsonify.py. Need anything more?I'm even sure you can inspect a function's AST dynamically but I have not yet found a way to do it... (Anyone got an idea? I'd really appreciate it... :)When languages like C++ offer function overloading, they do it via type inspection. So you can very clearly understand whether the function will be invoked. However, generic functions have no such limitations. This is more or less what dispatch.on does, type checking of a given argument. dispatch.generic is a superset of "on" which gives you even more power as you can go further than argument types and do checks on what those args *can* actually do: "does 'obj' have a 'display' method?"I've heard lots of arguments touting that generic functions increase the flexibility of code, and that's certainly true. However, no one has every cited an example that can only be achieved using generic functions. I've yet to hear an explanation similar to: "I've been looking for a way to flip my frobbles for ages, and thanks to generic functions, I now can!"Of course... but if I take this argument too seriously I can also affirm that there's nothing you cannot do in python/java/c++ that you cannot do in assembler, and way more efficiently. :)No. I'm afraid I classify generic functions under "leads to bad software design".Well, luckily for all think in different ways and have different approaches and biases to problems. And it'll be hell freezing boring :)Regards,Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Is Identity too much? I think so.
Non-generic function approach:
def do_something(obj):
if instance(obj, basestring):
do_something_with_string(obj)
if instance(obj, int):
do_something_with_int(obj)
else:
do_something_default(obj)
Generic-function approach:
@generic()
def do_something(obj):
Does something fancy with obj
@do_something.when(isinstance(obj, basestring))
def do_something_with_string(obj)
@do_something.when(isinstance(obj, int))
def do_something_with_int(obj)
@do_something.when(default)
def do_something_default(obj)
As you can see, the generic function approach makes you write even more.
So you triple the length of the code.
However, the biggest benefit, as I see it, is that these rules can be
defined anywhere (read: external modules), which basically aids in
manteinability because you don't need to touch the original module where the
function is defined when you need to tweak it's behavior. Oh, I should also
So with one call:
jsonify(someobj)
You have to look at code all over place to find out what it really
does? Because there can be some external module which due to the
coolness of generic functions are allowed to define additional rules.
mention that there's a much smarter algorithm than me taking care of
balancing the decision tree on the fly so it remains as efficient as
possible.
Premature optimization.
Also I should note that you don't *need* to undersand how they work in order
to *use* them. What can be easier to explain to users than: To get the JSON
representation of A do jsonify(A)? Of course, to actually define new rules
you have to study them a bit, but come on, I'm not that smart and I can make
use of them given my limited experience.
Yes and when something goes wrong you have to understand them. And
when someone asks But Alberto, what DOES jsonfiy(A) do? that is not
an easy question to answer.
You too make good use of this when you define rules in soprovider.py to
jsonify TG_User, etc. How would you have liked to hack on a long list of
I think it is bad use IMHO. The code is:
def jsonify_group(obj):
result = jsonify_sqlobject( obj )
result[users]= jsonify( [u.user_name for u in obj.users] )
result[permissions]= jsonify( [p.permission_name for p in
obj.permissions] )
return result
jsonify_group = jsonify.when('isinstance(obj, TG_Group)')(jsonify_group)
Why isn't it instead:
class TG_Group(InheritableSQLObject):
def __json__(self):
result = jsonify_sqlobject( obj )
result[users]= jsonify( [u.user_name for u in obj.users] )
result[permissions]= jsonify( [p.permission_name for p in
obj.permissions] )
return result
?
elifs inside an external egg (TurboJSON) making sure it's always up to
date, doesn't introduce dead branches and doesn't conflict with previous
With a normal simple if-elif dispatch, it wouldn't have to be an
external module. It would be 30 lines of Python code in a file named
jsonify.py. So yeah, I'd definitely prefer to hack in that file over
the complicated dispatch thingy.
rules? Not to mention that extenders of your identity classes can write
more specific rules, just below their subclasses, to jsonify them in a
different manner...
Why can't they just override __json__()?
The bottom line is that I'm not a good judge here, I'm now biased and
blinded by they're beauty, sorry but I cannot agree with you here... ;) The
importance generic functions are getting in TG is a plus for me...
Neither am I, but I still like to complain about them. :) They cause
me pain when I try to send utf8 encoded strings through JSON.
--
mvh Björn
--~--~-~--~~~---~--~~
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: Is Identity too much? I think so.
On 23/04/2006, at 18:13, BJörn Lindqvist wrote:
Non-generic function approach:
def do_something(obj):
if instance(obj, basestring):
do_something_with_string(obj)
if instance(obj, int):
do_something_with_int(obj)
else:
do_something_default(obj)
Generic-function approach:
@generic()
def do_something(obj):
Does something fancy with obj
@do_something.when(isinstance(obj, basestring))
def do_something_with_string(obj)
@do_something.when(isinstance(obj, int))
def do_something_with_int(obj)
@do_something.when(default)
def do_something_default(obj)
As you can see, the generic function approach makes you write even
more.
So you triple the length of the code.
Yep, for simple things the KISS maxim should be applied.
However, the biggest benefit, as I see it, is that these rules can be
defined anywhere (read: external modules), which basically aids in
manteinability because you don't need to touch the original module
where the
function is defined when you need to tweak it's behavior. Oh, I
should also
So with one call:
jsonify(someobj)
You have to look at code all over place to find out what it really
does? Because there can be some external module which due to the
coolness of generic functions are allowed to define additional rules.
Or use a debugger
mention that there's a much smarter algorithm than me taking care of
balancing the decision tree on the fly so it remains as efficient as
possible.
Premature optimization.
Ok, and when you have 1500 rules? Or when you wan to change the rules
for a different client's install?
Also I should note that you don't *need* to undersand how they
work in order
to *use* them. What can be easier to explain to users than: To
get the JSON
representation of A do jsonify(A)? Of course, to actually define
new rules
you have to study them a bit, but come on, I'm not that smart and
I can make
use of them given my limited experience.
Yes and when something goes wrong you have to understand them. And
when someone asks But Alberto, what DOES jsonfiy(A) do? that is not
an easy question to answer.
import pdb
You too make good use of this when you define rules in
soprovider.py to
jsonify TG_User, etc. How would you have liked to hack on a long
list of
I think it is bad use IMHO. The code is:
def jsonify_group(obj):
result = jsonify_sqlobject( obj )
result[users]= jsonify( [u.user_name for u in obj.users] )
result[permissions]= jsonify( [p.permission_name for p in
obj.permissions] )
return result
jsonify_group = jsonify.when('isinstance(obj, TG_Group)')
(jsonify_group)
Why isn't it instead:
class TG_Group(InheritableSQLObject):
def __json__(self):
result = jsonify_sqlobject( obj )
result[users]= jsonify( [u.user_name for u in obj.users] )
result[permissions]= jsonify( [p.permission_name for p in
obj.permissions] )
return result
Actually that example would work by grace of
jsonify.jsonify_explicit, flexibility...
Oh, and you might want to jsonify objects built from classes you
cannot directly modify, like from an C extension. Ok, ok.. you can
wrap that C extension's object and provide the __json__ method
yourself... but I *personally* would favor writing a new rule to
overload a generic function. A matter of taste I guess...
elifs inside an external egg (TurboJSON) making sure it's always
up to
date, doesn't introduce dead branches and doesn't conflict with
previous
With a normal simple if-elif dispatch, it wouldn't have to be an
external module. It would be 30 lines of Python code in a file named
jsonify.py. So yeah, I'd definitely prefer to hack in that file over
the complicated dispatch thingy.
Ok, now you want to distribute your project... with a hacked version
of dependency Y which obliges your users to have Y and Y' on their
systems with the most probably headaches they'll experience.
rules? Not to mention that extenders of your identity classes
can write
more specific rules, just below their subclasses, to jsonify them
in a
different manner...
Why can't they just override __json__()?
C extension example above.
The bottom line is that I'm not a good judge here, I'm now biased and
blinded by they're beauty, sorry but I cannot agree with you
here... ;) The
importance generic functions are getting in TG is a plus for me...
Neither am I, but I still like to complain about them. :) They cause
me pain when I try to send utf8 encoded strings through JSON.
No problem, I still like to defend them ;)
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
[TurboGears] Re: Is Identity too much? I think so.
Gosh, my english is s**t when i get excited... On 23/04/2006, at 18:12, Alberto Valverde wrote: Of course... but if I take this argument too seriously I can also affirm that there's nothing you cannot do in python/java/c++ that you cannot do in assembler, and way more efficiently. :) should read: nothing you can *do* in python... No. I'm afraid I classify generic functions under leads to bad software design. Well, luckily for all think in different ways and have different approaches and biases to problems. And it'll be hell freezing boring :) Should read: ...freezing boring *otherwise* Sorry, Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Is Identity too much? I think so.
Em Domingo 23 Abril 2006 13:12, Alberto Valverde escreveu: Of course... but if I take this argument too seriously I can also affirm that there's nothing you cannot do in python/java/c++ that you cannot do in assembler, and way more efficiently. :) joke It looks like somebody is obsessed with assembly... /joke -- 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: Is Identity too much? I think so.
On 23/04/2006, at 18:37, Jorge Godoy wrote: Em Domingo 23 Abril 2006 13:12, Alberto Valverde escreveu: Of course... but if I take this argument too seriously I can also affirm that there's nothing you cannot do in python/java/c++ that you cannot do in assembler, and way more efficiently. :) joke It looks like somebody is obsessed with assembly... /joke 5768 6f2c 206d 653f 3f0a ;) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Is Identity too much? I think so.
Em Domingo 23 Abril 2006 13:28, Alberto Valverde escreveu: Oh, and you might want to jsonify objects built from classes you cannot directly modify, like from an C extension. Ok, ok.. you can wrap that C extension's object and provide the __json__ method yourself... but I *personally* would favor writing a new rule to overload a generic function. A matter of taste I guess... Hmmm... I see two different approachs: one is OOP (__json__) making the objects know what to do; the other deals with generics. I also believe that we have to be very careful with what we use to solve our problems inside TG because that's what will be exposed to users. We should indeed opt for one alternative and doesn't make the other impossible, i.e., if the user thinks his problem can be best solved the other way, then this should be possible. Some clashes might happen on unexpected areas and they will happen but hey! We're working to get it better everyday, right? :-) We have the knife and the cheese... We just have to take care when we get to our hands. ;-) -- 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: Is Identity too much? I think so.
Em Domingo 23 Abril 2006 13:45, Alberto Valverde escreveu: 5768 6f2c 206d 653f 3f0a Do you own a PC or a Mac? ;-) /me runs! -- 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: Is Identity too much? I think so.
On 23/04/2006, at 18:56, Jorge Godoy wrote: Em Domingo 23 Abril 2006 13:45, Alberto Valverde escreveu: 5768 6f2c 206d 653f 3f0a Do you own a PC or a Mac? ;-) Oops, I'm sorry, should have mentioned that.. big-endian you're looking at. /me runs! /me too! :D Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Generic functions
Seeing a positive correspondence between people who disdain generic functions and people who do not know what exactly generic functions are, I decided to write a little primer in hopes FUD propagation will make way for an augmented discussion. --- Somewhat simplified, generic function is a set of functions bound to a single symbol. Where things get interesting is how a particular function* (let's call it specialisation) gets selected (dispatched). The process is usually deterministic, following a set of rules. Three predominant dispatch strategies are: 1) type dispatch (also called multiple dispatch and overloading) A function is selected depending on types of arguments passed. Examples: C, Py3k?, PyProtocols.dispatch.on 2) identity dispatch Usually used in conjunction with type dispatch A function is selected depending on concrete instances of arguments passed. Examples: CLOS 3) predicate dispatch A function is selected depending on arbitrary (logical) expressions. Examples: Cecil, Mathematica, PyProtocols.distpatch.generic The aforementioned rules usually also establishing a selection hierarchy (more specific is often the governing relation) to reduce ambiguity. While having more than one applicable specialisation may seem like a bad thing, it can actually be very useful. Enter function combination. Strictly speaking function combination is not a part of generic functions, therefore let's limit the scope to what PyProtocols (and CLOS) offer us. The simplest combination strategy is allowing the selected specialisation to call the next most specific specialisation. What makes function combination transcend generic functions are secondary functions. These allow us to define (generic) functions that get called automatically in relation to another function (called primary). Hence we can have secondary functions be called before, after or around (same as composition) a primary function. Some common misconceptions: 1) Generic functions are an alternative to normal (Java) OOP False. Message passing is nothing more than type dispatch on first (implicit) argument. 2) There is nothing I can't do without generic functions True, however considering lambda calculus (or Turing completeness) this can be said for most language constructs. References: http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html http://peak.telecommunity.com/DevCenter/CombiningResults http://en.wikipedia.org/wiki/Multiple_dispatch http://en.wikipedia.org/wiki/Generic_functions * term method is often used Cheers, Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Is Identity too much? I think so.
On 4/23/06, Steve Bergman [EMAIL PROTECTED] wrote: Jeff Watkins wrote: Frankly, I don't actually care what fields go in the User table, because I don't use the default TG version in any of my projects. If the feeling is that the tables have too much information, please feel free to either change them or submit a ticket/patch with changes. I take it, then, that no one would be too upset if I submit this patch to the trac? It will certainly cause problems for anyone who has every written user.byEmailAddress (including me), or allowed users to login in via email address (including me). At the very, very least, this had better be in the migration notes. -- Tim Lesher [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: Is Identity too much? I think so.
On Apr 23, 2006, at 8:44 AM, Jeff Watkins wrote:On 23 Apr, 2006, at 11:26 am, Alberto Valverde wrote:Also I should note that you don't *need* to undersand how they work in order to *use* them.On the other hand, if you need to understand the code that uses them, you'll NEVER actually know what the code does unless you understand EVERY instance of the generic function. It's impossible to look at the following code any actually know what it does:@generic()def flip_the_frobble(obj): pass...def clever_function(obj): flip_the_frobble(obj)What does clever_function actually do? It's impossible to tell, because you have no idea what versions of the generic flip_the_frobble have been created.When languages like C++ offer function overloading, they do it via type inspection. So you can very clearly understand whether the function will be invoked. However, generic functions have no such limitations. I've heard lots of arguments touting that generic functions increase the flexibility of code, and that's certainly true. However, no one has every cited an example that can only be achieved using generic functions. I've yet to hear an explanation similar to: "I've been looking for a way to flip my frobbles for ages, and thanks to generic functions, I now can!"Most generic function instances use a type or identity check as the predicate. Even with just plain type checking in languages like C++ you can get lost with deep hierarchies where a function matches a class exactly but also one or more of its superclasses.There ARE use cases that are best solved by generic functions (or a poor re-implementation of them):"I've been looking for a flexible way to have a library that can be extended by users, preferably without using adaptation, yet another type registry, or monkey-patching."There are of course no self-contained use cases that are best done with generic functions, but TG needs to offer extensibility to its users without them having to maintain their own fork.-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: Is Identity too much? I think so.
Em Domingo 23 Abril 2006 14:16, Alberto Valverde escreveu: I agree. At least in the jsonify case a jsonify_explicit function is added to operate on objects the have a __json__ method, therefore allowing both approaches: Add a rule to jsonify or provide a __json__ method in your objects. This is good design. :-) We should follow this in other parts of the code. Unfortunately, I cannot think of a way to offer this flexibility in other genericalized parts of TG like errorhandling.py or the new expose (which I admit not understanding yet how it actually works or what advantages it offers :/). Can't we adopt the same approach for these? How to do it is a bit beyond my abilities with generics right now, but I believe Simon can lend us a hand ;-) At least we have the possibility to access each implementation separately, doesn't we? So I can still write ifs in my code and call each one, can't I? :-) This would allow me to write the __json__ method and do the ifs myself... :-) On the other hand, error_handler() doesn't need generic function awareness in it's simplest and most common cases, only when doing something fancy which in that case you can provide an optional rule parameter. Make simple things simple and complex things possible. But then, this goes against the Zen of Python: There should be one-- and preferably only one --obvious way to do it.. So, I got stuck here :-) Mmm, cheese... ;) How was the race? :-) -- 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: Generic functions
On 4/23/06, Simon Belak [EMAIL PROTECTED] wrote: 1) type dispatch (also called multiple dispatch and overloading) A function is selected depending on types of arguments passed. Examples: C, Py3k?, PyProtocols.dispatch.on I think you meant to say C++, not C. In any evernt, your primer is rather lopsided. If your goal is really education rather than advocacy, you'd note the drawbacks of using generics. There are more than one, and if you really understand generics, then you can probably enumerate them. To me, the biggest drawback is their resistance to static analysis (the human kind!). True, Python already has features that make static analysis difficult, but there's no reason to make the problem worse if you don't have to. Generics can be very useful, but so far in TG I haven't seen a case in which the cure is better than the disease. -- Tim Lesher [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: Generic functions
On 23/04/2006, at 19:41, Simon Belak wrote: Seeing a positive correspondence between people who disdain generic functions and people who do not know what exactly generic functions are, I decided to write a little primer in hopes FUD propagation will make way for an augmented discussion. Thanks for giving us some formal background the topic for better understanding, nice to hear a sound voice on this :) The aforementioned rules usually also establishing a selection hierarchy (more specific is often the governing relation) to reduce ambiguity. As I've mentioned in the other (probably hijacked) thread. I would like to know if there is a way to inspect the current state of the rules hierarchy. To word it in another way: to see which rules are present in a function's decision tree. I'm mostly interested for debugging or maybe dynamically generating the rule I want to insert to avoid ambiguities. Some pointers to specific docs of RuleDispatch (couldn't find any) or in which part of the code I should start looking at will be much appreciated. Regards, Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Generic functions
Tim Lesher wrote: On 4/23/06, Simon Belak [EMAIL PROTECTED] wrote: 1) type dispatch (also called multiple dispatch and overloading) A function is selected depending on types of arguments passed. Examples: C, Py3k?, PyProtocols.dispatch.on I think you meant to say C++, not C. Yes, of course. In any evernt, your primer is rather lopsided. If your goal is really education rather than advocacy, you'd note the drawbacks of using generics. There are more than one, and if you really understand generics, then you can probably enumerate them. Yes, there are, but all are mostly implementation specific. To me, the biggest drawback is their resistance to static analysis (the human kind!). True, Python already has features that make static analysis difficult, but there's no reason to make the problem worse if you don't have to. I assume we are talking about border cases where function resolution order is not clear. Yes, it is harder, however why would you want to do static human analysis in a dynamic language? Fire up an interpreter prompt and experiment. Cheers, Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Generic functions
On 4/23/06, Simon Belak [EMAIL PROTECTED] wrote: Jeff Watkins wrote: Generics can be very useful, but so far in TG I haven't seen a case in which the cure is better than the disease. Generics != generic functions Ack. You're absolutely correct. I meant generic functions, not generics. Blame it on trying to reply while packing up to move, rather than a misconception, though. :-) -- Tim Lesher [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: Generic functions
Tim Lesher wrote: On 4/23/06, Simon Belak [EMAIL PROTECTED] wrote: I assume we are talking about border cases where function resolution order is not clear. That's one situation, but... Yes, it is harder, however why would you want to do static human analysis in a dynamic language? Fire up an interpreter prompt and experiment. The bigger problem is that in a interpreter, it's often difficult to duplicate the conditions that are prevalent during runtime of a large Python application. This is less a problem with the theory of generic functions (which is mathematically sound, of course), than with their implementation and use in Python. In my experience, interactive live development is a lot harder in Python environments that it is in Lisp or Smalltalk environments, simply because many Lisp and Smalltalk applications are _designed_ to be developed in this way: they are usually comprised of smaller functions, with less state and fewer side effects (pre-optimization, of course), and their standard libraries support that idiom very well. On the other hand, Python applications tend to be a mixture of C-style procedural libraries (mostly because of the C-runtime-flavored Python standard library), C++ and Java-style object-oriented classes, and a small slice of functional programming. That makes them harder to debug than either environments based on functional languages (where a live REPL is often sufficient for most,but not all, debugging) or C-like environments (where static analysis is often sufficient for most, but not all, debugging). This isn't an anti-Python rant (although it's starting to smell like one!). My opinion is that generic functions are harder to work with in Python than they are in the environments from whence they originated (due to the environment, not the functions themselves), and for that reason, they can't be used as lightly as they are in their native habitats. Can't argue with that, however as an avid (smug ;)) Lisper I would much rather TG moves towards a live environment (where it belongs) than to relinquish my toys, erm I mean powerful tools. Cheers, Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Generic functions
On 23/04/2006, at 21:34, Simon Belak wrote: As far as code goes, I would start either at dispatch.functions.parse or dispatch.interfaces.DispatchError. I think I've just found the answer with help(dispatch): TODO * Support DAG-walking for visualization, debugging, and ambiguity detection Thanks, Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: cannot import name config
Now my App runs on Port 8080 and Apache on Port 80 is a RewriteRule Proxy. The problem a raise HTTPRedirect leads to the Port 8080 Version. This works as long as this Port is open but how can i tell TurboGears/Cherrypy to use another host:port ? --~--~-~--~~~---~--~~ 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: cannot import name config
Em Domingo 23 Abril 2006 19:26, beza1e1 escreveu: Now my App runs on Port 8080 and Apache on Port 80 is a RewriteRule Proxy. The problem a raise HTTPRedirect leads to the Port 8080 Version. This works as long as this Port is open but how can i tell TurboGears/Cherrypy to use another host:port ? Take a look at the wiki. And use turbogears.redirect() instead of cherrypy.HTTPRedirect(turbogears.url()) ;-) I recommend using mod_proxy instead of mod_rewrite since it is much easier to setup. -- 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: forms - question and a suggestion/critique
Robin Haswell wrote:
Michele Cella wrote:
Ok, patch in svn and 1.0 branch, new package here:
http://trac.turbogears.org/turbogears/attachment/wiki/SimpleWidgetForm/WeAreFlexible-0.9a5.tar.gz?format=raw
Cheers, I read through this package and it looks pretty good to me :-) I'll
give it a try as soon a
.9a5 is released and will let you know what I think.
-Rob
Great to know!
Actually the features I've used are there since the first alpha release
of 0.9 (before there was just field_for but in 0.9a3 IIRC I enchained
it to be display/render_field_for since we added new features that
required more control and people were using it in the wrong way),
anyway the first I've made the first version at 4AM so I missed that
you can already do the same thing even on 0.9a4 it's just 7 lines of
code to add, I've updated the package:
http://trac.turbogears.org/turbogears/attachment/wiki/SimpleWidgetForm/WeAreFlexible.tar.gz
You can *already* use it if you want to, no need to wait for 0.9a5,
when the latter is out you can safely remove these things from
controllers.py:
from cherrypy import request (if you don't use it for other things)
from turbogears.widgets.forms import retrieve_value_by_path
and from StandardTextField:
def update_data(self, d):
super(StandardTextField, self).update_data(d)
errors = getattr(request, validation_errors, {})
d[error] = retrieve_value_by_path(errors, self.name_path)
d[label] = self.label
since in 0.9a5 they will be there by default:
http://trac.turbogears.org/turbogears/changeset/1208
Thanks.
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
-~--~~~~--~~--~--~---
[TurboGears] Re: forms - question and a suggestion/critique
jvanasco wrote: Thats pretty much my sentiment too - unlike Robin though, I generally don't like to use autogenerated html for fields - just leave that up to the designer, and have them pull info from a dict. In TAL, its something like this: === div class=f_error tal:condition=Errors/email tal:content=Errors/email/ input type=text name=email value= tal:attributes=value Defaults/_text/email/ Please Note: We will send a confirmation email to this address your provide, and you must click on a unique confirmation link in that email it to complete your registration. === Automagic generation saves time usually, but if there's some crazy complex layout - i leave it to the css/html people to handle the form placement. I'm looking forward to the .9a5 branch. The widgets seem great for validation and , at times , for generation - but sometimes simplifying things like that just makes it complicated to do a complex html form. I'm glad to know that what I didn't like about TG's approach to forms can be ignored in .9a5 Actually (as I said on my last reply to Robin that I encourage you to look at) there is nothing new in 0.9a5 regarding widgets, just bug fixing and the rename of template_vars to params. Hence you can already ignore what you're talking about if you're using 0.9a4. 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Is Identity too much? I think so.
I'm agains that, we will never reach a good for all default model. I think that the fact the default one is big means it will encourage most people to think of good/better/big ways to use it. (I'm refering to new web-developers) If we ever change it there should be diferent set of pre-define providers and have one as default.Or just don't define one at all and make it as simple as one class you define in your model, and make it as open as possible. On 4/23/06, Steve Bergman [EMAIL PROTECTED] wrote: Jeff Watkins wrote: Frankly, I don't actually care what fields go in the User table, because I don't use the default TG version in any of my projects. If the feeling is that the tables have too much information, please feel free to either change them or submit a ticket/patch with changes.I take it, then, that no one would be too upset if I submit this patchto the trac?--- soprovider.py.orig2006-04-22 16:49:22.0 -0500+++ soprovider.py 2006-04-22 16:50:42.0 -0500@@ -277,8 +277,8 @@ table=tg_user userId= UnicodeCol( length=16, alternateID=True )-emailAddress= UnicodeCol( length=255, alternateID=True ) -displayName= UnicodeCol( length=255 )+emailAddress= UnicodeCol( length=255, default=None )+displayName= UnicodeCol( length=255, default=None) password= UnicodeCol( length=40 ) created= DateTimeCol( default= datetime.now ) --~--~-~--~~~---~--~~ 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: Is Identity too much? I think so.
Em Domingo 23 Abril 2006 20:04, Jorge Vargas escreveu: I'm agains that, we will never reach a good for all default model. I think that the fact the default one is big means it will encourage most people to think of good/better/big ways to use it. (I'm refering to new web-developers) If we ever change it there should be diferent set of pre-define providers and have one as default. Or just don't define one at all and make it as simple as one class you define in your model, and make it as open as possible. Please, say that at ticket #778 (http://trac.turbogears.org/turbogears/ticket/778) I believe it is better to have more opinions there, even though there's a link to this thread. -- 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: Calendar Widget and IE: 'Calendar_TT.DEF_DATE_FORMAT' is null or not an object
And here is a live instance of that simple test project running on a Linux/TG 0.9a4 server: http://68.229.195.139:8082 I probably should also include: TurboGears 0.9a4 nose 0.8.6 RuleDispatch 0.5a0 setuptools 0.6a11 FormEncode 0.4 cElementTree 1.0.5-20051216 PasteScript 0.5 elementtree 1.2.6 simplejson 1.1 SQLObject 0.7.1dev-r1588 CherryPy 2.2.0 TurboKid 0.9.3 TurboJson 0.9.1 PyProtocols 1.0a0 Cheetah 1.0 PasteDeploy 0.5 Paste 0.5dev-r4745 FormEncode 0.4 kid 0.9.1 elementtree 1.2.6 --~--~-~--~~~---~--~~ 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] How many of us are gentoo users?
I want to see if there other people interests in having setuptools work with portage.Maybe revive eggs.gentooexperimental.org if there enough people we can start a movement from TG to the rest of python/gentoo community to make setuptools a std. and hopefully get Guido to make it into python 2.5any takers? or just someone that will be interested in this happening (and not actually working on it ;)I was a post on gentoo forums from someone name Jeff is he here too? he talk a lot about tg --~--~-~--~~~---~--~~ 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] Problem with SO and .select() when comparing joined data
Hey guys I was wondering if you could give me a hand with an SO problem I've run in to. I'm building a search mechanism for my database. This is what my model (essentially) looks like: class Player(SQLObject): firstname = StringCol(length=255) lastname = StringCol(length=255) fullname = DatabaseIndex(firstname, lastname, unique=True) # ..snip.. passing = IntCol() forsale = SingleJoin(PlayerForSale) # Don't really want this here, thought I might as well class PlayerForSale(SQLObject): player = ForeignKey(Player, alternateID=True) askingprice = IntCol() Anyway I'm trying to do .select to get some data, but I can't seem to make comparisons properly. Some examples: list(PlayerForSale.select(AND(PlayerForSale.q.player_id == Player.q.id, Player.q.passing 1))) Traceback (most recent call last): File console, line 1, in ? File /usr/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1675-py2.4.egg/sqlobject/sqlbuilder.py, line 350, in __getattr__ raise AttributeError(%s instance has no attribute '%s' % (self.soClass.__name__, attr)) AttributeError: PlayerForSale instance has no attribute 'player_id' list(PlayerForSale.select(AND(PlayerForSale.q.player == Player.q.id, Player.q.passing 1))) Traceback (most recent call last): File console, line 1, in ? File /usr/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1675-py2.4.egg/sqlobject/sqlbuilder.py, line 350, in __getattr__ raise AttributeError(%s instance has no attribute '%s' % (self.soClass.__name__, attr)) AttributeError: PlayerForSale instance has no attribute 'player' As you can see there are no PlayerForSale.q.* attributes for my ForeignKey, which is a real bummer. I can see this field in the database as well, so it's noting to do with that The closest I got was this: len(list(Player.select(AND(Player.q.passing = 1, Player.forsale 0 34 But that's not even nearly close as: len(list(PlayerForSale.select())) 13 I think that's just plain way off Can anyone help me with this? I'm totally stumped and a bit disappointed :-/ 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: Is Identity too much? I think so.
Jorge Vargas wrote: I'm agains that, we will never reach a good for all default model. I think that the fact the default one is big means it will encourage most people to think of good/better/big ways to use it. (I'm refering to new web-developers) If we ever change it there should be diferent set of pre-define providers and have one as default. Or just don't define one at all and make it as simple as one class you define in your model, and make it as open as possible. The patch only removes the requirement to populate the fields, not the fields themselves. They are still there to be used. Just optional. It is much easier to just extend tg_users to add more fields or more constraints than it is to remove the the requirement to populate existing fields. In particular, the uniqueness constraint on the email address doesn't make sense for a lot of apps. A person who is assigned administrative privileges may very well also need a non-administrative account for regular use, and yet have only one valid email address. -Steve --~--~-~--~~~---~--~~ 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: Calendar Widget and IE: 'Calendar_TT.DEF_DATE_FORMAT' is null or not an object
Em Domingo 23 Abril 2006 17:55, Steve Bergman escreveu: Using the calendar widget I am getting this error from IE6: Error: 'Calendar_TT.DEF_DATE_FORMAT' is null or not an object However, it is working just fine with Firefox 1.0.8, Opera 8, and Konqueror. Has anyone else seen this problem? Or better yet, resolved it? I haven't but check your language settings... It might be something related to the internationalized version of JSLink that is used with the Calendar. -- 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: Problem with SO and .select() when comparing joined data
BTW it's late here and I should have made it a bit clearer: What I'm actually trying to do is get a list of PlayerForSale objects based on the SingleJoin'd .player's attributes. The SQL for this would be: select * from player_for_sale, player where player_for_sale.player_id = player.id and player.passing = 1 However I'd really like to use SO for this as I want to build my search criteria pythonicly, 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: Is Identity too much? I think so.
On 4/23/06, Jorge Godoy [EMAIL PROTECTED] wrote: Em Domingo 23 Abril 2006 20:04, Jorge Vargas escreveu: I'm agains that, we will never reach a good for all default model. I think that the fact the default one is big means it will encourage most people to think of good/better/big ways to use it. (I'm refering to new web-developers) If we ever change it there should be diferent set of pre-define providers and have one as default. Or just don't define one at all and make it as simple as one class you define in your model, and make it as open as possible.Please, say that at ticket #778( http://trac.turbogears.org/turbogears/ticket/778)Done I believe it is better to have more opinions there, even though there's a linkto this thread.How about what I said there, have no default provider? Unless people contrain their app to the default provider most people will a) extend itb) write their ownproblem with a) is that it adds overhead, basically 2 everything being the most expensive (in performance) the 2 tablesproblem with b) is that even if it's easy most people at first glance are scare of going into the deeps of TG. So having no default at all will make everyone go with b) Looking at the soprovider.py code, the TG_* classes are just normal SQLObjects the only reason they are there is convinience (which seems some people don't see it that way) --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: Is Identity too much? I think so.
The patch only removes the requirement to populate the fields, not thefields themselves.They are still there to be used.Just optional. Yes I know but the original poster refered to people having problems with it which makes sence, and since most people trying TG/identity for the first time wont dare to go into the TG code to dig up the TG_* classes. It is much easier to just extend tg_users to add more fields or moreconstraints than it is to remove the the requirement to populate existing fields.Yes your right, but it will be easier to just write whatever you want it to be, and it's more efficient (both in having all you need in one place and in performance) In particular, the uniqueness constraint on the emailaddress doesn't make sense for a lot of apps.A person who is assigned administrative privileges may very well also need a non-administrativeaccount for regular use, and yet have only one valid email address.Yes your right about that but I think this discussion is beyond those 2 fields. -Steve --~--~-~--~~~---~--~~ 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: Is Identity too much? I think so.
Yes your right about that but I think this discussion is beyond those 2 fields. Just to be clear, I agree completely that defining tg_users in model.py would be perfect. The programmer would create a model which would include, at minimum, userId and password, along with whatever fields he or she needs for the app. That would just make s much sense. If such a thing could be ready and included in 1.0 I would be very happy indeed. Removing the constraints on the current default soprovider now could be thought of as administering a pain killer to relieve the pain while scheduling an operation to fix the cause of the pain. --~--~-~--~~~---~--~~ 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: Calendar Widget and IE: 'Calendar_TT.DEF_DATE_FORMAT' is null or not an object
I'm using the default calendar-en.js Googling for the problem is fairly discouraging. There are plenty of others who have had the problem from 2004 thru Jan 2006. But not a single instance that I have found of anyone who experienced the problem actually getting it solved except by using another calendar. :-( Is anyone else using the default language and seeing it work on IE? Does the link I posted above work for anyone using IE? Thanks, Steve --~--~-~--~~~---~--~~ 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: Is Identity too much? I think so.
On 4/23/06, Jorge Godoy [EMAIL PROTECTED] wrote: Em Domingo 23 Abril 2006 20:44, Jorge Vargas escreveu: How about what I said there, have no default provider? Unless people contrain their app to the default provider most people will a) extend it b) write their ownThere are applications where it is a good default.I think we need a better way to measure that, My biggest one forexample :-)because you made it fit to it :) (not that that is bad) Having no default provider makes the entry harder as well.You can only bedissatisfied / satisfied with something you know how to make work.You didn't undestand or we are confused in terms, I'm not saying replace soprovider.py I'm just saying remove the TG_* classes, and make soprovider.py look for them in the model.py of each project, changing the way the config values work.In fact we can even make a tg-admin quickstart identity that will create a model.py file with all the TG_* classes commented out. That will even make migration easier, the only thing everyone that is using the original provider has to do is uncomment those lines, (or copy them over) and for people that have extend it with 1 or 2 fields can think it better and just make a new class with the new values. problem with a) is that it adds overhead, basically 2 everything being the most expensive (in performance) the 2 tables problem with b) is that even if it's easy most people at first glance are scare of going into the deeps of TG. So having no default at all will make everyone go with b) The scariest thing, according to you...It doesn't sound like something thatwould make it a good default (no default is no good default).see above See, for example, Ben's and Tim's cases.Both are satisfied with the model,they just need minor tweaks.Tim uses it as it is, even with some facilityof logging in by email, while Ben would be happy if this was optional.But the model needed just minor tweaks for both.Again this wouldn't be an issue if the code was right there in their model.py and they could have just change it. Looking at the soprovider.py code, the TG_* classes are just normal SQLObjects the only reason they are there is convinience (which seems some people don't see it that way)Yes.Those could go the harder way, instead of forcing everyone to follow that path...I'm liking the tg-admin quickstart identity idea much more everytime i think about it :) --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 -~--~~~~--~~--~--~---
