Re: Looking up into an ordered list... A new feature?

[Honza Král]

On 1/23/07, Yann VR <[EMAIL PROTECTED]> wrote:
>
> How to achieve to search within a list of id that have been
> sorted in a precise way?

you have to sort it yourself

>
> the __in lookup tag will automatically reorder the list
> by ascendancy (and I reckon in_bulk does the same too).
>
> I have a list where items are ordered by rate (which is
> not a field of the same table) and giving the ordered list using the
> __in
> keyword will undo this order.

that is because of the way this is processed - it is translated as
SELECT * FROM table WHERE id IN ( 1,2,3 )
and that doesn't mean that the order will be kept...

you have to sort the list in python afterwards if you want some exact
ordering that cannot be achieved via normal .order_by()

>
> Is there any way to achieve this? I am posting here because I
> believe this is a new feature for which I'm likely to submit a ticket
> as I know some other folks looking for it already.
>
>
> >
>


-- 
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: Encouraging contributed documentation

[Aidas Bendoraitis]

+1 for both suggestions:
a) Combined documentation for filling all the gaps. Actually, existing
wiki (code.djangoproject.com) could be used.
b) Django documentation in CHM format. CHM can be used on Mac OS X
(Chmox) and Linux (xCHM) as well as on Windows and it is very
convenient (Personally, I prefer the index of all main entities and
keywords pointing to appropriate help pages).

Regards,
Aidas Bendoraitis aka Archatas



On 1/24/07, Vadim Macagon <[EMAIL PROTECTED]> wrote:
>
> +1
>
> I'd also like to see a script that generates a CHM (Compiled HTML Help)
> from the official Django ReST docs. The CHM could then be included as
> part of the installer-based release for Windows users. One of these days
> I'll probably get fed up waiting for the pages on djangoproject.com to
> load and write the damn script myself, unless someone beats me to it :)
>
>
> -+ enlight +-
>
> >
>

--~--~-~--~~~---~--~~
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 properties ?

[Michael Radziej]

Hi,

keyword expansion might be a good idea for a single file with the
only purpose to make the svn release number available. Then you
could really find out whether someone is using a current or a rather
old release. +1 for this, -1 for using keyword expansion for all files.

Michael

-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100

http://www.noris.de - The IT-Outsourcing Company

--~--~-~--~~~---~--~~
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: Encouraging contributed documentation

[Marc Fargas Esteve]

Hi,
Answering inline.

On 1/24/07, James Bennett <[EMAIL PROTECTED]> wrote:
> So I'd like to propose that we draw up some guidelines for
> contributing documentation for Django, and begin encouraging
> documentation contributions just as much as we encourage code
> contributions.
+1 !

> Maybe we could even choose some of the more prolific bloggers to form
> an official documentation team and work on filling in the gaps and
> maintaining the docs we already have? That'd also help take some of
> the burden off the core dev team, who currently maintain both the code
> and the documentation :)
+1 ! They could even fill bugs about documentation errors so
volunteers can help to fix them.

I'd also ask everybody to fill bug reports when they find inconsistent
or outdated documentation on the docs ;)

Cheers,
Marc

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Looking for Online Jops !!

[Lucy]

*Hello, *
*   Unlock the secrets to finding work you need to create a high
six-figure income working from home in just three weeks . Learn how to quit
your boring day job and start earning REAL money working for yourself .
Interested candidates can apply online.*
**
***http://clipurl.com/?EMC327* 

*Best Regards*


-- 
See Our Magic , You Will Be Surprised

  http://www.mediamall.tk

--~--~-~--~~~---~--~~
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: Encouraging contributed documentation

[Philipp Keller]

> So I'd like to propose that we draw up some guidelines for
> contributing documentation for Django, and begin encouraging
> documentation contributions just as much as we encourage code
> contributions.

I'm not 100% sure this is the right direction.
As I found out there's lacking documentation in newforms I digged into the 
django code and figured it out and set up a little tutorial.
The barrier would have been much higher if I had to write official 
documentation. Additionally bloggers (as me) want to publish on their own 
sites: to increase traffic, get comments, get in touch with other users, etc..

