Re: Dynamic Menus...
Hey! I saw you on a Google video! I feel like I'm talking to a celeb! :-) --Dave Jacob Kaplan-Moss wrote: On Aug 24, 2006, at 2:14 PM, mediumgrade wrote: Don't know if this is a Django question or not, but here is the situation: I am developing an application for a client who is a automobile broker. He wants agents to submit requests for vehicles from the web. The agent will be able to select the make/model of the vehicle. What I want is for the model menus to adjust dynamically depending on the make selected. For example, if the agent selects "Honda" I only the the models menu to show Civic, Accord, Element, ect. How can this be achieved? It's pretty much a _javascript_ thing; googling around for "_javascript_ select" or "dynamic select" should find something useful. FYI, you're likely to get much better responses if you post questions of this nature to django-users. django-developers is where we discuss developing Django itself; django-users is for questions about using Django. Thanks! 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: Validation Aware Models and django.forms on steroids
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. An example with a user registration form: user id: first name: last name: password: confirm password: Errors: - user id cannot be blank - user id already exists - password and confirmation do not match Warnings - first/last name not set - password blank - password shorter than suggested length And the logic I'll typically have is - if errors exist then redisplay form with errors and ask user to fix and resubmit - if no errors but some warnings, redisplay form with warnings and ask user to fix _or_confirm_save_with_warnings_ - if no errors and no warnings, just save as usual The reason I point this out is that I like to centralize the logic where the validation rules live - I don't want errors checked for in one place and warnings in another (as others have pointed out, I want ALL validation messages generated at once and then displayed in the form). 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). -Dave --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
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: 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 -~--~~~~--~~--~--~---
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: 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 -~--~~~~--~~--~--~---
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: 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 -~--~~~~--~~--~--~---
Re: SOC Integration Plan/Policy/Timeline
On Aug 25, 2006, at 11:29 AM, Linicks wrote: > Now that the "Summer Of Code" projects are complete, is there a > plan/policy/timeline for integrating these branches with Trunk? Nothing concrete, really. I imagine we'll take a few weeks to review what's been done (and give the students a chance to do a bit more hacking if they so desires) and figure out which parts will be merged, and which (if any) won't. I'd love anyone who's interested to take part in this. Please feel free to check out any of the branches and post some feedback to this list. Keep in constructive and polite, though, or Adrian'll sic his Ukranian Mafia connections on your ass. 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: 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: 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 -~--~~~~--~~--~--~---
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: db_index not creating indexes with syncdb
On 8/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: It looks like syncdb has a bug in that it doesn't create the indexes --at least on MySQL. You are correct (and it's not just with MySQL). This is a bug born of the way that syncdb installs applications. For some reason, it doesn't defer to install - it duplicates the install logic, but doesn't include indexes. I intend to refactor this code when I get into the installation of fixtures for the testing framework (#2333). However, if you want to ensure that this bug doesn't get missed, open a new ticket (do a quick search first to check that it isn't already logged). Yours,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: Bump again - #2333/Django testing framework
On Aug 25, 2006, at 8:21 PM, Russell Keith-Magee wrote: > 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? Funny, I was just playing with the patches earlier today, and was thinking about asking *you* where things stand. I missed much of the discussion between you and Malcom, but as far as I'm concerned it looks great and I'd "bless" you checking it in now. My only critique would be that there's no documentation of how to use your stuff to test Django apps. Even a quick howto would be super- useful. I'm sure I'll get around to writing one sooner or later, but if you've got the time that would rock. So, I'd say that -- unless Adrian thinks otherwise -- you're good to go. 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: 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 -~--~~~~--~~--~--~---
