On 12/6/10 10:56 PM, jorge.var...@gmail.com wrote:
My 0.02 cents on this.
From many bad nights of chasing bugs with TurboGears' quickstart
command. Make it as simple as possible!
In TG it was decided to go the "Full project route" and then having
experience users delete what's not needed. Back
On Nov 23, 9:48 pm, Ben Bangert wrote:
> On Nov 23, 2010, at 5:30 PM, Mike Orr wrote:
>
> > It sounds good in general. Will it still have a default index view
> > with a welcome page? I think that's a good minimum to get people
> > started. It saves user frustration and questions on the list, "How
On Wed, Dec 1, 2010 at 11:22 AM, nek4life wrote:
> How about writing documentation for Pyramid usage patterns rather than
> supplying numerous paster templates for various configurations?
That is essentially what's happening. Chris is making a pyramid
template that's essentially like the current
On Nov 23, 6:29 pm, Ben Bangert wrote:
> There's been a lot of debate about the 'best set' of pyramid project
> templates for awhile, and after going over a few options with Chris
> McDonough, reading the messages here from Graham Higgins and Mike Orr, I
> think I m
On Sun, Nov 28, 2010 at 9:33 PM, Ben Bangert wrote:
> On Nov 24, 2010, at 3:13 PM, Mike Orr wrote:
>
>> Why a list of sessions? That doesn't seem to give much control over
>> which session you get.
>
> It wasn't intended to. That was just so I wouldn't need to do 'global
> db_session' inside the
On Nov 24, 2010, at 3:13 PM, Mike Orr wrote:
> Why a list of sessions? That doesn't seem to give much control over
> which session you get.
It wasn't intended to. That was just so I wouldn't need to do 'global
db_session' inside the configure function.
- Ben
--
You received this message becau
On Nov 24, 2010, at 7:10 PM, Daniel Holth wrote:
> I recommend the status quo. My reusable pyramid application will not need to
> import pyramid_sqla. It will:
> • have its own declarative base
> • require the user to call ponzi_auth.configure_database(engine)
> • not use databa
I'm not really a big fan of using the threadlocal version of managing
a SQLAlchemy session. I'd prefer to either setup the session using a
BeforeRequest event handler or simply setup a session factory at
configuration (ie Configurator) time and store it in registry.settings
so that requests can re
I recommend the status quo. My reusable pyramid application will not need to
import pyramid_sqla. It will:
- have its own declarative base
- require the user to call ponzi_auth.configure_database(engine)
- not use database reflection, and so will not need a configured engine
before imp
On Wed, Nov 24, 2010 at 2:15 PM, Ben Bangert wrote:
> On Nov 24, 2010, at 1:49 PM, Mike Orr wrote:
>
>> So do we need multiple sessions? I'm not sure we've defined the use
>> cases clearly enough, which runs the risk that we'll make an API that
>> won't be adequate anyway. So I'm inclined to use a
On Nov 24, 2010, at 1:49 PM, Mike Orr wrote:
> So do we need multiple sessions? I'm not sure we've defined the use
> cases clearly enough, which runs the risk that we'll make an API that
> won't be adequate anyway. So I'm inclined to use a single session. We
> can always add a multisession object
On Wed, Nov 24, 2010 at 11:25 AM, Ben Bangert wrote:
. I'm sure we can work out something somewhat flexible for changing
engine bindings to a session on the fly though, like:
>
> from pyramid_sqla import set_session_bind
>
> set_session_bind(session='read_only', engine='db2')
>
> And it'll switch
On Nov 24, 2010, at 10:58 AM, Mike Orr wrote:
> There are a few limitations with putting the dbsession and initialize
> function in a package:
>
> 1) The model is no longer autonomous. A Pylons model can be imported
> and used on its own, even if the rest of the application or Pylons has
> some
There are a few limitations with putting the dbsession and initialize
function in a package:
1) The model is no longer autonomous. A Pylons model can be imported
and used on its own, even if the rest of the application or Pylons has
some error that makes it unusable. A db utility can simply creat
On Nov 24, 2010, at 9:53 AM, Daniel Holth wrote:
> I am also interested in having unrelated packages participate in the
> SQLAlchemy session but unfortunately have not had the opportunity to write
> and release those packages. A couple of SQLAlchemy notes:
Yea, that is one of the things having
I am also interested in having unrelated packages participate in the
SQLAlchemy session but unfortunately have not had the opportunity to write
and release those packages. A couple of SQLAlchemy notes:
It is not necessary for every mapped class to inherit from the same
declarative base class. For
On Nov 23, 2010, at 11:22 PM, Mike Orr wrote:
> I can't read Ben's mind. I need to know what he expects it to contain.
> If we're just talking a Session and Base object and initialize_sql(),
> that's almost too little to justify a package.
So, my thought was that it'd have a DBSession in it, and
On Nov 23, 2010, at 7:50 PM, Chris McDonough wrote:
> I'd suggest instead:
>
> newproj/
>__init__.py
>views.py
>tests.py
>models.py
>templates/
> mytemplate.pt
>static/
>
>
> Such a template might be named "pyramid_diy". "pyramid_diy" would be a
> template u
On Tue, Nov 23, 2010 at 9:33 PM, Chris McDonough wrote:
> On Wed, 2010-11-24 at 00:30 -0500, Chris McDonough wrote:
>> On Tue, 2010-11-23 at 21:24 -0800, Mike Orr wrote:
>> > By the way, with the extensive reorganization of application templates
>> > proposed including restructuring the SQLAlchemy
On Wed, 2010-11-24 at 00:30 -0500, Chris McDonough wrote:
> On Tue, 2010-11-23 at 21:24 -0800, Mike Orr wrote:
> > By the way, with the extensive reorganization of application templates
> > proposed including restructuring the SQLAlchemy support, it puts me
> > and Eric pretty much on hold for writ
On Tue, 2010-11-23 at 21:24 -0800, Mike Orr wrote:
> By the way, with the extensive reorganization of application templates
> proposed including restructuring the SQLAlchemy support, it puts me
> and Eric pretty much on hold for writing tutorials and demos, which I
> was planning to work on over th
By the way, with the extensive reorganization of application templates
proposed including restructuring the SQLAlchemy support, it puts me
and Eric pretty much on hold for writing tutorials and demos, which I
was planning to work on over the next five days. (Because I'm snowed
in in Seattle plus th
On Tue, 2010-11-23 at 20:12 -0800, Mike Orr wrote:
> On Tue, Nov 23, 2010 at 7:50 PM, Chris McDonough wrote:
> > On Tue, 2010-11-23 at 15:29 -0800, Ben Bangert wrote:
> >> Since both Mako and Chameleon are configured out of box, no additional
> >> config/options are necessary to support it. There
On Tue, Nov 23, 2010 at 7:50 PM, Chris McDonough wrote:
> On Tue, 2010-11-23 at 15:29 -0800, Ben Bangert wrote:
>> Since both Mako and Chameleon are configured out of box, no additional
>> config/options are necessary to support it. There is nothing in the
>> template that configures traversal, or
On Tue, 2010-11-23 at 15:29 -0800, Ben Bangert wrote:
> There's been a lot of debate about the 'best set' of pyramid project
> templates for awhile, and after going over a few options with Chris
> McDonough, reading the messages here from Graham Higgins and Mike Orr,
On Nov 23, 2010, at 5:30 PM, Mike Orr wrote:
> It sounds good in general. Will it still have a default index view
> with a welcome page? I think that's a good minimum to get people
> started. It saves user frustration and questions on the list, "How do
> I structure my views and make the first rou
On Tue, Nov 23, 2010 at 3:29 PM, Ben Bangert wrote:
> There's been a lot of debate about the 'best set' of pyramid project
> templates for awhile, and after going over a few options with Chris
> McDonough, reading the messages here from Graham Higgins and Mike Orr, I
There's been a lot of debate about the 'best set' of pyramid project templates
for awhile, and after going over a few options with Chris McDonough, reading
the messages here from Graham Higgins and Mike Orr, I think I might have a
decent solution.
One of the things thats
28 matches
Mail list logo