I would rather encourage users to post their documentation wherever and let 
them add a comment on a corresponding documentation site.
Later on, someone would ask such a poster if his post may be used for official 
documentation and if he would be willing to incorporate the doc to the official 
doc.

Granted, I've got the bloggers view on this :-)

greets
Philipp


> There's an awful lot of really good documentation floating around on
> other sites, some of which goes beyond anything covered in the
> official docs. That's always bugged me (even though I'm just as guilty
> as a lot of people when it comes to writing about Django and keeping
> it on my own site), because it carries two disadvantages:
> 
> 1. It fragments documentation and detracts from having a "one-stop
> shop" for information about Django -- every time we have to refer
> somebody to information that's only on someone else's site, we're
> simultaneously pointing out a failure in our documentation.
> 
> 2. It comes at a risk; links have a tendency to rot over time, and if
> a useful tutorial or blog entry goes to the great 404 in the sky one
> day it'll hurt Django as a whole.
> 
> So I'd like to propose that we draw up some guidelines for
> contributing documentation for Django, and begin encouraging
> documentation contributions just as much as we encourage code
> contributions.
> 
> The requirement to supply documentation with patches which add new
> functionality is a good start, but there's still quite a bit of
> existing functionality that has no official documentation (the
> dispatcher, for example). The community aggregator has shown time and
> again that there are plenty of people out there who are willing and
> able to provide good write-ups of functionality we haven't yet
> documented officially (and to point out any errors in things we have
> documented), so I think we should do our best to work with them on
> getting that information into the official docs.
> 
> Maybe we could even choose some of the more prolific bloggers to form
> an official documentation team and work on filling in the gaps and
> maintaining the docs we already have? That'd also help take some of
> the burden off the core dev team, who currently maintain both the code
> and the documentation :)
> 
> -- 
> "Bureaucrat Conrad, you are technically correct -- the best kind of correct."
> 
> > 
> 

--~--~-~--~~~---~--~~
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: Why does the admin app tie directly to models?

[Nate Straz]

On Tue, Jan 23, 2007 at 11:47:08PM -0600, Jacob Kaplan-Moss wrote:
> On 1/23/07 9:16 PM, Nate Straz wrote:
> > Why does the admin app tie directly to models?  Why not applications?
> 
> Because sometimes you want certain models within in app *not* to be 
> admin-editable.

Okay, there's a clue that sometimes customization is needed.  I'll
continue expanding on my idea.

What if the admin app was really an admin framework inside Django?  It
could provide a base admin sub-app that applications could extend.  That
would allow apps to easily add new views to the admin app.

I think it would plug into the urls.py in django.contrib.admin like
this:

  ('^([^/]+)/(?:(.+)/)?$', 'django.contrib.admin.views.main.app_admin')

def app_admin(request, app_label, rest_of_url):
# import admin urlpatterns from app
# continue resolving url with new patterns


Inside app/admin.py:

from django.contrib.admin import AdminApp
from app.models import Foo, Bar

myadminapp = AdminApp(models = (Foo, Bar))
urlpatterns = myadminapp.patterns()


How does that sound for a new direction?

Nate

--~--~-~--~~~---~--~~
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: Encouraging contributed documentation

[Michael Radziej]

Philipp Keller:
>> So I'd like to propose that we draw up some guidelines for
>> contributing documentation for Django, and begin encouraging
>> documentation contributions just as much as we encourage code
>> contributions.
> 
> I'm not 100% sure this is the right direction.
> As I found out there's lacking documentation in newforms I digged into the 
> django code and figured it out and set up a little tutorial.
> The barrier would have been much higher if I had to write official 
> documentation. Additionally bloggers (as me) want to publish on their own 
> sites: to increase traffic, get comments, get in touch with other users, etc..
> 
> I would rather encourage users to post their documentation wherever and let 
> them add a comment on a corresponding documentation site.
> Later on, someone would ask such a poster if his post may be used for 
> official documentation and if he would be willing to incorporate the doc to 
> the official doc.

What about filing a ticket that says "I've put some documentation on
... on ..." Someone else could then build a patch to include the
text in the docs. I think that for docs separating these two stages
works better than for code. And for the blogger it's an additional
link to his/her blog, so they have an interest to make the ticket.

