"Robert Wittams" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> === Events ===
>
> I discussed this with Adrian on IRC a few times, and we agreed that
> events would be a good way to handle quite a number of the issues we
> face - particularly loose coupling.
>
> I've looked arou
Hey Robert --
Thanks for your work on this -- I've just had a chance to check out
the branch for the first time, and it's just amazingly awesome.
On Dec 16, 2005, at 8:09 PM, Robert Wittams wrote:
Ok, so in the magic-removal branch, I've refactored things in a way
which makes it very easy t
On 12/16/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
> There are quite a number of other areas this can be applied to as well.
>
Middleware?
=== Funky stuff ===
Ok, so in the magic-removal branch, I've refactored things in a way
which makes it very easy to extend the meta system as a third-party.
When a class such as this:
class Something(Model):
name = CharField(maxlength=100)
is created, the following happens in the metaclass
On Dec 16, 2005, at 2:01 PM, Robert Wittams wrote:
Brant Harris wrote:
However, Why do they have to be all caps? "class Admin" and "class
Meta", seem nicer.
I think so too. It would be easy enough to make it accept both.
I always think capitals are constants, or I'm using something scary
l
On 12/17/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
> Adding orm hints for replication and for federation is going to be
> interesting, shall we say ;-)
>
>
a connection list each specifying a specific connection. (with a default one)
your could then override a the 'READ' connection wit
Brant Harris wrote:
> On 12/15/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
>>Basically, promote Admin settings to a full inner class, rather than
>>nesting it in meta. It would still end up in meta though.
>>
>>Thoughts?
>
>
> +1
>
> Just last night I was making a new model, and thinking t
Robert Wittams wrote:
>That would be even wierder in my opinion, as the Manager:
>a) is not required
>b) is orthogonal to the admin
Fair enough. I guess what I was looking for was an ADMIN class that is
closer to a manipulator (and if so I think it is inflexible to assume
there should only ever b
On 12/15/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> Basically, promote Admin settings to a full inner class, rather than
> nesting it in meta. It would still end up in meta though.
>
> Thoughts?
+1
Just last night I was making a new model, and thinking that this should be done.
However, Wh
+1
On 12/16/05, hugo <[EMAIL PROTECTED]> wrote:
>
> >However, if a person *does* use a database, we still want that
> >connection.close() in a finally.
>
> Adapt my idea of middleware for database transaction handling :-)
>
> Essentially if you have code outside the web app context, you handle
> s
Simon Willison wrote:
>
>
> On 16 Dec 2005, at 09:59, hugo wrote:
>
>> But if you are running a web application, you just hook
>> up a middleware that opens a cursor on process_request and commits or
>> rolls back that cursor on process_response (if the user did handle his
>> transaction himse
>This makes the assumption (currently inherent in Django) that you
>will only use one database connection. This can cause problems if you
>need to scale your application.
Actually it only makes the assumption that it is a common case that you
only manage one connection. There is nothing that woul
On 16 Dec 2005, at 02:38, Adrian Holovaty wrote:
I could go either way on this. But if we create the ADMIN thing, maybe
it's a good opportunity to move some of the admin-specific Field
options into the ADMIN class instead of in the Field.
It's always struck me as a design smell that admin sp
On 16 Dec 2005, at 09:59, hugo wrote:
But if you are running a web application, you just hook
up a middleware that opens a cursor on process_request and commits or
rolls back that cursor on process_response (if the user did handle his
transaction himself, it won't matter - the data will be co
oggie rob wrote:
> Can the admin options be specified in the meta.Manager field?
> e.g.
> class Whatever(Model):
> name = CharField(maxlength=100)
> objects = Manager(list_display=)
>
> -rob
>
>
That would be even wierder in my opinion, as the Manager:
a) is not required
b)
>However, if a person *does* use a database, we still want that
>connection.close() in a finally.
Adapt my idea of middleware for database transaction handling :-)
Essentially if you have code outside the web app context, you handle
stuff yourself. But if you are running a web application, you j
>Basically, promote Admin settings to a full inner class, rather than
>nesting it in meta. It would still end up in meta though.
+1 from me on that one. The Admin-Minilanguage within the
META-Minilanguage is rather weird currently, one uses attribute=value
syntax, the other uses list-of-named-par
17 matches
Mail list logo
