Re: Validation Aware Models and django.forms on steroids
On 8/25/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > > The whole raising a Form thing is just a shocking idea. > > Which, right there, is what I'm opposed to it. Often there's a reason > why things are usually done one way, and I don't want to break from > the standard way of using exceptions. Having a function raise a Form > object as an exception is just strange (to me, at least), and > strangeness is *not* what I'm looking for in form processing. Yeah, and that's fine. Personally, I'm weary of any objection that can cite no other reason but that it is "strange"; many good ideas have been destroyed that way. But whatever, really I'm not pushing the form-exception at all. What I am pushing for is clean and simple api usage for the developer. But what I'm seeing so far is pretty good. If what you say follows. However, many of the details here are still missing. Like how exactly are objects assigned to this Form so that it knows to use the correct validate(), and how to save() the object. And what about Forms that are complex and deal with more than one object, not just one that is inlined? Also, I'm still hazy on how the set_defaults / get_defaults works exactly. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Bump again - #2333/Django testing framework
Hi all,Sorry to be the squeaky hinge here, but is anyone looking at the testing framework patches associated with #2333?At last count, I believe Malcolm was happy with the patches as they stand; however, I'm still looking other comments, plus a blessing from a higher power before I commit anything and move onto the next phase in this work. I get the impression that Adrian and Jacob have been pretty busy of late, but as of this week, they both seem to be back with a vengance - Guys? Any comments? Am I good to go?Thanks,Russ Magee %-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
On Aug 24, 2006, at 2:21 PM, Brantley Harris wrote: > > The whole raising a Form thing is just a shocking idea. +1 At first, I really digged this raising a Form, but then I realized that it is just returning a value, but too cleverly... 1. It feels like a goto is happening (execution jumping in an unusal path) 2. It abuses raise as a replacement for a return and a try...except as a replacement for an if-statement 3. It makes the return value strongly typed (you have to raise a Form object) 4. Form becomes a sub-class of Exception (yuch) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
[Pulling together quotes from a few messages] On Aug 24, 2006, at 2:21 PM, Brantley Harris wrote: > My problem with Joseph's proposal is that I believe it to be too tied > to the concept of the Model. Idealy, the Form/Manipulator should not > really have anything to do with a Model, except perhaps in the > finalization, like in .save(). The way I read it, it doesn't -- a Form can delegate to a model for validation and saving, but doesn't have to. > Also it doesn't end up actually leveraging model-validation. You'd > have to define the validation twice, once in the Model, and then once > in Field. But leveraging on the Model validation turns out to be > rather tricky anyway, even in my proposal. Again, the way I see it would be that Form.validate() would delegate to Model.validate(), iff that Form represents a Model. For custom forms, validate() would delegate differently. Or am I missing something? > The whole raising a Form thing is just a shocking idea. Which, right there, is what I'm opposed to it. Often there's a reason why things are usually done one way, and I don't want to break from the standard way of using exceptions. Having a function raise a Form object as an exception is just strange (to me, at least), and strangeness is *not* what I'm looking for in form processing. On Aug 25, 2006, at 7:04 AM, DavidA wrote: > One comment on ValidationErrors: When I've done these types of things > in the past, I've typically returned two levels of validations > messages: warnings and errors. An error indicates that the attempted > save will fail (i.e. it would either cause a an object to be saved in > an invalid state or it would violate a DB constraint and throw an > exception in the backend). A warning would not result in a failure but > is still worthy of notifying the user, but there are cases where > its OK > so its not identified as an error. Yes! This is something that I forgot about -- we've wanted to add validation warnings to Django as long as I can remember. > So I'd suggest a ValidationException that has an errors dict, a > warnings dict and possibly a form (or a very easy way to create a form > from the exception). This sounds like a reasonable idea to me... Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Modular Django
On Aug 25, 2006, at 4:34 PM, lugal wrote: > For a personal project, I modified Django's urlresolvers module to > make > it into a piece of WSGI middleware. I liked Django-style URL > dispatching but I didn't need the whole framework. That's cool -- mind posting your code somewhere? > 1) Develop a loosely coupled module that acts like the "usual" Python > module > 2) Develop a piece of WSGI middleware > 3) Something else > > I'm curious where Django modularity is going in the future, all things > remaining equal. Personally, I would lean towards #1, but since Django modularity isn't an itch I have, chances are someone with a more pressing need will beat me to it. Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Modular Django
For a personal project, I modified Django's urlresolvers module to make it into a piece of WSGI middleware. I liked Django-style URL dispatching but I didn't need the whole framework. >From that experience, I can see at least a few ways to modularize Django components: 1) Develop a loosely coupled module that acts like the "usual" Python module 2) Develop a piece of WSGI middleware 3) Something else I'm curious where Django modularity is going in the future, all things remaining equal. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: I18N+Database Problem
AFAIK, django's i18n support is mainly for static strings in the code and templates. For keeping multiple translations of database content, you'll need something more. This might work for you: http://trac.studioquattro.biz/djangoutils/wiki/TranslationService I also started working on a translation service app last night. I'll share it if it turns into anything usefully :-) MWM --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
SOC Integration Plan/Policy/Timeline
Now that the "Summer Of Code" projects are complete, is there a plan/policy/timeline for integrating these branches with Trunk? Thanks! --Nick --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Dynamic Menus...
Take a look at the js option (http://www.djangoproject.com/documentation/model_api/). --Nick --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: BigIntegerField
I have wanted this as a built in "Type" for some time. I usually just do some manual SQL to alter the columbs that I need to be "Big Integers", but it would be nice to have them built in, especially for the default row id created for each table. Hopefully this will make its way into the trunck sometime soon. --Nick --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django unicode-conversion, beginning
Hi gabor, I've put up some patches to help with the unicode conversion of django. We have a site which is shortly going to production where we actually have to handle multiple unicode scripts including some which have characters that do not fall into iso-8859-1. Since I'm pretty lazy and I'm not really interested in maintaining my own set of unicode patches against django forever - I'm *very* interested in helping with any effort to get Django to support unicode. Adrian - can we get that branch opened up soon? vic On 8/21/06, gabor <[EMAIL PROTECTED]> wrote: > > Adrian Holovaty wrote: > > On 8/8/06, gabor <[EMAIL PROTECTED]> wrote: > >> i think unicodizing django can be done in 4 easily separated steps/parts: > >> > >> 1. request/response > >> 2. templating-system > >> 3. database-system > >> 4. "overall unicode-conversion". this is mostly about replacing > >> bytestrings with u"bla" in the code, and switching __str__ to __unicode__ > >> > >> my biggest problem currently is, that i do not know how to continue... > >> should i just write more and more patches to increase the > >> "unicode-coverage" to more parts of django? or maybe a more coordinated > >> approach would be better? > > > > Hey gabor, > > > > Sorry for the slow response on this -- I'm just now wading through a > > couple of weeks' worth of django-users and django-developers messages. > > This patch is a great step forward! > > > > Are you interested in a Subversion branch devoted to Unicoding Django? > > Let me know... > > > > (to make sure my original response is not caught up in a spam-filter or > such, sending this to the list too) > > > hi, > > > yes, i'm interested :) > > cannot really promise how long it will take to convert the whole django > to unicode, but will try. it's not hard. as i wrote, the changes are > simple, it's just that many changes have to be done. > > > thanks, > gabor > > > > -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