When I look at the tickets, I often see that the ability to make a
patch does not come out of thin air, and perhaps people who write
good docs are not always used to working with patches.

> Granted, I've got the bloggers view on this :-)

Well, as this involves you bloggers, I guess your point of view is
essential here!

Michael

-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100

http://www.noris.de - The IT-Outsourcing Company

--~--~-~--~~~---~--~~
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: Encouraging contributed documentation

[[EMAIL PROTECTED]]

I wholeheartedly agree. When I was new to Django, I had a very
difficult time moving forward where the four "official" tutorials left
off. I've always admired people that could learn a system by sitting
down with the docs or pouring through the source - unfortuantely, I'm
not one of them. Seeing code in the context of an app or project helps
me more that doc pages. (No discredit to the fantastic Django
documentation, it's some of the best I've ever seen) Having the Django
Book available as of late has also been an incredible help.

Most of my early learing time was spent reverse engineering other
people's apps and trying to assimilate disparate pieces of information
into something workable. (Especially for concepts like user
registration and commenting which the documentation was sparse on)
Finding Jeff Croft's Lost Theories code was like discovering the
Rosetta Stone; I had a live, working site online with accompanying
source code.

I'd like to see a place where code samples are provided in a consistent
format, perhaps in the manner of O'Reilly's 'Cookbook' series.
(Problem, Solution, Discussion, See Also, etc.) Being able to search
this information, or drill down through specific Django concepts (i.e.
pagination, caching, generic views) with usage examples would be
helpful. The Symfony project has a nice "24 days with Askeet" section
(http://www.symfony-project.com/askeet) that does a great job of
walking a new user through an entire application.

I'd be curious to see what other people thought, but I think the
YUI-EXT commenting system could be used on cookbook 'recipe' pages.
This would give newbies the ability to ask "Why did you do this
specific code block this way..." and would really help out people that
get lost in the tutorials (I've been there). This would also give
experienced people the ability to suggest alternative ways to phrase
code or suggest improvements. I thought about trying it out, but I
haven't been able to figure out the Yahoo libraries yet.

I'm not a prolific blogger but I'd like to find ways to contribute to
the community - definitely +1 on the effort.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Prefix for URLs?

[vfoley]

Hello,

one thing that bugs me about URL patterns is that you can specify a
prefix only for the view functions to call, not for the URLs to match.
A quick example

web request:
http://localhost/project/view/1/

urls.py:
urlpatterns = patterns('', (r'^view/(?P\d+)/$',
'myproject.myapp.views.view'),)

The client will get a 404, because 'project/view/1/' isn't matched.
Now, I could add project to all my regular expressions, but that seems
like a whole lot of repetition.  Instead, could we have another
parameter for patterns() that would trim this part off the passed URL?
Example:

urls.py:
urlpatterns = patterns('', prefix_url='project/',
(r'^view/(?P\d+)/$', 'myproject.myapp.views.view'),)

And the previous URL would now work.  If this is something that could
be useful and that is not currently being worked on, I could try my
hand at modifying the relevant functions and classes.  Due to the risk
of breaking older applications, this could be another function.

Vincent


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

All tickets go to jacob

[Marc Fargas Esteve]

All new tickets being opened on TRAC are assigned to jacob, not sure
if it's to be this way but if it isn't, then you know it's happening!
;)

Maybe get the field empty unless somebody assigns it or set it to "anonymous" :)

--~--~-~--~~~---~--~~
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: Prefix for URLs?

[Robert Myers]

On 1/24/07, vfoley <[EMAIL PROTECTED]> wrote:
>
>
> Hello,
>
> one thing that bugs me about URL patterns is that you can specify a
> prefix only for the view functions to call, not for the URLs to match.
> A quick example
>
> web request:
> http://localhost/project/view/1/
>
> urls.py:
> urlpatterns = patterns('', (r'^view/(?P\d+)/$',
> 'myproject.myapp.views.view'),)
>
> The client will get a 404, because 'project/view/1/' isn't matched.
> Now, I could add project to all my regular expressions, but that seems
> like a whole lot of repetition.  Instead, could we have another
> parameter for patterns() that would trim this part off the passed URL?
> Example:
>
> urls.py:
> urlpatterns = patterns('', prefix_url='project/',
> (r'^view/(?P\d+)/$', 'myproject.myapp.views.view'),)


