On Fri, May 30, 2008 at 12:40 AM, percious [EMAIL PROTECTED] wrote:
It came to my attention while working on tg.ext.silverplate that any
extension which requires identity will need access to the classes and
table names which it uses in order to handle generic permission
handling. I need
config['identity'] = {'user_class':User,
'group_class':Group,
'permission_class':Permission,
'users_table':'tg_user',
'groups_table':'tg_group',
Perhaps it would work if we made the restriction that extensions
cannot modify existing tables, but may add tables, defining them in a
separate model file?
cheers.
-chris
On May 30, 7:37 am, Mark Ramm [EMAIL PROTECTED] wrote:
All of this boils down to the simplest approach: components
One more thing, before I commit.
It would be good to store the password encoding type the way we do
with TG1.
I will commit this by the end of the sprint at the latest.
cheers.
-chris
On May 30, 7:44 am, Mark Ramm [EMAIL PROTECTED] wrote:
config['identity'] = {'user_class':User,
I just wanted to say thank you to Alberto for his hard work.
Also, I wanted to mention that I don't know of any widgets in the
twtools family that use Rule Dispatch. I urge those using RD in their
widgets to speak up about it so that we can move quickly from
deprecation to elimination.
cheers.
Mark Ramm wrote:
This is fine when you want super simple things. But take a
look at django contrib for a whole list of things that would be
absolutely impossible if apps couldn't change the model. (A
simple example, a comments app, which allows you to add comments
to various content.)
I
Here is what I am hoping to solidify on:
config['identity'] = {'user_class':User,
'group_class':Group,
'permission_class':Permission,
'users_table':'tg_user',
'groups_table':'tg_group',
On May 30, 10:58 am, Jonathan LaCour [EMAIL PROTECTED]
wrote:
I'm tempted to suggest code generation as a solution for this, but I
think that also provides issues when you want to upgrade a component
for example.
Perhaps there could be a balance here, where if you just want the
default
On Fri, May 30, 2008 at 6:48 PM, Patrick Lewis [EMAIL PROTECTED] wrote:
- the name of the login controller
- login form values
- cookie name
Is there any plan to add these options? And is tgreposewho going to be
modified to consume these options?
Yes. We would like to be as flexible as
Patrick Lewis wrote:
Other than upgrading, are there other issues with injection /
templating? Is reuse in other projects / apps a concern? Are
there other issues? From the standpoint of seeing what's going on
and making changes though, injection is attractive (IMO).
Not really. The big
i am not sure cookie name and name of the login controller are really
identity entities. (say that 3 times fast!)
what do you mean by login form values?
-chris
On May 30, 10:48 am, Patrick Lewis [EMAIL PROTECTED] wrote:
On May 30, 11:00 am, percious [EMAIL PROTECTED] wrote: Here is what I am
Hi,
ToscaWidgets 0.9 is available for testing at the dev repository. To
upgrade either pull the new changes with Mercurial or install the
development snapshot:
easy_install -U
http://beta.toscawidgets.org/hg/ToscaWidgets-dev/archive/tip.zip
Most notable change is that there's not C dependency
percious wrote:
I just wanted to say thank you to Alberto for his hard work.
You're welcome :)
Also, I wanted to mention that I don't know of any widgets in the
twtools family that use Rule Dispatch. I urge those using RD in their
widgets to speak up about it so that we can move quickly
if google let me use dancing banana emoticons, you would see a whole
row of them.
-chris
On May 30, 12:31 pm, Alberto Valverde [EMAIL PROTECTED] wrote:
percious wrote:
I just wanted to say thank you to Alberto for his hard work.
You're welcome :) Also, I wanted to mention that I don't know
If you wanted to later tweak things, you could issue another
command, which could selectively start replacing those placeholders
(model, templates, API, etc) with the actual generated
code/templates, which you could then edit to your heart's content.
This is what I meant by a hybrid
I'm tempted to suggest code generation as a solution for this, but I
think that also provides issues when you want to upgrade a component
for example.
The django way is pure code generation. There are 2 problems with
code-generation:
1) putting not-well understood code inside your project
Anyway, the release will most probably go out even if not
all those tickets are closed so these important changes can be tested in
the wild ASAP.
This is fantastic news. Thanks for all the hard work Alberto, Paul,
Chris, etc.
I'm very much looking forward to the new ToscaWidgets site.
On May 30, 2:13 pm, percious [EMAIL PROTECTED] wrote:
i am not sure cookie name and name of the login controller are really
identity entities. (say that 3 times fast!)
My only real (badly made) point is that I think the config/
middleware.py template should use the config values you are
Hey, I'm new around here, but I'm really excited about using tg2 and I
like to contribute back when I can. I was looking at tgdev/devtools/
templates/turbogears/+package+/templates/about.html and noticed on
line 42 and 44 that there's a space in between the $ and { to prevent
genshi from parsing
Thanks for the contribution.
I'll make sure this change gets put in at this weekend's sprint.
In the future, the best way to post diffs and whatnot is to use:
http://trac.turbogears.org and create a new ticket.
You'll need to create a Trac account before you can add tickets, but
it should be
However, again, the template lookup is handled entirely by the plugin,
so it can do whatever it wants. A future plugin may load templates from
a database, using a completely different notation to identify them.
and also mentions that dotted-path notation is required for template
engines
Changing the pylons version in tw.forms to:
'ToscaWidgets = 0.8.6',
seems to resolve the problem.
I think Alberto has plans to release some new TW versions in the very
near future, but for those sprinting today this should get you
working...
--
Mark Ramm-Christensen
email: mark at
22 matches
Mail list logo
