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 of ease-of-use for the admins. > It just > didn't seem quite worth it to me. However, given that the app is quite > likely to be used by distributed apps, I suppose it could make sense > to provide limits to make sure individual implementations use the > right values. > > I'll do a bit of looking to see how much work it would take to > implement, but since I'm relying heavily on newforms for form > interaction, it shouldn't be too bad. Alright, thanks for considering it! > I'm glad to see someone else is > enjoying it! I am, thanks for sharing it. In my opinion it really deserves a spot in the default contrib apps. regards, Simon > > -Gul > > On May 16, 2:26 am, simonbun <[EMAIL PROTECTED]> wrote: > > > 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 functionality would be the same as for django > > models. I know the pain for having to duplicate the functionality, but > > looks to me like a very useful feature nonetheless. > > > regards, > > Simon > > > On May 10, 4:04 pm, 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 > > > describe the framework as a whole. Google Code won't let me change the > > > URL from django-values, but I can change any of the rest of it once I > > > settle on a name. Any suggestions? > > > > -Gul > > > > On May 9, 10:48 pm, Gulopine <[EMAIL PROTECTED]> wrote: > > > > > 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.. > > > > >http://code.google.com/p/django-values/ > > > > > The syntax has changed a bit to incorporate some of the concerns that > > > > were raised. Values are provided on subclasses of a new class, > > > > values.Options. This class can then be instantiated either in the main > > > > module or in an individual module. A single declared Options class can > > > > be instantiated multiple times, even in multiple modules, and each > > > > instantiation will be able to store a different value. > > > > > The rest is mostly code cleanup, but it's much easier (for me) to work > > > > with now. So anyone with mroe ideas, feel free to bring them up! > > > > > -Gul > > > > > [1]http://groups.google.com/group/django-developers/browse_thread/thread... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