You can do that by using the include function:

(r'^project/', include('project.app.my_urls')),

Then just place my_urls.py in your project directory. You can name it
anything you want.

Robert


And the previous URL would now work.  If this is something that could
> be useful and that is not currently being worked on, I could try my
> hand at modifying the relevant functions and classes.  Due to the risk
> of breaking older applications, this could be another function.
>
> Vincent
>
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

No. <-- Re: All tickets go to jacob

[Michael Radziej]

Marc Fargas Esteve:
> All new tickets being opened on TRAC are assigned to jacob, not sure
> if it's to be this way but if it isn't, then you know it's happening!

No, they don't. It depends on the selected component.

Michael

-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100

http://www.noris.de - The IT-Outsourcing Company

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

triage: one third done

[Michael Radziej]

Hi,

just to give you an idea how fast we proceed: currently 228 out of
655 open tickets have been reviewed, and that does not count all
those that got closed during triage! Isn't that nice?

Michael


-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100

http://www.noris.de - The IT-Outsourcing Company

--~--~-~--~~~---~--~~
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: No. <-- Re: All tickets go to jacob

[Marc Fargas Esteve]

Thanks for the info!

On 1/24/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> Marc Fargas Esteve:
> > All new tickets being opened on TRAC are assigned to jacob, not sure
> > if it's to be this way but if it isn't, then you know it's happening!
>
> No, they don't. It depends on the selected component.
>
> Michael
>
> --
> noris network AG - Deutschherrnstra�e 15-19 - D-90429 N�rnberg -
> Tel +49-911-9352-0 - Fax +49-911-9352-100
>
> http://www.noris.de - The IT-Outsourcing Company
>
> >
>

--~--~-~--~~~---~--~~
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: triage: one third done

[Jeremy Dunck]

On 1/24/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> just to give you an idea how fast we proceed: currently 228 out of
> 655 open tickets have been reviewed, and that does not count all
> those that got closed during triage! Isn't that nice?

Huzzah!

--~--~-~--~~~---~--~~
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: triage: one third done

[Adrian Holovaty]

On 1/24/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> just to give you an idea how fast we proceed: currently 228 out of
> 655 open tickets have been reviewed, and that does not count all
> those that got closed during triage! Isn't that nice?

Keep up the fantastic work, guys!

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
-~--~~~~--~~--~--~---

multi-db branch: looking for a new maintainer

[JP]

Hi all,

I'm afraid that I am not going to have time in the future to continue
maintaining and merging up the multi-db branch. It's diverged so far
from trunk that any trunk change that touches management.py or models
results in hours of hand-merging and svn detective work... hours that I
just don't have to give right now.

I'd hate to see the branch die, since I think it will be of use to
people, so I'm hoping that someone else will step forward to take over
ownership, until such a time as the branch is reviewed and merged or
rejected. Of course I'll be more than happy to help the new maintainer
get up to speed on the changes and new features in the branch, and will
always be available to answer questions about it -- as much as time
allows anyway. :)

Any takers?

JP


--~--~-~--~~~---~--~~
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: triage: one third done

[Marc Fargas Esteve]

Really nice work, congratulations! ;)

On 1/24/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> just to give you an idea how fast we proceed: currently 228 out of
> 655 open tickets have been reviewed, and that does not count all
> those that got closed during triage! Isn't that nice?
>
> Michael
>
>
> --
> noris network AG - Deutschherrnstra�e 15-19 - D-90429 N�rnberg -
> Tel +49-911-9352-0 - Fax +49-911-9352-100
>
> http://www.noris.de - The IT-Outsourcing Company
>
> >
>

--~--~-~--~~~---~--~~
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: Prefix for URLs?

[Gary Wilson]

On Jan 24, 11:03 am, "vfoley" <[EMAIL PROTECTED]> wrote:
> one thing that bugs me about URL patterns is that you can specify a
> prefix only for the view functions to call, not for the URLs to match.
[snip]
> urls.py:
> urlpatterns = patterns('', prefix_url='project/',
> (r'^view/(?P\d+)/$', 'myproject.myapp.views.view'),)

