On 5/18/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Don't forget that responses like this are partly written for the archive
> so that we can optimistically assume that the next person to walk this
> path will have either read the archives
Ha!
(Sorry, couldn't resist :)
Jacob
--~--~---
Django Managment eXenstions? ;)
On 5/10/07, Gulopine <[EMAIL PROTECTED]> wrote:
>
>
> I should also add that I haven't changed the name yet. I've opted for
> the name Options to describe a collection of values that can be
> applied to a module or model, but I'm not sure how to best name and
> desc
On Fri, 2007-05-18 at 13:55 -0400, Marty Alchin wrote:
> On 5/18/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > No third-party app should expect to be installed in django.contrib,
> > because that would require app users to modify their pristine (and
> > possibly unwritable) Django source.
On 5/18/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> No third-party app should expect to be installed in django.contrib,
> because that would require app users to modify their pristine (and
> possibly unwritable) Django source. Presumably django-values was written
> that way as some kind of
On Fri, 2007-05-18 at 10:36 -0700, Jason Davies wrote:
> On May 18, 5:30 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
> wrote:
>
> > Indeed; I've been telling people interested in getting stuff into
> > Django that doing it as a standalone project first is probably the
> > best idea. I really like
On 5/18/07, Jason Davies <[EMAIL PROTECTED]> wrote:
> Is there any way around this, or is it just something inherent to
> Python?
Personally, I think the sanest way to handle a standalone app is to
assume it'll be directly on the Python path and build around that
idea; asking people to install in
On May 18, 5:30 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Indeed; I've been telling people interested in getting stuff into
> Django that doing it as a standalone project first is probably the
> best idea. I really like the constraints that places on how these
> external projects are d
On 5/18/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> I would definitely recommend that process to anyone else looking to
> write a contrib app for Django, as it makes it much easier for the
> eventual audience to try it out in real-world projects. I got
> suggestions and requests for things I nev
On 5/18/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> I don't really care one way or the other. I haven't intuited what makes
> something appropriate for contrib or not.
Yeah, I think I might do well to try to write that up (in the
contributing document, eventually). I think I have a feelin
On 5/18/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Nice that it already exists as a standalone app, though, so that people
> can play with it a bit without having to apply patches. That's good
> development practice.
That's been a big part of shaping the current version of the app. I
wou
On Thu, 2007-05-17 at 20:11 -0500, Jacob Kaplan-Moss wrote:
> > In my opinion it really deserves a spot in the default contrib apps.
>
> Mine as well.
>
> The only thing holding me back from full support is the name; "values"
> doesn't explain enough about what the app does to me. Yes, it's
> bi
On 5/17/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> The only thing holding me back from full support is the name; "values"
> doesn't explain enough about what the app does to me. Yes, it's
> bike-shedding, but Django's always had a nice color scheme. That is,
> names are important (to a po
> In my opinion it really deserves a spot in the default contrib apps.
Mine as well.
The only thing holding me back from full support is the name; "values"
doesn't explain enough about what the app does to me. Yes, it's
bike-shedding, but Django's always had a nice color scheme. That is,
names
On May 16, 12:47 pm, Gulopine <[EMAIL PROTECTED]> wrote:
> Admittedly, I had considered adding 'choices', but I had decided
> against it, given that these would be edited far less often than
> standard Django models, and by more trustworthy personnel.
I agree, but I'd just prefer to have it out
Admittedly, I had considered adding 'choices', but I had decided
against it, given that these would be edited far less often than
standard Django models, and by more trustworthy personnel. It just
didn't seem quite worth it to me. However, given that the app is quite
likely to be used by distribut
Hi Gulopine,
I've been testing your contrib and I'm liking it so far. Finding a
suitable name is quite difficult...At the moment I'm calling them
'presets' in my code, but that may be a bit too generic.
As an aside: what do you think about adding a 'choices' parameter to
relevant ValueTypes? The
I should also add that I haven't changed the name yet. I've opted for
the name Options to describe a collection of values that can be
applied to a module or model, but I'm not sure how to best name and
describe the framework as a whole. Google Code won't let me change the
URL from django-values, b
Well, after a long time of work on it, I've committed a new version of
django-values, incorporating feedback from the previous discussion on
the topic[1]. There's still a little work I'd like to do on it, but
it's very functional right now, and ready for use and testing by
anyone who's interested.
18 matches
Mail list logo
