User Group

[new2turbo]

I am a new user to Turbogears and python.
I just got handed an existing project in turbogears. I need to make
USER -Group interface. How do I do it.
Also, how do I insert into the user_group_table using Identity though
a web-interface. I have made a user interface and a group interface
using CRUD....

any help will be highly appreciated... Thanks....

[Mike Schinkel]

Would be nice to have instructions for a TurboGears Appliance, ala:

http://virtualappliances.org/?p=45

I don't have the skills yet to do it, but would if I could...

-Mike

[gasolin]

Hi, at first you should open the tg-admin shell(or use Catwalk if you
are using SQLObject) and make sure you can do the basic operations
around your USER -Group models.

Then, apply the same operation on the (hand made/generated by tgcrud)
interface. That would be:

1. form the selected groups to a group check list (or something else)

* in controllers: select group by user id:
Group.select(Group.q.user_id==id) / Group.select_by(user_id=id) or
Group.select(Group.c.user_id==id)
* in template: form the group list

2. process the select group

* in controllers: select the user: record = User.get(id);
* in controllers: assign group_list to record.groups

Above note just covered the add/modify process.

--
Fred

[gasolin]

oops, I almost forgot that code has already documented:

http://docs.turbogears.org/1.0/CRUDTemplate#one-to-many-relationships

--
Fred

[Cliff Wells]

http://www.rpath.org/rbuilder/project/turbogears/

Haven't tried it, so YMMV.

Cliff

[Mike Schinkel]

Cliff wrote:
> > Would be nice to have instructions for a TurboGears Appliance, ala:
> >
> > http://virtualappliances.org/?p=45
> >
> > I don't have the skills yet to do it, but would if I could...
> >
>
> http://www.rpath.org/rbuilder/project/turbogears/
>
> Haven't tried it, so YMMV.

Thanks Cliff. I should have been more clear. I meant it would be nice to
have the TurboGears Appliance specifically on Virtual Appliances for benefit
of TurboGears mindshare because I think Virtual Appliances is getting a lot
of mindshare.

Also, the biggest problem I have with TurboGears, and the most important
thing I think could be done is to make it easy to install on every ISP. I
know that might require rearchitecting, but most ISPs won't allow it which
is far too much friction for anything but a trivial level of adoption.

-Mike

[Florent Aide]

On 7/14/07, Mike Schinkel <mikesc...@gmail.com> wrote:
>
> Cliff wrote:
> > > Would be nice to have instructions for a TurboGears Appliance, ala:
> > >
> > > http://virtualappliances.org/?p=45
> > >
> > > I don't have the skills yet to do it, but would if I could...

Hi Mike,

maybe you could begin to produce something (in the TG wiki?) and then
post the result here or in the documentation mailing list so we can
help you polish the result.

This would really be a worthy addition !

Cheers,
Florent.

[Mark Ramm]

> Also, the biggest problem I have with TurboGears, and the most important
> thing I think could be done is to make it easy to install on every ISP. I
> know that might require rearchitecting, but most ISPs won't allow it which
> is far too much friction for anything but a trivial level of adoption.

Unfortunately this is not a problem we can solve on our own -- no
Python framework works on every ISP.

In TG2 we fully support the WSGI server specification, which is
rapidly becoming the standard in the python world, and which provides
several different ways to hook into servers from mod-python adapters,
to mod-wsgi, to all kinds of other fast-cgi or native python server
options. See the wsgi.org site for more details:

http://wsgi.org/wsgi/Servers

We can't support every possible form of deployment, but with WSGI
support we can support the widest possible range of server options, so
we will be installable in as many places as possible -- more than any
of the non WSGI frameworks out there. :)

[Graham Dumpleton]

On Jul 15, 7:47 am, "Mark Ramm" <mark.mchristen...@gmail.com> wrote:
> > Also, the biggest problem I have with TurboGears, and the most important
> > thing I think could be done is to make it easy to install on every ISP. I
> > know that might require rearchitecting, but most ISPs won't allow it which
> > is far too much friction for anything but a trivial level of adoption.
>
> Unfortunately this is not a problem we can solve on our own -- no
> Python framework works on every ISP.
>