This has bugged me before too, as I wanted to remove the regex
duplication from my url patterns without having to put them in a
seperate file.  I remember making a regexpatterns() function that
simply returned a list of tuples to extend urlpatterns.  The syntax was
almost exactly what you gave here in your example.  I can't seem to
find that bit of code I wrote, but it would be very simple to reproduce.


--~--~-~--~~~---~--~~
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: extending the user model

[Gary Wilson]

On Jan 20, 10:00 am, "Joseph Perla" <[EMAIL PROTECTED]> wrote:
> Have you already decided on a simple, fast, non-deprecated, standard way of
> extending the User model?

This has been talked about a few times, but nothing concrete yet.  I
think one of the more popular ideas was to create a user interface for
custom user models to adhere to.  So you could have whatever
fields/methods you wanted in your model as long as it adheres to the
interface.  Then we could possibly have a setting like:

USER_MODEL = 'myapp.models.myuser'


--~--~-~--~~~---~--~~
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: triage: one third done

[Gary Wilson]

On Jan 24, 2:50 pm, "Marc Fargas Esteve" <[EMAIL PROTECTED]> wrote:
> Really nice work, congratulations! ;)

Yes, good work everyone!  It at least appears that there is more
activity in the ticket system now ;)


--~--~-~--~~~---~--~~
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: Encouraging contributed documentation

[[EMAIL PROTECTED]]

We have a section of the wiki listing tutorials etc here:
http://code.djangoproject.com/wiki/DjangoResources

Why don't we just spin that off into a new page, categorise things
(e.g. Forms, building-a-blog, simple tutorials, misc. etc) and let
people add their own to that page. This way the bloggers get linkage,
and credt, and we get to have a handy page helping users. If there are
really good ones we can then ask the writer if they could be included -
recent ones that come to my mind here are Jeff Croft's MTV article, and
there's a few on that B-List page written by some guy :)

Personally, I think the Django-Powered-Sites list should go to another
page on the wiki (DjangoSites?) and we keep the resources page for
tutorials. The CookBook idea is also good - there's plenty of example
apps out there, we just need to have a page for it and keep it
maintained.

-Simon


--~--~-~--~~~---~--~~
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: extending the user model

[James Bennett]

On 1/24/07, Gary Wilson <[EMAIL PROTECTED]> wrote:
> This has been talked about a few times, but nothing concrete yet.  I
> think one of the more popular ideas was to create a user interface for
> custom user models to adhere to.  So you could have whatever
> fields/methods you wanted in your model as long as it adheres to the
> interface.  Then we could possibly have a setting like:

AUTH_PROFILE_MODULE is still the standard and, since it's been written
up in the book, likely to remain so. See "Profiles" near the bottom of
Chapter 12:

http://www.djangobook.com/en/beta/chapter12/


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

triage: Which "state" for #3279

[Marc Fargas Esteve]

Hi,
In the nice graphic on
http://www.djangoproject.com/documentation/contributing/#ticket-triage
#3279 would go from "Unreviewed" to the left to "worksforme" as the
resolution, but what Triage State would it get? "Unreviewed" is not
true, as it has been reviewed, but it's not "Accepted" either (at
least if we follow the "The ticket is a bug")

Any suggestion on which state to set for tickets closed as
wontfix/invalid and some "worksforme" ? Maybe we can get the
"Rejected" or "Invalid" states for those cases.

Marc.

--~--~-~--~~~---~--~~
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: triage: one third done

[Russell Keith-Magee]

On 1/25/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> just to give you an idea how fast we proceed: currently 228 out of
> 655 open tickets have been reviewed, and that does not count all
> those that got closed during triage! Isn't that nice?

Magnificent stuff, guys! You're all doing superb work, here.

Here's to knocking off the remaining 367 tickets in short order.

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: triage: Which "state" for #3279

[Michael Radziej]

Hi Marc!

Marc Fargas Esteve:
> Hi,
> In the nice graphic on
> http://www.djangoproject.com/documentation/contributing/#ticket-triage
> #3279 would go from "Unreviewed" to the left to "worksforme" as the
> resolution, but what Triage State would it get? "Unreviewed" is not
> true, as it has been reviewed, but it's not "Accepted" either (at
> least if we follow the "The ticket is a bug")

