On 9/16/05, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> class MyModel(meta.Model)
> f = meta.CharField(...)
>
> class META:
> ...
>
> class MODULE:
> ...
>
> class MANIPULATOR:
> ...
Meta? Module? Manipulator? M
On Sep 16, 2005, at 2:19 PM, Eugene Lazutkin wrote:
+1 from me.
Me three.
Additionally, we should make the manipulator methods work the same way::
class MyModel(meta.Model)
f = meta.CharField(...)
class META:
...
class MODULE:
...
+1 from me.
"Adrian Holovaty" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]
On 9/15/05, Sune Kirkeby
<[EMAIL PROTECTED]> wrote:
>
> Then one could put "def gnah" in MODULE_LEVEL instead of
> "def _module_gnah" in the model, also exceptions and the
> module_constants that cannot b
On 15 Sep 2005, at 23:45, Sune Kirkeby wrote:
Hmm... And, how about a "MODULE_LEVEL"-class inside
the model-classes, whose attributes are copied into the
genereated module? I think I like that more than class-attributes,
since it emphasises that black magic is occuring behind the
scenes (I thi
On Fri, Sep 16, 2005 at 12:21:08PM -0400, Adrian Holovaty wrote:
> On 9/15/05, Sune Kirkeby <[EMAIL PROTECTED]> wrote:
> > Then one could put "def gnah" in MODULE_LEVEL instead of
> > "def _module_gnah" in the model, also exceptions and the
> > module_constants that cannot be auto-deduced could
>
On 9/16/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> The one thing I don't like is that I cannot add decorators like
> classmethod. For instance, this method:
>
> @classmethod
> def clsmethod(cls):
> print "HERE in", cls
>
> Blows up like this for me:
>
> File "C:\www\djan
On 9/15/05, Sune Kirkeby <[EMAIL PROTECTED]> wrote:
> Couldn't django auto-fill much of module_constants
> from co_freevars in the code-objects of the methods? That
> would be nice.
That's possible, but I've hesitated to do so because models have a lot
of global variables available to them -- bas
On 9/16/05, Sune Kirkeby <[EMAIL PROTECTED]> wrote:
> On 9/16/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> > Another extremely common problem is the need to have a field
> > automatically set to some value when an item is created or updated
> > (most commonly a field such as pub_date or last_mo
On 9/16/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> Another extremely common problem is the need to have a field
> automatically set to some value when an item is created or updated
> (most commonly a field such as pub_date or last_modified). I wonder
> if the above mechanism, or something sim
On 9/16/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> tagfield = meta.FakeCharField()
> def load_tagfield(self):
> # Returns the contents of the field when it is displayed
> def save_tagfield(self, value):
...
Instead of Fake*, I suggest Deferred, or Mapped*, or Extended*.
I'm trying to work out the best way to implement tagging in Django,
for a relaunch of my blog system.
The model seems natural enough:
class Tag(meta.Model):
tag = meta.SlugField()
...
class Entry(meta.Model):
pub_date = meta.DateTimeField()
headline = meta.CharField(maxlengt
On 9/15/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 9/15/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> > from django.models.blog import Blog, Entry
> >
> > Blog.get_list()
> > Blog.get_object()
> > Entry.get_iterator()
>
> I have a natural aversion to class methods like that. To me,
On 15 Sep 2005, at 23:10, Adrian Holovaty wrote:
I have a natural aversion to class methods like that. To me, it makes
more sense for a *module* to contain functions that return instances,
than for a *class* to have methods that return instances of that same
class. It's one of the things I don
The one thing I don't like is that I cannot add decorators like
classmethod. For instance, this method:
@classmethod
def clsmethod(cls):
print "HERE in", cls
Blows up like this for me:
File "C:\www\django\core\meta\__init__.py", line 490, in __new__
assert callable(v), "%r i
14 matches
Mail list logo
