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 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. I'm glad to see someone else is enjoying it! -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 -~----------~----~----~----~------~----~------~--~---
