contrib proposal: django-values
Gulopine
Many projects require a certain amount of calculations and other
features that are based on organizational (or other) policies, rather
than any technical requirements imposed by Python or Django. As those
policies may change and evolve over time, programmers are often
required to change code that utilizes these values. Regardless of how
programmers maintain these numbers, any code change requires time from
a programmer, and a restart of the application. Depending on other
organizational policies, it may also require a testing period, which
may push these minor modifications back until a more major release, to
avoid extra testing periods.
Given that a project I'm working on has several such policies that are
expected to change frequently once the site is up and running, I
developed the django-values framework to deal with exactly this
situation. Essentially, it allows programmers to create placeholders
in Django models, without ever entering the values those placeholders
refer to. The values themselves are then editable by Django users
through an included editor. This allows programmers to use thes
placeholders directly in Python code, while allowing managers and
other non-programmers to maintain the actual policies.
http://code.google.com/p/django-values/
It is essentially an entire subframework, but it exists entirely as a
contrib app, utilizing newforms and standard Django permissions for
its value editor, and supplying class attributes for direct use by
Python code. The entire process is outlined on the Wiki at the above
site, and I would be happy to take any questions or suggestions. I
expect this is something fairly different than what most people are
used to seeing, so I'm glad to explain further if necessary.
P.S. Jacob, in case you're wondering, this is the fairly substantial
project I was referring to recently.
Adrian Holovaty
> http://code.google.com/p/django-values/
>
> It is essentially an entire subframework, but it exists entirely as a
> contrib app, utilizing newforms and standard Django permissions for
> its value editor, and supplying class attributes for direct use by
> Python code. The entire process is outlined on the Wiki at the above
> site, and I would be happy to take any questions or suggestions. I
> expect this is something fairly different than what most people are
> used to seeing, so I'm glad to explain further if necessary.
Interesting! This might indeed be a candidate for django.contrib, just
with some slight changes --
* The name "values" is a bit too abstract -- it took me a while to
figure out exactly what this framework *does*. Maybe something like
"editable constants" or "model-specific options" would be more clear.
* I think it would be cleaner if the values were specified in an inner
class, rather than in the same class namespace as database fields. I'd
suggest something like this, for example:
class BlogEntry(models.Model):
title = models.CharField(maxlength=255)
body = models.TextField()
class Constants:
comment_limit = values.IntegerValue('Max # of comments a
blog can have')
* Similarly, I think the way of accessing values from a model should
use a secondary namespace, rather than using the same namespace as
field names. For example:
# OLD
BlogEntry.comment_limit
# NEW
BlogEntry.constants.comment_limit
I'm sure I'll have other opinions on this as I learn more about it
(and actually *use* the code). But it looks promising so far -- it's a
good feature addition that would come in handy for many people. Nice
job, Gulopine!
Next steps: Let's discuss these three points I've brought up, and
let's play around with the code as it stands so far to see if any
other design-level questions creep up.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Gulopine
> figure out exactly what this framework *does*. Maybe something like
> "editable constants" or "model-specific options" would be more clear.
I will admit that I never really had a clear idea on what to call it.
I knew going in that it would be hard to describe, and I couldn't
think of a clear phrase that adequately captured it. The best I had
come up with was "run-time value configuration" which still isn't
really a good one. I had personally avoided the term "constants" since
they are in fact editable without a restart, but from a programming
standpoint, they function just like constants, so I wouldn't be
completely opposed.
> * I think it would be cleaner if the values were specified in an inner
> class, rather than in the same class namespace as database fields. I'd
> suggest something like this, for example:
>
> class BlogEntry(models.Model):
> title = models.CharField(maxlength=255)
> body = models.TextField()
>
> class Constants:
> comment_limit = values.IntegerValue('Max # of comments a
> blog can have')
Well, I'm not completely attached to that namespace idea, but I do
have a couple specific reasons for it.
By not using an inner class, it can exist completely as a contrib app,
without any modifications to Django's core. Using an inner class
requires special handling specific to that subframework, which seems
to go a bit against the idea of contrib apps being kept outside the
core. I understand that they're not *required* for core functionality,
but having special processing in the core seems to tie them together a
bit more than I'd like, personally. Obviously, that's just my
preference, but that's where I was coming from. The other option I had
considered, that I'll throw out here, is using a base class that could
be used as an inner class. This way, the base class could provide
contribute_to_class as a class method, which would then be used by the
core to handle all the special processing. This could bring the best
of both worlds, using inner class namespaces for these options, while
keeping their processing out of the core.
class BlogEntry(models.Model):
title = models.CharField(maxlength=255)
body = models.TextField()
class Constants(values.Constants):
comment_limit = values.IntegerValue('Max # of comments a
blog can have')
For the other reason, I have to bring up how your second and third
points are very closely related.
> * Similarly, I think the way of accessing values from a model should
> use a secondary namespace, rather than using the same namespace as
> field names. For example:
>
> # OLD
> BlogEntry.comment_limit
>
> # NEW
> BlogEntry.constants.comment_limit
While I'm not opposed to a syntax like that, I never really saw it as
the same namespace. I understand that it technically is, especially in
terms of potential name clashes, but since these constants are only
available on the class, and not on instances, it seemed adequately
separated to me. In addition, I'm very used to language conventions
using class constants that are available directly on the class, and
not on some arbitrary attribute. It just seemed more in line with what
I expected people were already familiar with.
Tying into the previous point, I felt that using an inner class would
make it seem awkward to use an inner class to define these constants,
while accessing them directly on the class. The same awkwardness would
be there if they were defined in the main namespace, while being
accessed on an attribute. So I think it's worth pointing out that your
second and third points really should be discussed together, because a
decision on one really does affect the other.
> I'm sure I'll have other opinions on this as I learn more about it
> (and actually *use* the code). But it looks promising so far -- it's a
> good feature addition that would come in handy for many people. Nice
> job, Gulopine!
I'm glad you like it! I really hope it does help many other people who
have a need for something like this. I'm very eager to hear what other
thoughts and questions you (and anyone else!) have about it. I'm glad
to clarify.
-Gul
Max Battcher
>
> > * The name "values" is a bit too abstract -- it took me a while to
> > figure out exactly what this framework *does*. Maybe something like
> > "editable constants" or "model-specific options" would be more clear.
>
> I will admit that I never really had a clear idea on what to call it.
> I knew going in that it would be hard to describe, and I couldn't
> think of a clear phrase that adequately captured it. The best I had
> come up with was "run-time value configuration" which still isn't
> really a good one. I had personally avoided the term "constants" since
> they are in fact editable without a restart, but from a programming
> standpoint, they function just like constants, so I wouldn't be
> completely opposed.
It's a magic numbers (avoidance) framework. I know this is going to
sound like a joke, but what about calling it
django.contrib.magic_numbers?
--
--Max Battcher--
http://www.worldmaker.net/
oggie rob
> have a need for something like this. I'm very eager to hear what other
> thoughts and questions you (and anyone else!) have about it. I'm glad
> to clarify.
>
> -Gul
Good timing! I was planning to look to something like this pretty soon
- my settings file has been the place for all of this data initially
but was getting out of hand.
So, my first question is whether this could be designed to work
without respect to models. For example, there are a lot of cases where
views might refer to the same data, but not the same models. It would
seem cleaner if there were a separation (and would avoid complications
with inner classes vs. overridden fields). In my particular case, it
would be cleaner to simply have a new class (or classes if it is
easier to manage) that contains ALL the "constant" data. Was there a
reason that you went with field-defined values? I can see the
"context" argument, but seems like a lot of extra complexity if that
is the only reason.
Also, like Adrian I don't like the name as it is now. I think
"Constants" is fine. "Config" might also work but seems less specific.
Djata, perhaps?!
-rob
Adrian Holovaty
> It's a magic numbers (avoidance) framework. I know this is going to
> sound like a joke, but what about calling it
> django.contrib.magic_numbers?
But we've *removed* the magic!
:)
I like the idea of thinking out of the box, though, along the lines of
"localflavor." We need a name that's descriptive but not too
generic-sounding.
Marc Fargas Esteve
* The name "values" is a bit too abstract -- it took me a while to
figure out exactly what this framework *does*. Maybe something like
"editable constants" or "model-specific options" would be more clear.
Isn't a constant supposed to be **constant** ? ;) As those values are constant during server lifetime the name could be ok as it's clear. But maybe "modelsettings" would also sound ok unless it's inside a secondary namespace under the model in which case I'd go for "settings".
BlogEntry.constants.comment_limit
On this "settings" sound nicer, for me.
Integration with the admin interface would be also a nice thing!
Anyway, it's a nice contrib I think almost everyone here has thought about something to handle model specific settings sometime and has large settings.py :)
My 0.02,
Marc
Honza Král
> Hi,
>
> On 4/8/07, Adrian Holovaty <holo...@gmail.com> wrote:
> > * The name "values" is a bit too abstract -- it took me a while to
> > figure out exactly what this framework *does*. Maybe something like
> > "editable constants" or "model-specific options" would be more clear.
>
> Isn't a constant supposed to be **constant** ? ;) As those values are
> constant during server lifetime the name could be ok as it's clear. But
> maybe "modelsettings" would also sound ok unless it's inside a secondary
> namespace under the model in which case I'd go for "settings".
>
> # NEW
> > BlogEntry.constants.comment_limit
>
> On this "settings" sound nicer, for me.
I like "parameters", it wouldn't get confused with settings.py and
accurately describes what it does..
but problem is with name clashes... what if I have a field called
parameters (or constants for that matter)? i think this could work a
bit as a Manager class:
class MyParams( params.Parameters ):
max_items = params.IntegerParam( 'Max ........', default=6, )
class MyModel( models.Model ):
field1 = models....
field2 = models....
params = MyParams()
that way you can choose the name for the pseudo-field and also reuse
your parameters (DRY: I want max_items on many models, I want it to be
simple to reuse these params)
> Integration with the admin interface would be also a nice thing!
definitely
> Anyway, it's a nice contrib I think almost everyone here has thought about
> something to handle model specific settings sometime and has large
> settings.py :)
definetely ;)
>
> My 0.02,
and mine
> Marc
>
>
> >
>
--
Honza Král
E-Mail: Honza...@gmail.com
ICQ#: 107471613
Phone: +420 606 678585
Gulopine
> So, my first question is whether this could be designed to work
> without respect to models. For example, there are a lot of cases where
> views might refer to the same data, but not the same models. It would
> seem cleaner if there were a separation (and would avoid complications
> with inner classes vs. overridden fields). In my particular case, it
> would be cleaner to simply have a new class (or classes if it is
> easier to manage) that contains ALL the "constant" data.
Well, it should be fairly simple to put together a base class within
this framework that can then be subclassed in whatever file you like,
where you could then place your placeholder definitions. This way,
you'd have a separate class that's not connected to Django's DB
framework in any way, but is just a place for your settings.
On Apr 8, 11:18 pm, "oggie rob" <oz.robhar...@gmail.com> wrote:
> Was there a
> reason that you went with field-defined values? I can see the
> "context" argument, but seems like a lot of extra complexity if that
> is the only reason.
I'll list the reasons I chose the current approach, but I should note
that I'm not adamantly tied to any of these, they're just the reasons
I used when building it.
* Like any project, I could only plan for what I could anticipate. I
had no way of knowing what other people would want out of it, so I
only designed for the way my own project would best utilize it.
* Defining them directly inside models allows it to be 100% contrib,
with no modifications to Django's core. Given some of the other
suggestions here, however, this doesn't seem like the only way to go
about that, so I'm open to other concepts.
* Defining them within a class allowed me to use descriptors for
accessing their values. However, this only explains why they weren't
defined at the module level; including a separate class on which to
define them on would also satisfy this goal.
On Apr 9, 7:32 am, "Marc Fargas Esteve" <teleni...@gmail.com> wrote:
> Integration with the admin interface would be also a nice thing!
Well, the supplied editor is based on the admin template, so it
visually integrates with the admin interface, but it does still
require a separate urlpattern, and no links are provided from within
the main admin interface. To me, it'd be ideal for the admin app to
have a way to "plug in" contrib apps like this into the admin. This
would work quite well next to the Add and Change links for the models,
or even at the app level if the app has model-neutral options. Or,
worst case, a separate pseudo-app section could be shown, with a list
of all the apps that utilize these options, with each link going to a
per-app editor.
Perhaps, since there's already considerable work being done on the
admin interface for newforms-admin, could something like this be
included? I'd be willing to do some work on it if it would be a
possibility.
On Apr 9, 7:56 am, "Honza Král" <honza.k...@gmail.com> wrote:
> but problem is with name clashes... what if I have a field called
> parameters (or constants for that matter)? i think this could work a
> bit as a Manager class:
>
> class MyParams( params.Parameters ):
> max_items = params.IntegerParam( 'Max ........', default=6, )
>
> class MyModel( models.Model ):
> field1 = models....
> field2 = models....
>
> params = MyParams()
The ability to change the name would have been present in my subclass
idea mentioned above, but you bring up a very interesting idea. I
hadn't considered the possibility of sharing a set of options across
multiple models, and your example does show an excellent way of
representing that. In fact, that would tie in quite well with rob's
request for defining values without regard to any particular model. If
a separate class is used, it could be instiated within a model OR
directly at the module level.
It could also be useful for other contrib apps to supply their own
class, subclassing the base from this framework, but without
instantiating it. Take, for example, a framework that logs edits to
models. The framework could supply a class with options for what
events should be logged, as well as how much verbosity should be used
in the log. Since those could apply to any model, it would be up to
the individual project to simply import the class and instantiate it
on whichever models use it.
All in all, I'm starting to like the idea of a separate class that's
instantiated wherever it's used. I'll set up a branch for it on the
Google Code page and get to work on it.
Thanks again for all the feedback. It's great to hear that there are
others who need this.
-Gul
Brian Beck
> > So, my first question is whether this could be designed to work
> > without respect to models. For example, there are a lot of cases where
> > views might refer to the same data, but not the same models. It would
> > seem cleaner if there were a separation (and would avoid complications
> > with inner classes vs. overridden fields). In my particular case, it
> > would be cleaner to simply have a new class (or classes if it is
> > easier to manage) that contains ALL the "constant" data.
This does sound useful, and I agree with the above -- the most
immediate use cases for my personal projects have little to do with
models and more to do with templates. For example, the number of
entries to display from my blog feed on my home page. It would be nice
to use this project to not have to restart the site just to change
that...
Gulopine
definitions are moved outside the main field namespace, there's no
longer a clash of functionality between standard fields and these
constant values. That clash was the primary reason I had to recreate
the basic functionality of built-in field types, so they had different
semantics.
Now that they're being moved out, do you guys think it would make more
sense to just use the standard field types? I haven't done too much
with it yet, but it looks like it should work just as well (better,
really, with more available types and less app to maintain).
Essentially, the class would then look quite a bit like a regular
model, only using a different subclass than models.Model (and without
any methods).
The biggest potential pitfall I see is confusion among an Options
class and a Model class, since they'd look so much alike. I look at
newforms, and how they redefined their own fields, which is due to
form fields having inherently different functionality from model
fields.
There's also something to be said for confusion caused by the overkill
of using model fields for this. After all, this app won't have the
concept of core, unique, default, editable, db_column, etc. Some users
might supply values for those, thinking it would have some impact, but
nothing would be different.
On the flipside, however, there's something to the notion of using
*some* existing model field functionality. Currently, for instance,
there's no allowance for blank, choices, radio_admin, or help_text. I
suppose given the short list of borrowed functionality, it would be
simple enough to duplicate, but I'm not a fan of reinventing the
wheel. Thoughts?
-Gul
doug.na...@gmail.com
the reasons you specified.
How would a FileField or an ImageField work? How would the proposed
CreatedTimestamp/ModifiedTimestamp fields work?
ForeignKey? yikes.
The added confusion for users and developers who are extending or
creating their own model Fields greatly outweighs the benefits from
reusing some parts of the existing model field code.
Because I like straw men:
One radical approach would be to have the model.XXXField's inherit
from value.XXXValue's.
That would be DRY at the cost of development and code complexity.
That would also mean that the values system would really be part of
the django core and not the contrib.
I am not sure people are ready for that.
Just my 2c.
-Doug
Ian Holsman
it 'preferences' (see http://zyons.com/preferences/ )
The zyons version allows for:
- constants at the site level (ie max blog comments can be different
on different sites)
- allows users (registered and anonymous) to set their preferences
(like in a user profile)
- is not set at the model level, but at the application level
you might want to look at that (http://svn.zyons.python-hosting.com/
trunk/zilbo/common/prefs/ )
for ideas.
--Ian
--
Ian Holsman
I...@Holsman.net
http://VC-chat.com It's what the VC's talk about
Gulopine
<doug.napole...@gmail.com> wrote:
> How would a FileField or an ImageField work? How would the proposed
> CreatedTimestamp/ModifiedTimestamp fields work?
> ForeignKey? yikes.
Very true. I hadn't considered the many fields that wouldn't even make
sense themselves in this context.
On Apr 10, 6:28 pm, "doug.napole...@gmail.com"
<doug.napole...@gmail.com> wrote:
> One radical approach would be to have the model.XXXField's inherit
> from value.XXXValue's.
> That would be DRY at the cost of development and code complexity.
> That would also mean that the values system would really be part of
> the django core and not the contrib.
I would personally oppose this very strongly for two reasons. For one,
like you said, it would make a core Django feature rely on this
subframework, which would intimately connect it to the core, which I
don't want at all. I don't expect this will be used by the majority of
Django users, so keeping it contrib is key.
For the other, the functionality of these is so different that model
fields would essentially have to override everything anyway, just to
retain their existing functionality. Essentially all that would change
is the inheritance chain for model fields, making it (unnecessarily)
longer than it needs to be, for no real benefit. After all, nobody's
ever gonna use isinstance(field, values.Value).
-Gul
Gulopine
> The zyons version allows for:
> - constants at the site level (ie max blog comments can be different
> on different sites)
True, site-awareness would be a definite benefit that I hadn't yet
included.
> - allows users (registered and anonymous) to set their preferences
> (like in a user profile)
I had also started some preliminary work on a user preferences
structure, but I found that the auth system's profile setup was
sufficient for most needs (though I do like that you extended it to
anonymous users as well). Also, I don't think I'd want user
preferences tied in with this contrib anyway, as those are really two
different features. And yes, I know you were just stating what yours
supports, rather than recommending mine do the same.
> - is not set at the model level, but at the application level
I like the recent proposals to make it optional whether it is placed
on the model or the application. While many of the arguments here so
far have been for application-level constants, my project (and I
expect many others) makes more sense with these on models, as they
really control core model behavior. Options are good.
-Gul