皆様
はじめまして。
穗苅と申します。
自己紹介
Zope,Plone関係の開発をしています。
趣味でゲームプログラミングをしていて、その関係で
Webゲームの制作に適したフレームワークを探している中
たまたまTurboGearsに出会いました。
やりたいこと
=
仕事としても趣味としてもTurboGearsに興味を持っています。
現在、TurboGearsの勉強もかねて、社内で使うちょっとしたタスク管理システム
のようなものを作っています。
CGIゲームのようなものも作ってみたいと思っています。
おおたにです。
気になっていても時間がなくて放置していました。sqliteは割といい加減なので
気を付けないと他のDBにしたときに困りますね。
さて、Postgresでテーブルの作成に失敗することがあるという問題は、model.pyに
soClasses = (table1, table2)
のようにテーブルの作成順を指定する必要があるということですね。
調べてもらってありがとうございます。
因みに余談ですが、テーブルの作成順はtg-admin sql sqlで見る限りだとASCII
ソートされているような印象があります。
Atsushi Shibata wrote:
#775: [PATH] quickstart templates is not valid html
+---
Reporter: Lazy| Owner: anonymous
Type: defect | Status: new
Priority: low | Milestone: 0.9a5
Component:
#775: [PATH] quickstart templates is not valid html
+---
Reporter: Lazy|Owner: anonymous
Type: defect | Status: closed
Priority: low |Milestone: 0.9a5
Component:
#724: Turn of automatic svn add behavior in quickstart
+---
Reporter: kevin |Owner: anonymous
Type: defect | Status: closed
Priority: normal |Milestone: 0.9a5
Component:
#776: Enhancements for CogBin
-+--
Reporter: anonymous| Owner: anonymous
Type: enhancement | Status: new
Priority: normal | Milestone: 1.0
Component: Docs |
#777: Impossible to programatically set an AutoCompleteField default value
--+-
Reporter: godoy | Owner: anonymous
Type: defect| Status: new
Priority: high | Milestone: 0.9a5
#777: Impossible to programatically set an AutoCompleteField default value
--+-
Reporter: godoy |Owner: anonymous
Type: defect| Status: new
Priority: high |Milestone: 0.9a5
#777: Impossible to programatically set an AutoCompleteField default value
--+-
Reporter: godoy |Owner: anonymous
Type: defect| Status: new
Priority: high |Milestone: 0.9a5
#777: Impossible to programatically set an AutoCompleteField default value
--+-
Reporter: godoy |Owner: anonymous
Type: defect| Status: new
Priority: high |Milestone: 0.9a5
#777: Impossible to programatically set an AutoCompleteField default value
--+-
Reporter: godoy |Owner: anonymous
Type: defect| Status: new
Priority: high |Milestone: 0.9a5
#778: [PATCH] Patch to make emailAddress and displayName optional in default
soprovider
---+
Reporter: anonymous | Owner: anonymous
Type: defect | Status: new
Priority: normal |
#778: [PATCH] Patch to make emailAddress and displayName optional in default
soprovider
---+
Reporter: anonymous |Owner: anonymous
Type: defect | Status: new
Priority: normal |
#777: Impossible to programatically set an AutoCompleteField default value
--+-
Reporter: godoy |Owner: anonymous
Type: defect| Status: closed
Priority: high |Milestone: 0.9a5
#777: Impossible to programatically set an AutoCompleteField default value
--+-
Reporter: godoy |Owner: anonymous
Type: defect| Status: closed
Priority: high |Milestone: 0.9a5
#778: [PATCH] Patch to make emailAddress and displayName optional in default
soprovider
---+
Reporter: anonymous |Owner: anonymous
Type: defect | Status: new
Priority: normal |
#779: turbogears.util.DictObj improvement
--+-
Reporter: [EMAIL PROTECTED] |Owner: anonymous
Type: enhancement | Status: new
Priority: normal|Milestone: 0.9a5
#780: patch attempt (non functional) at making identity more adaptable
+---
Reporter: [EMAIL PROTECTED] | Owner: anonymous
Type: enhancement | Status: new
Priority: normal |
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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:
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. :)
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
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.
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
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
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
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
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
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
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.
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
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.
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
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.
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
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
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 ?
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
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
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
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
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
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
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
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)
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
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?
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
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.
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
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
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
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
68 matches
Mail list logo