This ticket is a bad example. It should be open, and it is only
closed since reopen does currently not work.

When a ticket is "really closed", then the Triage State does not
matter. Closed tickets simply will not get looked at (except by some
one who is looking for an old bug).

Hope that makes it clear.


Cheers,

Michael


-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100

http://www.noris.de - The IT-Outsourcing Company

--~--~-~--~~~---~--~~
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: triage: Which "state" for #3279

[Marc Fargas Esteve]

Thanks Michael for the explanation, I took the ticket as example until
you pointed me to comment #9 :)

Cheers,
Marc.

On 1/25/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
[...]
> This ticket is a bad example. It should be open, and it is only
> closed since reopen does currently not work.
>
> When a ticket is "really closed", then the Triage State does not
> matter. Closed tickets simply will not get looked at (except by some
> one who is looking for an old bug).
[...]

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

calling attention to #639

[Gary Wilson]

"For models with file fields (FileField/ImageField etc.) save() is
called twice on manipulator form submission"

Possibly causing duplicate objects to be created in the database.


--~--~-~--~~~---~--~~
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: calling attention to #639

[Gary Wilson]

link for the lazy:
http://code.djangoproject.com/ticket/639


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

does locmem cache backend need to use copy.deepcopy()?

[Gary Wilson]

see http://code.djangoproject.com/ticket/3012


--~--~-~--~~~---~--~~
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 properties ?

[Sean Perry]

On Jan 23, 2007, at 10:45 PM, Russell Keith-Magee wrote:

>
> On 1/24/07, Sean Perry <[EMAIL PROTECTED]> wrote:
>> I could care less about most of the keywords. However, having Rev or
>> Id set is handy for the sysadmin down the road trying to figure out
>> where the bug came from.
>
> Isn't that what `svn blame` is for?
>
> Count me -1 on keywords expansion, too.
>

Yes, but ONLY if you have a svn checkout. Forgive me for not being  
clear. Having a id or rev is handy if at sometime a sysadmin has a  
file on his system but does not know for sure which version / release  
it came from.

For example, admin A finds out about Django downloads a tarball /  
checks out svn. He installs it to /usr/local/blah and writes some web  
apps. At some point in the future admin B has to find out why an app  
is not working and it turns out to be a Django bug. How does he know  
where /usr/local/blah/django/broken.py came from? Is it 0.91? 0.95? 1.1?


--~--~-~--~~~---~--~~
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 properties ?

[Russell Keith-Magee]

On 1/25/07, Sean Perry <[EMAIL PROTECTED]> wrote:
>
> For example, admin A finds out about Django downloads a tarball /
> checks out svn. He installs it to /usr/local/blah and writes some web
> apps. At some point in the future admin B has to find out why an app
> is not working and it turns out to be a Django bug. How does he know
> where /usr/local/blah/django/broken.py came from? Is it 0.91? 0.95? 1.1?

By looking at /usr/local/blah/django/__init__.py. This contains the
version number for the Django install.

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: multi-db branch: looking for a new maintainer

[[EMAIL PROTECTED]]

Just wanted to put a note on here...that there are people actively
using this branch.  I've been using it since the beginning of
December...and have found it to work fantastically... ( well I did send
JP a bug report today ... with a sample project ... when he told me
this news ).

I do hope in the future to be able to pitch in on this branch and help
out ( I did submit a how-to dock in the wiki) ...but am under some
serious deadlines right now... so also wouldn't be able to devote the
time needed to fully understand everything quickly to take it over...
until I meet some deadlines in Feb/March

At any rate...I did want to chime in and thank JP for his help when I
was getting started...and tell him that this branch of the project is
great!!

On Jan 24, 3:50 pm, "JP" <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm afraid that I am not going to have time in the future to continue
> maintaining and merging up themulti-dbbranch. It's diverged so far
> from trunk that any trunk change that touches management.py or models
> results in hours of hand-merging and svn detective work... hours that I
> just don't have to give right now.
>
> I'd hate to see the branch die, since I think it will be of use to
> people, so I'm hoping that someone else will step forward to take over
> ownership, until such a time as the branch is reviewed and merged or
> rejected. Of course I'll be more than happy to help the new maintainer
> get up to speed on the changes and new features in the branch, and will
> always be available to answer questions about it -- as much as time
> allows anyway. :)
> 
> Any takers?
> 
> JP


