Re: auto_name for newforms
On 8/22/07, james_027 <[EMAIL PROTECTED]> wrote: > while the auto_id features of newforms is more on dealing on the > client side, could it good to have auto_name feature also? To give you > an idea, I am dealing here with a master details form where in the > details part will compose of more than one same kind of form, which > the data could be differentiate thru their name attribute and not on > id ... Hi James, I don't quite understand what you're requesting...Could you give a more specific, detailed example? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django on jython (new version)?
On 8/24/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > It seems a JDBC/DB-API bridge is in order, but again, that seems like > a thing for the Jython distro. That's already distributed with Jython: http://www.jython.org/docs/zxjdbc.html > Then (I think) a single JDBC Django backend would do. No, you still need to manage the differences between SQL dialects. -- Leo Soto M. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django on jython (new version)?
On 8/23/07, Leo Soto M. <[EMAIL PROTECTED]> wrote: ... > That's easy to solve: Just copy optparse.py from the python 2.3 > distibution to the jython Lib directory. Odd; I thought it must be a C module, since Jython is under the Python license and it'd make a lot more sense for them to ship the module if it's pure python... ... > I'm working on a patch to get rid of those small problems. But I'm > pretty sure there are bigger ones. > It seems a JDBC/DB-API bridge is in order, but again, that seems like a thing for the Jython distro. Then (I think) a single JDBC Django backend would do. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django on jython (new version)?
On 8/23/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > > Oh wow, I hadn't noticed Jython 2.2 yet (I've been out of town)! I'm > wondering this myself, since my employer uses strictly Java, $ java -jar jython.jar -Dpython.path=/home/jeremwork/djtrunk ~/work/djtrunk/tests/runtests.py Traceback (innermost last): File "/Users/jeremy/work/djtrunk/tests/runtests.py", line 147, in ? ImportError: no module named optparse --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django moving from SVN to distributed VCS
On 8/23/07, Almad <[EMAIL PROTECTED]> wrote: > I'd like to ask if there is any possibility for moving django from SVN > to some distributed version control system. No, there is no possibility for moving Django from Subversion at this time. The benefits would not outweigh the downsides, which are (in an incomplete list): user confusion, unnecessary differences from familiar open-source practices and time/effort. This is one that I feel strongly about, so let's leave it be. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
django on jython (new version)?
Jython 2.2 was just released. This article claims it supports Python 2.2 and 2.3 language features. http://www.theserverside.com/news/thread.tss?thread_id=46661 http://www.jython.org/Project/download.html Does this mean I will finally be able to use Django in my stuffy corporate app server environment? If so, hot-diggety! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
GSoC 2007: Reusable Django applications
Hi,
After the official end on monday and two weeks without a real status
update on my GSoC project I'd like to share some thoughts and ideas
that came up during the summer. As a spoiler (or if you don't feel
like reading the big chunk of text below): I have not completed all of
my original project goals but will continue to work.
My initial GSoC application [1] was divided in:
1) Create code infrastructure to simplify the process of building
reusable Django applications, e.g. with egg files.
2) Build a public repository website for reusable Django applications.
Even if these two topics are connected in a way, I stumbled over the
rather different approaches to package management on a programming
language, operating system and community level. I evaluated the
package formats I knew to learn more about common package management
idioms (apt, rpm, gems, distutils, setuptools) and realized that
reinventing the wheel should be avoided - especially for a specific
product like Django; reusable Django apps should happen with something
stable and widely known, preferable without having to tie users to a
"simple", wrapped version of a sophisticated system.
So, giving the user the option to have an easy start with package
management was my first actual goal. I looked at the standard
distutils and the defacto standard setuptools and found the features I
needed: package management, dependency tracking, uploading and an easy-
to-distribute format - eggs. Hacking the setuptools code and cloning
the cheeseshop (PyPI) wasn't an option of course, so instead I
introduced a "release" metaphor (thanks for the idea Neil Blakey-
Milner) which holds the basic metadata for a reusable Django
application. It's basically a simple Python file which lives in the
application directory, gets loaded by setup.py and can be hand-edited
or even abandoned if not needed.
To facilitate the preparation of apps I added hooks to
dango.core.management (the refactored code too) to ask for the
metadata with "startapp" and made it the default (--noskeleton for the
current behaviour). It also creates skeleton files, builds a MANIFEST
file and gives the option to edit the release information later
("editapp"). The prepared apps can be uploaded to the PyPI or use
virtually any other function of setuptools. [2] (django.utils.package)
In the second part of my project I needed to bridge the gap between
the reusable Django apps and a to-be repository. Since I already used
setuptools (and PyPI) to create application packages, I decided to add
a keyword to any app (e.g. "django.apps") which later can be used to
identify the packages during a PyPI scan. With a little inspiration by
Jacob's project cheeserater.com I got this scan working in the days
before final evaluation. [3]
So now I'm on building the rest of the repository website, using
several of the django-* Google Code projects. If you have any ideas
for it, feel free to contact me. What about djangoapps.org?
James, thanks for your support and constant patience, I really learned
a lot this summer about programming and this crazy open source thing.
Seriously, you got one contributer more.
All the others, if you find the time, please have a look at my code
[2] and tell me if this all makes sense. My weblog [4] has some more
information about my summer of code, too.
Best
Jannis
1: http://jannisleidel.com/2007/03/gsoc-application/
2: http://code.google.com/p/django-package/
3: http://websushi.org/trac/browser/django-apps/
4: http://jannisleidel.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: delete-object, cascading
On 8/24/07, Gábor Farkas <[EMAIL PROTECTED]> wrote: > > or, to turn this into more constructive discussion, what's the preferred > thing to do, when someone does not get an answer to such a 'design > decision needed' mail? should he wait more than i waited before he > re-sends his question? how much? a month? i really do not know what is > the 'accepted' or 'patient' or 'nice' behavior in such cases... About |<>| that long :-) Seriously, there isn't really a fixed measure here. It depends very much on the activity in the list, and what else is going on. Generally speaking, a week is probably on the low end of an acceptable wait - but it depends a bit on what else is going on with django-developers. If there are a bunch of busy threads going on simultaneously, or there is a conference on, or people have announced that they will be on holiday or running silent for a bit, you would be well advised to wait a little longer. For the record - I didn't consider your email to be impolite/impatient - I just wanted to point out that the reason nobody answered was because we are all busy (a comment which is for the benefit of the general community as much as it is for you specifically). 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?hl=en -~--~~~~--~~--~--~---
Re: svn:ignore for new management package
On 8/23/07, John Shaffer <[EMAIL PROTECTED]> wrote: > > Thank you. There's one other directory that should be changed - > tests/regressiontests/test_client_regress has an svn:ignore of > "__init__.pyc", but actually includes several other files. Committed in [5994]. Thanks for the heads up. 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?hl=en -~--~~~~--~~--~--~---
Re: Django moving from SVN to distributed VCS
On 8/23/07, Honza Král <[EMAIL PROTECTED]> wrote: > Do you really need this? I am currently keeping my own two branches in > git repository, that I synchronize with the master svn repository. > > It is very simple to do and completely painless. As you said yourself > - since there are many conversion tools, nothing is stopping you from > running your own distributed copy of the repository. That's an n VS 1 situation. There are two reasons I could see for switching: 1) Making it easier for non-committers to provide quality patches. 2) Making it easier for users to cherry-pick patches and apply them uniformly across their various environments. Obviously, if the patch makes its way into trunk, it need not be manually managed. For the former, having to set everything up manually is another hurdle to making a submission. Some may view this as a weeding out process, which is fine. I personally am not going to bother mirroring trunk in a local repository. I would, however, use a sanctioned, public one. For the latter, it's probably not the responsibility of the devs. Indeed, it would appear to be symptomatic of a larger issue and the proper fix would be to apply patches in a timely fashion. That's not to say they're not right now -- I'm just painting a picture. So, in summary, depending on what the intent is, I think it naturally leads to a conclusion. I personally am a fan of distributed systems to encourage new contributions. I'm a member of one of the Apache projects and it annoys me as a developer to no end that we set up this extra hurdle for patch submissions. Of course, everyone has their own take on the matter ;-) -- Kevin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django moving from SVN to distributed VCS
Do you really need this? I am currently keeping my own two branches in git repository, that I synchronize with the master svn repository. It is very simple to do and completely painless. As you said yourself - since there are many conversion tools, nothing is stopping you from running your own distributed copy of the repository. On 8/23/07, Almad <[EMAIL PROTECTED]> wrote: > > Hi, > > I'd like to ask if there is any possibility for moving django from SVN > to some distributed version control system. > > Move would be painless (at least on Mecurial from my experience) as > there are converting tools (hgsvn), it works on almost all platforms, > there is a trac plugin (so tickets, wiki & co. would remain untouched) > and support for most IDEs. > > This change would make it easier for us mere users to use django that > is merged from mulitple branches. Also, it would make it easier to > contribute to django. > > I knew that there is mercurial mirror at http://hg.korpios.com/django.trunk/ > , but that is not allowing to gain from all features offered by > decentralized VCS. > > Is there any plan/chance on seeing this happen? > > Thanks, > > Almad > > > > > -- Honza Kr�l E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: delete-object, cascading
Russell Keith-Magee wrote: > On 8/23/07, Gábor Farkas <[EMAIL PROTECTED]> wrote: >> hi, >> >> i posted this one week ago, could someone with commit access please >> respond to it? > > If we're haven't addressed these tickets, it's not because we don't > want to - we have just had other priorities. Remember - we're all > volunteers. sure, i'm sorry if it seemed as being inpatient. i simply sent a reply to the mail to be sure that the topic is not forgotten or skipped-by-mistake. (so it was about my mail, not about those tickets) > As you correctly noted, you can already do what you proposed without > making any changes in trunk. You can override _collect_sub_objects or > delete() to implement whatever behaviour you want. to be correct, yes, i can do it, but it will be a hack (relying on an unpublished internal implementation-detail(that delete() calls _collect_sub_objects)), meaning i will have to read the diffs everytime django is updated to be sure it does not break my code (because i won't be able to rely on the backwards-incompatible-changes page in this case). > So - Feel free to work up the patch you describe and circulate it, but > I don't think it would be accepted to trunk. thanks, this was more what i wanted to know. > Alternatively, if you > want to take a serious swing at the ON DELETE issue, we would welcome > any contribution well, ON DELETE is a much larger topic than what i can handle currently, that's why i thought that perhaps simply making _collect_sub_objects public would allow the developers to customize the delete-behavior in a clean way. but if it's not the acceptable way, i can live with that. thanks again, and sorry if my response seemed inpatient. or, to turn this into more constructive discussion, what's the preferred thing to do, when someone does not get an answer to such a 'design decision needed' mail? should he wait more than i waited before he re-sends his question? how much? a month? i really do not know what is the 'accepted' or 'patient' or 'nice' behavior in such cases... gabor --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django moving from SVN to distributed VCS
Hi, I'd like to ask if there is any possibility for moving django from SVN to some distributed version control system. Move would be painless (at least on Mecurial from my experience) as there are converting tools (hgsvn), it works on almost all platforms, there is a trac plugin (so tickets, wiki & co. would remain untouched) and support for most IDEs. This change would make it easier for us mere users to use django that is merged from mulitple branches. Also, it would make it easier to contribute to django. I knew that there is mercurial mirror at http://hg.korpios.com/django.trunk/ , but that is not allowing to gain from all features offered by decentralized VCS. Is there any plan/chance on seeing this happen? Thanks, Almad --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: svn:ignore for new management package
On 8/23/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Thanks. I've added a few missing svn:ignore properties, including the > ones you mentioned, in [5993]. Thank you. There's one other directory that should be changed - tests/regressiontests/test_client_regress has an svn:ignore of "__init__.pyc", but actually includes several other files. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Admin and Related Models/Fields
I know the admin contrib package is getting a major overhaul right now as well as some of the query internals. So my question is, is there a patch coming soon where we will be able to include related fields of models in the admin columns as well as search sort and filter on them? If not, is it a good idea for me to start on functionality like this with the outstanding tickets currently. Trey --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: svn:ignore for new management package
On 8/23/07, Deryck Hodge <[EMAIL PROTECTED]> wrote: > > Hi, all. > > svn:ignore is not set for .pyc files on the new management package. I > know I can set my own global svn config, but since we do it for all > the rest of Django, I thought I would point it out. Thanks. I've added a few missing svn:ignore properties, including the ones you mentioned, in [5993]. 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?hl=en -~--~~~~--~~--~--~---
refactoring has_perm (and other permission stuff)
Hi, I am planning to rewrite the permission system in Django. Why? I am currently working a lot with ldap and use the auth_backend to auth users against the ldap-server. But working with permissions is somewhat painful, so I am planning to move the permission stuff to the auth_backend. I would implement it this way that user-obj.has_perm would remain as it is, but the has_perm method itself would call the auth_backends has_perm method like backend.has_perm(user-obj, 'can_vote'). This would mean that the whole source would remain backwards-compatible from what I can see... Is there something I would have to take care of and are you interested in something like it. Thx, Florian P.S.: The only backwards incompatible change to include would be renaming AUTHENTICATION_BACKENDS to AUTH_BACKENDS (as auth and auth are different ;) ) [but this is more cosmetic]. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: delete-object, cascading
hi, i posted this one week ago, could someone with commit access please respond to it? thanks, gabor Gábor Farkas wrote: > hi, > > when django deletes an object (using the object's delete() method), > then all related objects are also deleted. > > this is not always a good thing. > > there are various approaches to solve this, like: > > http://code.djangoproject.com/ticket/1007 > and > http://code.djangoproject.com/ticket/2288 > , > but they have been sitting there for a long time, and i don't think they > will be integrated anytime soon. > > so maybe a simpler solution would be able to solve most of the needs: > > a non-recursive (non-cascading) delete-method. > > as far as i can understand the code, the recursive-delete works like this: > > 1. collect all the objects to be deleted (using Model._collect_sub_objects) > > 2. and then delete them using models.delete_objects > > this proposed non-recursive delete would: > > 1. the same as the previous step #1 > > 2. if step #1 returned more than one object, raise an exception. > otherwise delete the object > > would this be acceptable? > > actually, this can be implemented without changing django (i can simply > call into Model._collect_sub_objects, and see how many objects it > returns), but that means i am calling undocumented private methods, > which is not that nice. so maybe, even if my proposed solution is not > acceptable, would it be possible, to make Model._collect_sub_objects > into a normal, non-private method? so that at least i can be safe, that > an internal change won't break my code? > > so, in short: > > two proposals/possibilities: > > 1. create a non-recursive delete-method (either by adding a > boolean-argument to Model.delete(), or by creating a new method) > > 2. make Model._collect_sub_objects into a documented non-private method. > > would any of these be suitable? if yes, i can create a patch for it, but > first i wanted to make sure that there's a chance for it to get accepted. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Using MySQL replication
On 8/22/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > I am now at the prospect of using a MySQL database in the form of a > 2-machine master-slave cluster. If I understand things right this > requires Django to actually know which queries should be directed to > which host, i.e. writes on master, reads on both master and slave. > > I'm about to start thinking of what changes are required to Django's > backends, how the choosing itself can be implemented (as view decorators > or middleware). The recent django.db.backends refactoring we've done goes a long way in helping make this happen. I think Brian Harring is working on this sort of multiple-DB support, if I understand correctly. -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: proposal: update QuerySet.get() to return a default if object does not exist?
On 8/22/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > So - I would suggest holding off for a week or two (to let the dust > settle on the refactor), and then poke this issue again. For the > record, I think the general idea has merit, we just need to finess > some details. Yeah, we should wait until the query.py refactoring is done, but I'm +1 on this change. It's a pain to have to wrap things in try/excepts all of the time. Of the options Rob pointed out, I prefer the last -- giving the get() method an optional "default" parameter, instead of creating new methods like get_or_default() or get_or_none(). We can easily get around the fact that it clashes with fields named "default" -- if you have a field named "default" and want to do an exact lookup, just use "default__exact" instead of "default". That seems like a reasonable solution. This would be backwards-incompatible for anybody who currently has a field named "default" and does an exact lookup. But I think that's OK, as long as we document it and get the word out. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