> In TG2 we fully support theWSGIserver specification, which is

> rapidly becoming the standard in the python world, and which provides
> several different ways to hook into servers from mod-python adapters,
> to mod-wsgi, to all kinds of other fast-cgi or native python server

> options. See thewsgi.org site for more details:

>
> http://wsgi.org/wsgi/Servers
>
> We can't support every possible form of deployment, but withWSGI
> support we can support the widest possible range of server options, so
> we will be installable in as many places as possible -- more than any
> of the nonWSGIframeworks out there. :)

Supporting WSGI is all well and good, but a question I have raised
before and never got an answer from anyone, is whether TurboGears
always works properly with multiprocess web servers. My recent post
about this is at:
http://groups.google.com/group/turbogears/browse_frm/thread/600f15ce80a13df/c81645645e611de6?lnk=gst&q=mod_python&rnum=3#c81645645e611de6

Are the database caching issues with multiprocess web servers briefly
mentioned at the end of:

http://docs.turbogears.org/1.0/mod_python

still an issue or not.

It isn't really good enough to say here is a recipe for using
TurboGears on mod_python but then leave some question marks as to
whether it will work or not. It doesn't exactly leave a potential user
with any great deal of confidence. :-)

Graham

[Mike Schinkel]

> maybe you could begin to produce something (in the TG wiki?)

How would I put a virtual machine in the wiki? BTW, I do not have enough
Linux skills to even consider approaching this myself.

-Mike

[Mark Ramm]

> It isn't really good enough to say here is a recipe for using
> TurboGears on mod_python but then leave some question marks as to
> whether it will work or not. It doesn't exactly leave a potential user
> with any great deal of confidence. :-)

For TG 1.x I still think the standard deployment advice of using
mod-rewrite or mod-proxy is still the best way to go. It would be
great to test and resolve the issues you mentioned if they are still
there, but 1.x isn't yet as fully WSGI compliant as turbogears 2.

For TG 2.0 I don't believe we will have any problems with
multi-process web servers, but if I'm wrong I'd be very interested in
hearing about it!

--Mark Ramm

[Graham Dumpleton]

The issues I am talking about have nothing to do with WSGI compliance,
they are more to do with the database layer. If no changes have been
made to the database layer to address caching problems which some have
mentioned, if they do in fact exist, then it will also affect TG 2.0.

Graham

[Mark Ramm]

> > For TG 2.0 I don't believe we will have any problems with
> > multi-process web servers, but if I'm wrong I'd be very interested in
> > hearing about it!
>
> The issues I am talking about have nothing to do with WSGI compliance,
> they are more to do with the database layer. If no changes have been
> made to the database layer to address caching problems which some have
> mentioned, if they do in fact exist, then it will also affect TG 2.0.

Yea, I guess I wasn't clear about that, the whole database layer is
being replaced in TG 2, and the new way of doing things should be
multi-process safe. Though we haven't written the SQLObject version
yet, and it may need some additional work to verify that works fine in
a multi-process environment.

Basically TG2 will use the same database layer as pylons, so if things
aren't broken there, they shouldn't be broken here :)

--Mark

[Mark Ramm]

> It isn't really good enough to say here is a recipe for using
> TurboGears on mod_python but then leave some question marks as to
> whether it will work or not. It doesn't exactly leave a potential user
> with any great deal of confidence. :-)

So, I've had a bit more time to look into this issue, and here's where we are:

At this point I would not recommend using Tubogears 1.0.x with
SQLObject and mod-python together. Using mod-proxy, or mod-rewrite
will give you much better results.

However TurboGears 1.1 and 2.0 will use SQLAlchemy by default, and we
will be clearing out the session at request boundaries by default, so
using TG in a multiprocess environment like mod-python or mod-wsgi
should be fine, when using SQLAlchemy.

In the past some users may have had problems with SQLAlchemy and
mod-python, though I don't remember seeing reports of it, but anyway
it should not be a problem in turbogears 1.0.3 or greater -- at least
when using SQLAlchemy!

As of revision 3290, we are now implementing the behavior described
above and are deleting the session between requests, so caching is
limited to a single request lifetime.

--Mark Ramm