--~--~-~--~~~---~--~~
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 properties ?

[Don Arbow]

On Jan 24, 2007, at 8:06 PM, Russell Keith-Magee wrote:
> On 1/25/07, Sean Perry <[EMAIL PROTECTED]> wrote:
>>
>> For example, admin A finds out about Django downloads a tarball /
>> checks out svn. He installs it to /usr/local/blah and writes some web
>> apps. At some point in the future admin B has to find out why an app
>> is not working and it turns out to be a Django bug. How does he know
>> where /usr/local/blah/django/broken.py came from? Is it 0.91?  
>> 0.95? 1.1?
>
> By looking at /usr/local/blah/django/__init__.py. This contains the
> version number for the Django install.



When I import a version of Django from the repository, I put a file  
in the top level of the django directory that tells me what changeset  
was checked out:

touch chngset.3499

Of course I'm not checking out daily builds so it's fairly easy. If I  
was syncing every day, I'd write a script to do the syncing and put  
the changeset file creation in there as well.

And you could always create a local mirror of Django's repository  
(which you could sync daily) and put your own svn properties in there.

Don


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

newforms - dynamic construction of a Form (relatively LC)

[Cam MacRae]

I love the way newforms is shaping up - when finished it's going to be
very powerful.

In the regression tests ~line 2250 there is an example for dynamic
constuction of a Form

/* snip

It's possible to construct a Form dynamically by adding to the
self.fields
dictionary in __init__(). Don't forget to call Form.__init__() within
the
subclass' __init__().
>>> class Person(Form):

... first_name = CharField()
... last_name = CharField()
... def __init__(self, *args, **kwargs):
... super(Person, self).__init__(*args, **kwargs)
... self.fields['birthday'] = DateField()
>>> p = Person(auto_id=False)
>>> print p
First name:
Last name:
Birthday:

*/


That's a beautiful thing, so I was thinking about my hacked comments
app (seems like every man and his dog has hacked comments ;)) and how
to switch to new forms - in particular how one might create exactly the
right number of ratings fields.  I did some toying around in the shell
(before I read the newforms code) and caught myself out thus:

>>> from django import newforms as forms
>>> class MyForm(forms.Form):
... field_a = forms.CharField()
... field_b = forms.CharField()
... def __init__(self, *args, **kwargs):
... super(MyForm, self).__init__(*args, **kwargs)
... options = self.data.get('options') # eg'opt1,opt2,opt3'
... opts_required = self.data.get('opts_required', True)
... if options:
... for i in range(len(options.split(','))):
...self.fields['opt%d' % (i+1)] =
forms.ChoiceField(required=opts_required)

>>> # create an instance of the form
>>> f = MyForm()
>>> f.fields.keys()
['field_a', 'field_b']
>>> f1 = MyForm({'options': 'opt1'})
>>> f1.fields.keys()
['field_a', 'field_b', 'opt1']
>>> f1.fields['opt1'].required
True
>>> f.fields.keys() #Now f also has the opt1 field
['field_a', 'field_b', 'opt1']
>>> f.fields['opt1'].required
True

>>> #Create another form and watch the behaviour
>>> f2 = MyForm({'options': 'opt1,opt2,opt3', 'opts_required': False})
>>> f2.fields.keys()
['field_a', 'field_b', 'opt1', 'opt2', 'opt3']
>>> f2.fields['opt1'].required
False
>>> f2.fields['opt2'].required
False
>>> f2.fields['opt3'].required
False
>>> f.fields.keys()
['field_a', 'field_b', 'opt1', 'opt2', 'opt3']
>>> f.fields['opt1'].required
False
>>> f.fields['opt2'].required
False
>>> f.fields['opt3'].required
False
>>> f1.fields.keys()
['field_a', 'field_b', 'opt1', 'opt2', 'opt3']
>>> f1.fields['opt1'].required
False
>>> f1.fields['opt2'].required
False
>>> f1.fields['opt3'].required
False

Probably not what I was hoping to achieve, but on reading the code
certainly what I should have expected, and a nice footnote to the
exercise nonetheless ;)

cheers,
Cam.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---