Re: #1443: strftime for date and datetime before 1900

[Jared]

Is there any movement on this issue?  I'm working on designing a site
dealing with historical data and pretty much all of the dates involved
are before 1900 (1600-1800).  Would be really nice to get a solid
solution on this.

On Mar 19, 10:45 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Wed, 2008-03-19 at 19:07 -0700, Philippe Raoult wrote:
> > Hi everyone,
>
> > I recently marked #1443 as RFC as it seemed to have a working patch
> > but SmileyChris asked me to start a discussion here.
>
> > I've since given a second look to the patch and surrounding code and
> > I'm a bit puzzled:
> > DateField's get_db_prep_{save, lookup} will use strftime to make a
> > string, but DateFieldTime seems to be dealing with strings already ?
>
> > Anyway, the issue is that we have two different strategies for fixing
> > #1443 (and two different patches):
> > - simply replace strtfime calls with custom format prints
> > - replace datetime by a specific module with full handling of leap
> > years before1900(correct me if I'm wrong there Chris)
>
> > I'd be happy to clean up and add some more tests to the simple version
> > but there need to be a consensus about which strategy to follow. To be
> > honest I just came across this ticket and I don't fully understand
> > what we're loosing by simply going the first way.
>
> The main drawback with the first approach is that every single case of
> using dates that might possibly be pre-1900has to manually do the
> printing. The second approach provides the standard strftime() interface
> on such objects that works. It's less strain on the brain -- import the
> right module once and then work as normal. It's also less typing.
>
> The main thing preventing checking in of the first approach, apart form
> a rewrite to give things sensible names -- the functions imported from
> the "datetime_pg" (better name required) module might as well have the
> proper names instead of also being called datetime_pg, etc and it should
> import all the other datetime stuff so you only have to import one
> module -- is copyright clearance. Code posted to comp.lang.python
> belongs to the original author. It's not automatically available for
> swiping into a project. The good news there is that Andrew Dalke isn't
> likely to have a problem here, so we just need to get some kind of
> sign-off. Fredrik Lundh has mentioned in the past that he'd be happy to
> contact Andrew if we think there'd be problems.
>
> (Don't do anything along those lines yet. Let's get some consensus
> first.)
>
> I'm slightly more in favour of replacing the broken methods with things
> of the same name that work. Much like we do for iterator stuff, doctest,
> decorator wrapping, sets, etc.
>
> Malcolm
>
> --
> Many are called, few volunteer.http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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: Unfair ticket management

[Mike Scott]

I'm not a fan of this discussion,

I understand what you're saying, and the simple importerror test should
suffice, otherwise its going to get to a point where we're going to have to
keep a list of python libraries that can't be used for app names. Its not
going to work like that. As far as I'm concerned, if you don't know enough
to know that you cannot name an app the same as a module on your python
path, then you're obviously not doing something right.

As an aside, I'm sure something could be implemented that goes through the
app list and see's if there are any conflicts. But not sure how reliable
this would be.

On Tue, Apr 1, 2008 at 4:08 PM, Thejaswi Puthraya <
[EMAIL PROTECTED]> wrote:

>
> On Mar 31, 9:08 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> > On Mar 31, 7:36 pm, Thejaswi Puthraya <[EMAIL PROTECTED]>
> > wrote:> First, I am very sorry to have caused so much of pain to you. I
> > > totally overlooked your ticket (just missed it) in an urge to
> > > contribute during the sprint. Will be careful from the next time. The
> > > patch for ticket #6789 too was pushed in after lot of reluctance from
> > > the devs because it still did not solve the problem of preventing the
> > > name clash during deployment.
> >
> > It's ok. It really wasn't so painfull :)
> >
> > > Another thing is that your current patch (as on 31/3/08) let's people
> > > name their project "test" which the INVALID_PROJECT_NAMES was
> > > preventing earlier.
> >
> > No, it won't. 'test' is a standard python package and it will be
> > detected by __import__ in try/except/else clause.
> > INVALID_PROJECT_NAMES is unnecessary - every single name in it is
> > handled by __import__ - I checked and tested this when created my
> > patch.
>
> Sorry to prolong this discussion. Though I can see the test module
> http://docs.python.org/modindex.html, it is not installed on my system
> and hence I was able to create a project by name 'test'. I am using
> python2.5.1 taken directly from the fedora rpm repository.
>
> Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
> [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import test
> Traceback (most recent call last):
>  File "", line 1, in 
> ImportError: No module named test
> >>>
>
> --
> Cheers
> Thejaswi Puthraya
> >
>

--~--~-~--~~~---~--~~
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: Unfair ticket management

[Thejaswi Puthraya]

On Mar 31, 9:08 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> On Mar 31, 7:36 pm, Thejaswi Puthraya <[EMAIL PROTECTED]>
> wrote:> First, I am very sorry to have caused so much of pain to you. I
> > totally overlooked your ticket (just missed it) in an urge to
> > contribute during the sprint. Will be careful from the next time. The
> > patch for ticket #6789 too was pushed in after lot of reluctance from
> > the devs because it still did not solve the problem of preventing the
> > name clash during deployment.
>
> It's ok. It really wasn't so painfull :)
>
> > Another thing is that your current patch (as on 31/3/08) let's people
> > name their project "test" which the INVALID_PROJECT_NAMES was
> > preventing earlier.
>
> No, it won't. 'test' is a standard python package and it will be
> detected by __import__ in try/except/else clause.
> INVALID_PROJECT_NAMES is unnecessary - every single name in it is
> handled by __import__ - I checked and tested this when created my
> patch.

Sorry to prolong this discussion. Though I can see the test module
http://docs.python.org/modindex.html, it is not installed on my system
and hence I was able to create a project by name 'test'. I am using
python2.5.1 taken directly from the fedora rpm repository.

Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import test
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named test
>>>

--
Cheers
Thejaswi Puthraya
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

AutoCad Software Free Download & AutoCAD 2009 is coming

[selvan suganthy]

*ttp://www.designhelp4you.blogspot.com/*


*http://www.designhelp4you.blogspot.com/*


*http://www.designhelp4you.blogspot.com/*


*
* *Auto CAD EBOOKS*

*AutoCAD 2009* 

*Bathroom Design Ideas* 
*Introduction*

   - *Interior 
design
   *
   - *Home interiors
design
   *
   - *Home decorating
ideas
   *

*
* *AutoCAD 2009*

   - *AutoCAD 2009 is
coming
   *
   - *AutoCad 
Download
   *
   - *AutoCAD 
history
   *
   - *Autodesk introduces
Vsta
   *
   - *Invalid 
display
   *
   - *Invalid display of polyline with negative thickness in
AutoCAD
   *
   - *Network license news in AutoCAD
2009
   *
   - *Purge of DWG takes forever -
solution
   *
   - *Riverbed and DWG 2007 file format
workaround
   *
   - *Vista File copy
Error
   *
   - *Vista SP1
installation
   *

*

*
 *Auto CAD EBOOKS*

   - *AutoCAD 2005 For
Dummies
   *

*

*
 *Auto CADThe Basics Lessons*

   - *L-1 Using
Co-ordinates
   *

*

*
 *AutoCAD 2008' Category*

   - *Autodesk AutoCAD
2008
   *
   - *Hip tip: Joining corners by using
FILLET
   *

*

*
 *Auto CAD 2008 Lessons*

   - *Auto CAD 
Lesson1-10
   *
   - *Auto CAD Lessons
1-11
   *
   - *AutoCAD Lesson
1-1
   *
   - *AutoCAD Lesson
1-2
   *
   - *AutoCAD Lesson
1-3
   *
   - *AutoCAD Lesson
1-4
   *
   - *AutoCAD Lesson
1-5
   *
   - *AutoCAD Lesson
1-6
   *
   - *AutoCAD Lesson
1-7
   *
   - *AutoCAD Lesson
1-8
   *
   - *AutoCAD Lesson
1-9
   *

*

*
 *AutoCad 2005 For Architects Training 1-10*

   - *Architectural
Film
   *
   - *Architectural
Visualization
   *
   - *Creating Presentation
Drawings
   *
   - *Drawing and Scale
Ffactor
   *
   - *Externally Referenced

Re: Refactoring the documentation

[James Bennett]

On Mon, Mar 31, 2008 at 7:25 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> Technology helps in some places, but there's no replacement
>  for a good editor. And I'm *not* talking about Emacs.

The next release will have 'M-x copyeditor' for that, actually...


-- 
"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: Refactoring the documentation

[pbx]

On Mar 31, 8:25 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Mon, Mar 31, 2008 at 6:25 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >  I'm wondering if something likehttp://django.reddit.com/shouldn't
> >  get some sort of official blessing for listing/searching those blog
> >  posts which aren't of good enough quality for inclusion in the
> >  official docs, but are still useful to some people.
>
> Mmmm... I'm really skeptical of "consensus" documentation. I think
> when it comes to prose a centralized group of editors does better than
> "the masses" -- Wikipedia may be (and is!) technically superior to
> Britannica, but Wikipedia's writing style doesn't even measure up to
> Encarta. Technology helps in some places, but there's no replacement
> for a good editor. And I'm *not* talking about Emacs.

First, this project is a great idea. Django's docs are great, but they
will only stay great if they're attended to. I'll be happy to help out
a bit once I finish up this (ahem) other pesky writing project I've
been working on.

Second, I take and agree with your point about editorial authority.
Leaving aside the question of outside resources, I wonder if some
pathway for user feedback or annotation of the official docs, in
addition to the ticket system, could be beneficial. A dynamic FAQ that
serves as an alternative TOC/index for the docs? A "did this answer
your question" type of feedback loop? Maybe I've been sniffing the Web
2.0 fumes too much.

Third, one stakeholder type I didn't see in your list is the refugee/
migrator coming from another web framework. This probably doesn't map
to another full-blown documentation type, since the topical and API
reference docs will serve pretty well. But one could make an argument
that a guide or guides along the lines of "Django for Blub-on-Boats
programmers" could help bring framework-switchers up to speed more
quickly.

pb

--~--~-~--~~~---~--~~
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: Refactoring the documentation

[Jacob Kaplan-Moss]

On Mon, Mar 31, 2008 at 6:25 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>  I'm wondering if something like http://django.reddit.com/ shouldn't
>  get some sort of official blessing for listing/searching those blog
>  posts which aren't of good enough quality for inclusion in the
>  official docs, but are still useful to some people.

Mmmm... I'm really skeptical of "consensus" documentation. I think
when it comes to prose a centralized group of editors does better than
"the masses" -- Wikipedia may be (and is!) technically superior to
Britannica, but Wikipedia's writing style doesn't even measure up to
Encarta. Technology helps in some places, but there's no replacement
for a good editor. And I'm *not* talking about Emacs.

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?hl=en
-~--~~~~--~~--~--~---

Re: Refactoring the documentation

[Jacob Kaplan-Moss]

On Mon, Mar 31, 2008 at 4:36 PM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>  One thing I'm trying to figure out in my small set of docs is how
>  frequently I want/plan to use the index and glossary functionality
>  that comes with sphinx. How much additional meta data do you hope to
>  add to the docs? Adding more index directives (for example) could be
>  quite time consuming and I'm not sure how useful it would be. The
>  glossary is another intriguing concept but I'm not sure how useful it
>  is. I'm curious what your approach might be with these types of sphinx
>  features.

I'd take these questions (and any others about Sphinx) to the
(brand-new!) sphinx-dev mailing list (also on Google Groups). It's
just getting started, but I'd love to say a bunch of projects start
using and discussing using Sphinx.

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?hl=en
-~--~~~~--~~--~--~---

Re: Refactoring the documentation

[[EMAIL PROTECTED]]

This all sounds really awesome!

>     * Cross-sectional how-tos: we've only got a few of these currently. This
>       is the area where bloggers are doing a wonderful job these days. The
>       problem with this blog material is that it usually doesn't every get
>       updated, so it eventually becomes obsolete. The task here will be to
>       identify the best of these articles and make them official parts of the
>       documentation. If we can get the original author to maintain the doc,
>       even better.

I'm wondering if something like http://django.reddit.com/ shouldn't
get some sort of official blessing for listing/searching those blog
posts which aren't of good enough quality for inclusion in the
official docs, but are still useful to some people.
--~--~-~--~~~---~--~~
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: Refactoring the documentation

[Marty Alchin]

I won't bother responding to anybody in particular, because I'm in
agreement with so many on this thread so far. I'm glad to see this
refactoring happen, because a doc improvement can only make things
better for everybody.

I know you're not getting into details yet, but once you do get down
to it, I'll gladly volunteer to write, or at least edit, API reference
and internals docs. I already delve into all that anyway, so
documenting it sounds like a blast!

-Gul

--~--~-~--~~~---~--~~
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: Refactoring the documentation

[Malcolm Tredinnick]

On Mon, 2008-03-31 at 13:45 -0500, Jacob Kaplan-Moss wrote:
[...]
> * Internals: not so hot; in fact, we've really only got the contributing
>   document. Help is needed here.

There's http://code.djangoproject.com/wiki/DevModelCreation. It needs to
be updated when model inheritance lands, because the data flow in
__new__ has changed slightly, but it's still predominantly accurate.
I've started writing a similar page (just locally so far) for the
QuerySet and Query classes. They're useful for people wanting to
customise. I'd prefer stuff like that to be in subversion rather than
the wiki because it's not really appropriate fodder for just anybody to
edit.

The trick here is walking the line between what we want to commit to and
what is in existence at the moment. In the past we've used the lack of
documentation as a clear sign that something isn't stable, which isn't a
bad approach, but does make it annoying when you actually want to work
on that stuff and don't know how it works.

Prior to you posting this thread, I'd been meaning to send a query about
maybe having a docs/dev/ directory which would have the status of "stuff
in here is accurate, but not frozen and not public API". But now it's
all your problem and you can work it out. I like that plan better.
Mwahahaha...

Regards,
Malcolm

-- 
Success always occurs in private and failure in full view. 
http://www.pointy-stick.com/blog/


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

we need something like this in Django json encoder

[ydjango]

This following code was very helpful, something like this in Django
would be greatly appreciated, I wish I had seen it earlier, would have
saved me 2 days of effort.

http://blog.michaeltrier.com/2007/7/30/json-generic-serializer

--~--~-~--~~~---~--~~
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: Refactoring the documentation

[[EMAIL PROTECTED]]

I've been looking at using the sphinx tools for overhauling the
Satchmo documentation too. There's far far less documentation in that
project so it is easier but I am anxious to see how you do it. IMHO,
Django really has some best practices with documentation so I
appreciate the fact that you're keeping the process open. It should
help other people do the same thing with their projects.

One thing I'm trying to figure out in my small set of docs is how
frequently I want/plan to use the index and glossary functionality
that comes with sphinx. How much additional meta data do you hope to
add to the docs? Adding more index directives (for example) could be
quite time consuming and I'm not sure how useful it would be. The
glossary is another intriguing concept but I'm not sure how useful it
is. I'm curious what your approach might be with these types of sphinx
features.

Anyway, looking forward to the process - so I can "leverage" it for
Satchmo.

-Chris

--~--~-~--~~~---~--~~
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: Refactoring the documentation

[Jacob Kaplan-Moss]

On Mon, Mar 31, 2008 at 4:01 PM, J. Cliff Dyer <[EMAIL PROTECTED]> wrote:
>  Since all the documentation is already in subversion, it might make
>  sense to have a docs-refactor branch on the tree.

I'd rather not -- I don't want to get sucked into thinking I have a
long time for this. As long as the refactor results in something
structurally correct we can improve on the content continuously. As
I've been working more today I think I can set the groundwork pretty
well and then ask for volunteers to assist in quickly adding all the
metadata. Once that's in place we can make the swap and improve on the
content bit by bit.

>  I volunteered to help out on the documentation at the sprint, and then
>  had to leave before anything got underway on it.  I just want to put my
>  hat in the ring again.  I'd love to help out, when the time comes for
>  work delegation.

Awesome; I'll certainly ask here when I need some help.

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?hl=en
-~--~~~~--~~--~--~---

Re: Refactoring the documentation

[Jacob Kaplan-Moss]

On Mon, Mar 31, 2008 at 2:29 PM, Tim Chase
<[EMAIL PROTECTED]> wrote:
>  Ah, the curse of backwards compatibility and permalinks.  My one
>  concern (okay, given more time to think about it, perhaps more
>  will percolate to the surface) with this is the abundance of
>  (legacy) HTML-fragment references that reside in the ML archives,
>  such as
>http://www.djangoproject.com/documentation/model-api/#primary-key
>
>  which will break in the new scheme.

I'll do my best to maintain these. Worst-case, we can turn an invalid
fragment into a search string and try to find the content that way.

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?hl=en
-~--~~~~--~~--~--~---

Re: Refactoring the documentation

[J. Cliff Dyer]

On Mon, 2008-03-31 at 13:45 -0500, Jacob Kaplan-Moss wrote:

> Right. How will I do this, you say? Here's my plan:
> 
> * Using the outline from the existing documentation
>   (http://toys.jacobian.org/django/docoutline-r7392/), make a new outline
>   and figure out where each bit fits into the new regime. This doesn't
>   need to be in any way perfect or 100% complete; just good enough to get
>   started from.
> 
> * Following that outline, break up the existing docs. Copy/paste is fine;
>   no rewriting yet.
> 
> * A few areas will need top-level outlines/indexes. Write those.
> 
> * Go through each document and mark it up with all the gory metadata and
>   links. This is the part that'll take a crazy amount of work.
> 
> * Rewrite the website documentation tools to work under the new regime
>   (they'll already build standalone thanks to Sphinx).
> 
> Am I missing anything here?
> 
> So feedback is welcome, please give it. Volunteers are welcome, too, but I'll
> probably not be ready to distribute work just yet. I need to finish the
> groundwork, and I need to figure out how to best to work without totally
> fucking up the existing docs.
> 

Since all the documentation is already in subversion, it might make
sense to have a docs-refactor branch on the tree.

> Jacob

I volunteered to help out on the documentation at the sprint, and then
had to leave before anything got underway on it.  I just want to put my
hat in the ring again.  I'd love to help out, when the time comes for
work delegation.  

Cheers,
Cliff


--~--~-~--~~~---~--~~
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: Refactoring the documentation

[Fredrik Lundh]

Tim Chase wrote:

> Ah, the curse of backwards compatibility and permalinks.  My one
> concern (okay, given more time to think about it, perhaps more
> will percolate to the surface) with this is the abundance of
> (legacy) HTML-fragment references that reside in the ML archives,
> such as
>http://www.djangoproject.com/documentation/model-api/#primary-key
> 
> which will break in the new scheme.

unless you add a small amount of JavaScript to the page in question, of 
course.




--~--~-~--~~~---~--~~
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: Dynamic Subdomain generation for users

[[EMAIL PROTECTED]]

I apologize, I did not see that I was posting this to Django
Developers.

My mistake.

On Mar 31, 2:33 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Hi guys.
>
> I'm developing a system that gives a user a sub domain for their
> account.
>
> I found this 
> article,http://www.rossp.org/blog/2007/apr/28/using-subdomains-django/,
> which is really helping. But the problem I'm having trouble thinking
> through is how I could give sub domains certain urls that the main
> domain wouldn't have. For example:
>
> A user's account would be user.domain.com. When they access that it
> would redirect to user.domain.com/login. I don't want the normal
> domain.com to be able to go to /login without being a sub domain.
>
> Ideas on how I should implement this would be great.
>
> Thanks,
>
> Levi
--~--~-~--~~~---~--~~
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: GSoC proposition - djangosearch backend

[[EMAIL PROTECTED]]

Yes, but in djangosearch you will have support for many search engines
with very simple API.

On 31 Mar, 20:16, Alex Koshelev <[EMAIL PROTECTED]> wrote:
> Do you see:
> -http://code.djangoproject.com/wiki/TextIndexingAbstractionLayer
> -http://code.google.com/p/djapian/
> -http://code.google.com/p/django-sphinx/
> ?
>
> On Mar 31, 8:39 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > Hi,
>
> > My name is Grzegorz Swierad and I am interested in participating in
> > Google Summer of Code for Django. I study in University of Zielona
> > Gora in Poland. I have more than one year experience with Django. I
> > create sites:http://mines20.comorhttp://plom.pl.
>
> > I wish to create a Xapian backend for djangosearch. Eventually, it can
> > be other search engine, but Xapian is more important for me, becouse I
> > use it in my new project.
>
> > What do you thing about this, and who is interested in mentoring it?
>
> > Thanks,
> >  Grzegorz
--~--~-~--~~~---~--~~
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 the documentation

[Jacob Kaplan-Moss]

I'm embarking on a mission to refactor Django's documentation; this is where
you give me feedback about how much crack I'm smoking. Keep in mind that most
of this post fits into the "heads-up" category: if I'm not asking for feedback
on some point it's because I've made up my mind. Only argue with those points
if you *really* think you need to.

I've identified five types of people reading Django documentation:

* New users looking to get started or to learn new techniques.
* Developers looking to solve a specific problem.
* Developers looking for reference to a particular API.
* Experienced developers looking to build other frameworks on top of
  Django using extension points (middleware, signals, contribute_to_class,
  etc.)
* Contributors looking for information about Django internals and
  workflow.

This leads me to identify five types of documentation we need:

* Beginner material (tutorials, getting started)
* Cross-sectional "how-to" material (specific walkthroughs of particular
  techniques)
* Topical guides ("caching", "middleware")
* API reference ("HttpResponse.__init__")
* Internals and meta-documentation.

(This leaves out misc. stuff like release notes; I don't really think we need
to worry about those beyond stuffing 'em in a "misc" section.)

My breakdown of stakeholders is one place I'm looking for feedback. Am I
missing anyone? Is there a "type" of documentation I've not thought of?
This'll become the high-level organization of the docs, so getting it right is
important.

My thoughts on how we do on each section and how we need improvement:

* Beginner material: we've got a good amount if this in the tutorials,
  overview, and installation guide. Some bits of those documents --
  especially the installation guide -- ought to be broken out into
  reference material.

* Cross-sectional how-tos: we've only got a few of these currently. This
  is the area where bloggers are doing a wonderful job these days. The
  problem with this blog material is that it usually doesn't every get
  updated, so it eventually becomes obsolete. The task here will be to
  identify the best of these articles and make them official parts of the
  documentation. If we can get the original author to maintain the doc,
  even better.

* Topical guides: we're awesome here; most current docs are organized
  around one particular topic covered in depth. The only thing to change
  here is to move detailed reference out of these documents into dedicated
  reference docs. This will improve the overall flow of the topical
  guides.

* API reference: like above, we're pretty awesome here, too. Again, though
  the API reference needs to move to documents linked from the topical
  guides.

* Internals: not so hot; in fact, we've really only got the contributing
  document. Help is needed here.

Again, am I missing anything here?

By now you probably want more details. OK, here we go.

If you hung out with my at the PyCon sprint this'll probably make sense. If
not apologies, 'cause I'm gonna do a bunch of hand-waving now. Ask questions
where it doesn't make sense.

The main goal in refactoring is to break everything up into manageable chunks.
The model API document is over 30 printed pages -- finding anything useful
there is rapidly becoming impossible. Even worse, it's hard to tell if
something's gonna be found there or in the DB API -- quick, where are primary
keys documented?

What I'm planning on doing is some radical chopping. I'd turn the model
documentation into a bunch of different docs, laid out something like the
following (where each bullet point is a separate doc file/page):

* High-level overview: defining and loading models.
* Model definition reference
* Field types
* Relationships
* Meta options
* Writing managers
* "Special" model methods
* DB API reference (CRUD basics)
* Manager methods
* QuerySets / QuerySet methods
* Filter lookup options
* Following relationships
* Custom SQL

This is only a rough sketch -- please don't even bother critiquing it; it'll
change. I only include it there to give you a rough idea of what I'm intending
to do. And of course I'm not going to limit my work to models; I plan to do
something similar to all the documentation.

This is the main bit I'm looking for feedback on. Is this a good idea, or am I
on crack?

In the end, the basic idea will be that topical information will "flow" like
good prose should, but will link down into detailed reference where
appropriate. Each little bit of reference will have a canonical "location" in
the docs, so that every like to HttpResponse will go to the same place.

Of course, this'll require better tooling -- we're going to need to make sure
these links all work 

Re: GSoC proposition - djangosearch backend

[Alex Koshelev]

Do you see:
- http://code.djangoproject.com/wiki/TextIndexingAbstractionLayer
- http://code.google.com/p/djapian/
- http://code.google.com/p/django-sphinx/
?

On Mar 31, 8:39 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> My name is Grzegorz Swierad and I am interested in participating in
> Google Summer of Code for Django. I study in University of Zielona
> Gora in Poland. I have more than one year experience with Django. I
> create sites:http://mines20.comorhttp://plom.pl.
>
> I wish to create a Xapian backend for djangosearch. Eventually, it can
> be other search engine, but Xapian is more important for me, becouse I
> use it in my new project.
>
> What do you thing about this, and who is interested in mentoring it?
>
> Thanks,
>  Grzegorz
--~--~-~--~~~---~--~~
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: GSoC proposition - djangosearch backend

[[EMAIL PROTECTED]]

Yes, You right. This is not big enough. I can try to create more
backends, but I don't know how many I make it.

Grzegorz

On 31 Mar, 18:49, "Joseph Kocherhans" <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 31, 2008 at 11:39 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> >  Hi,
>
> >  My name is Grzegorz Swierad and I am interested in participating in
> >  Google Summer of Code for Django. I study in University of Zielona
> >  Gora in Poland. I have more than one year experience with Django. I
> >  create sites:http://mines20.comorhttp://plom.pl.
>
> >  I wish to create a Xapian backend for djangosearch. Eventually, it can
> >  be other search engine, but Xapian is more important for me, becouse I
> >  use it in my new project.
>
> >  What do you thing about this, and who is interested in mentoring it?
>
> I know someone else is also putting together a proposal to work on
> djangosearch backends, but please submit your proposal anyhow. I would
> love to see a good xapian backend. A single backend might not be a big
> enough project for SoC, so you might want to specify what else you'll
> do in your proposal if you finish early.
>
> Joseph
--~--~-~--~~~---~--~~
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: Customizable QuerySets

[Marty Alchin]

On Mon, Mar 31, 2008 at 5:27 AM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
>  If you want to be able to specify a different default manager for some
>  particular use of an existing model, you're sort of after a third type
>  of model subclassing that I've thought about but haven't implemented:
>  subclassing an existing model and explicitly telling Django that this is
>  only Python-level (and not database-/ORM-level) inheritance. So all the
>  database interactions are part of the parent class(es) and the child
>  class simply adds extra functional pieces (such as a new default
>  manager). Nothing existing so far rules out adding this, so it's not
>  something that has to be resolved now, which is why I haven't wasted any
>  brain cells on it so far. This might be fairly easy to add once we work
>  out how to spell it, since it's only saying "create absolutely no fields
>  for this model, not even links back to the parent model and definitely
>  don't create a database table."

I've invested a few brain cells on this already, though not enough for
a complete solution. It'd be off-topic for this discussion, but
if/when you get around to it, feel free to hit me up if you're looking
for another opinion on how it could be done.

-Gul

--~--~-~--~~~---~--~~
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: GSoC proposition - djangosearch backend

[Joseph Kocherhans]

On Mon, Mar 31, 2008 at 11:39 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>  Hi,
>
>  My name is Grzegorz Swierad and I am interested in participating in
>  Google Summer of Code for Django. I study in University of Zielona
>  Gora in Poland. I have more than one year experience with Django. I
>  create sites: http://mines20.com or http://plom.pl .
>
>  I wish to create a Xapian backend for djangosearch. Eventually, it can
>  be other search engine, but Xapian is more important for me, becouse I
>  use it in my new project.
>
>  What do you thing about this, and who is interested in mentoring it?

I know someone else is also putting together a proposal to work on
djangosearch backends, but please submit your proposal anyhow. I would
love to see a good xapian backend. A single backend might not be a big
enough project for SoC, so you might want to specify what else you'll
do in your proposal if you finish early.

Joseph

--~--~-~--~~~---~--~~
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 proposition - djangosearch backend

[[EMAIL PROTECTED]]

Hi,

My name is Grzegorz Swierad and I am interested in participating in
Google Summer of Code for Django. I study in University of Zielona
Gora in Poland. I have more than one year experience with Django. I
create sites: http://mines20.com or http://plom.pl .

I wish to create a Xapian backend for djangosearch. Eventually, it can
be other search engine, but Xapian is more important for me, becouse I
use it in my new project.

What do you thing about this, and who is interested in mentoring it?

Thanks,
 Grzegorz
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Duplicate tickets

[Ivan Illarionov]

Just changed the subject.
--~--~-~--~~~---~--~~
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: Unfair ticket management

[Ivan Illarionov]

On Mar 31, 7:36 pm, Thejaswi Puthraya <[EMAIL PROTECTED]>
wrote:
> First, I am very sorry to have caused so much of pain to you. I
> totally overlooked your ticket (just missed it) in an urge to
> contribute during the sprint. Will be careful from the next time. The
> patch for ticket #6789 too was pushed in after lot of reluctance from
> the devs because it still did not solve the problem of preventing the
> name clash during deployment.
It's ok. It really wasn't so painfull :)

> Another thing is that your current patch (as on 31/3/08) let's people
> name their project "test" which the INVALID_PROJECT_NAMES was
> preventing earlier.
No, it won't. 'test' is a standard python package and it will be
detected by __import__ in try/except/else clause.
INVALID_PROJECT_NAMES is unnecessary - every single name in it is
handled by __import__ - I checked and tested this when created my
patch.

--
Ivan Illarionov
--~--~-~--~~~---~--~~
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: Unfair ticket management

[Ivan Illarionov]

> There are people doing triage regularly to check for duplicates;
> however, there are a large number of tickets and this one -- as
> mentioned above -- happened during the development sprint when there
> was already a large amount of ticket activity. Try not to take it
> personally or allege unfairness; in all likelihood, it was just a
> mix-up that happened in the clamor of the sprint.

Thank you for explanation. Now I see that it's all about sprint. But
it's still feels very bad when you see some other patch merged when
you have the same thing (even that small) done earlier.

--
Ivan
--~--~-~--~~~---~--~~
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 admin Error at /admin/auth/user/1/?

[Ned Batchelder]

Just to explain my motivation: it wasn't so much to optimize the core 
devs' time, though that is a concern, but to make on-ramping new users 
as friction-free as possible.  If there's a common error that newbies 
make, we can either provide an error message ("wrong group"), or try to 
fix the system so that they don't make the error in the first place.  
The latter is a better option where possible.  It's as true of the 
community as it is of the software.

--Ned.
http://nedbatchelder.com/blog

Malcolm Tredinnick wrote:
> On Mon, 2008-03-31 at 07:11 -0400, Ned Batchelder wrote:
>   
>> I figured the name of the group is hard to ignore.  By making the name
>> more specific, people would be more likely to find the appropriate
>> group.
>> 
>
> Yeah... I know where you're coming from. It's hard to tell if the change
> will work or not.
>
> Speaking only for myself, it's not that huge of a problem when people
> periodically post to the wrong list. We point them in the right
> direction and everybody moves on. If we all remain polite, nobody seems
> to take offence. As a percentage of traffic on this list, slightly
> misdirected posts are a small amount. So I tend to favour the "do
> nothing" action slightly at this stage, rather than chase an ephemeral
> perfect solution.
>
> Anyway, I've posted two more times to this thread that I probably needed
> to. It's not that big a deal for me either way. Also not my decision.
>
> Malcolm
>
>   

-- 
Ned Batchelder, http://nedbatchelder.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: Unfair ticket management

[Justin Lilly]

Ivan,

I'm sure the developers do check for duplicate tickets, but they're busy
people. Not to mention with nearly a thousand tickets open, it can be
difficult to remember all of them and easy to miss one. I might suggest
coming here with an air of curiosity instead of an accusatory tone for best
results.
Good luck,
   -justin

On Mon, Mar 31, 2008 at 7:52 AM, Ivan Illarionov <[EMAIL PROTECTED]>
wrote:

>
> Hey, I've just found that ticket #6789 was merged into trunk while my
> ticket #6654 that was filed a month earlier and does the same thing
> was ignored.
>
> My patch is still better because it removes INVALID_PROJECT_NAMES that
> became unnecessary -- all those names will be detected by __import__.
>
> Why the developers don't check for duplicate tickets?
>
> --
> Ivan
> >
>


-- 
Justin Lilly
Web Developer/Designer
http://justinlilly.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 admin Error at /admin/auth/user/1/?

[Malcolm Tredinnick]

On Mon, 2008-03-31 at 07:11 -0400, Ned Batchelder wrote:
> I figured the name of the group is hard to ignore.  By making the name
> more specific, people would be more likely to find the appropriate
> group.

Yeah... I know where you're coming from. It's hard to tell if the change
will work or not.

Speaking only for myself, it's not that huge of a problem when people
periodically post to the wrong list. We point them in the right
direction and everybody moves on. If we all remain polite, nobody seems
to take offence. As a percentage of traffic on this list, slightly
misdirected posts are a small amount. So I tend to favour the "do
nothing" action slightly at this stage, rather than chase an ephemeral
perfect solution.

Anyway, I've posted two more times to this thread that I probably needed
to. It's not that big a deal for me either way. Also not my decision.

Malcolm

-- 
No one is listening until you make a mistake. 
http://www.pointy-stick.com/blog/


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

Unfair ticket management

[Ivan Illarionov]

Hey, I've just found that ticket #6789 was merged into trunk while my
ticket #6654 that was filed a month earlier and does the same thing
was ignored.

My patch is still better because it removes INVALID_PROJECT_NAMES that
became unnecessary -- all those names will be detected by __import__.

Why the developers don't check for duplicate tickets?

--
Ivan
--~--~-~--~~~---~--~~
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 admin Error at /admin/auth/user/1/?

[simonbun]

Indeed, but maybe the description could be added to the top of the
list on
http://groups.google.com/group/django-developers/topics or
http://groups.google.com/group/django-developers

to make it a bit harder to miss.

But I agree, no solution would be 100% fool proof.

Simon.


On Mar 31, 7:50 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sun, 2008-03-30 at 22:01 -0700, simonbun wrote:
> > Maybe it could be useful to add a description to this list. This would
> > make things clear for new people using the Google Groups web
> > interface. Just an 
> > example:http://groups.google.com/group/notmm-discuss/topics
> > . I've also seen some groups with a red warning box at the top, but I
> > can't seem to find an example at the moment.
>
> Quoting the description of this list as given on the Google groups page:
>
> "Discussion group for Django developers. This is for people
> developing the Django framework itself. Please use django-users
> for issues regarding using the framework."
>
> If people don't read documentation and instructions on the page set up
> to describe something, having multiple things for them to ignore doesn't
> usually improve the situation. People will continue to make mistakes.
> We'll continue to point them in the right direction and try not to
> inadvertently answer their question in the inappropriate forum.
>
> Malcolm
>
> --
> Telepath required. You know where to apply...http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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: Customizable QuerySets

[Malcolm Tredinnick]

On Sun, 2008-03-30 at 13:31 -0700, [EMAIL PROTECTED] wrote:
> > Agreed. In fact, this exact suggestion was made during the recent
> > discussions about adding aggregates. I'd much rather see per-manager
> > customization of Query Sets, rather than a global setting.
> 
> What do you think about my latest proposal of a
> get_custom_manager(MyManager) function on Model objects?  (See the end
> of my previous post to this list for an example of what I mean).

I don't like this, since it's not actually usable (in the sense that it
doesn't add anything) in this form. Your earlier example had you
attaching a get_custom_manager() method to, e.g., the User model, but
there's no way to say what that method should return.

If you want to be able to specify a different default manager for some
particular use of an existing model, you're sort of after a third type
of model subclassing that I've thought about but haven't implemented:
subclassing an existing model and explicitly telling Django that this is
only Python-level (and not database-/ORM-level) inheritance. So all the
database interactions are part of the parent class(es) and the child
class simply adds extra functional pieces (such as a new default
manager). Nothing existing so far rules out adding this, so it's not
something that has to be resolved now, which is why I haven't wasted any
brain cells on it so far. This might be fairly easy to add once we work
out how to spell it, since it's only saying "create absolutely no fields
for this model, not even links back to the parent model and definitely
don't create a database table."

Then something that wanted to use a different manager (which is really
what you are meaning when you say "different queryset") with a model
would subclass it in this fashion and add their own manager to the
subclass. Existing code doesn't care about the new behaviour of your
custom manager and can safely rely on the existing behaviour it is used
to (which is a good thing: you don't sabotage existing code. Existing
code uses the original model class). Your new code can use the subclass
to be explicit that it wants the new queryset and that's fine, since
it's new code that you are writing to take advantage this, so it's
hardly a burden to have to write UserSubclass instead of User.

Malcolm

-- 
Atheism is a non-prophet organization. 
http://www.pointy-stick.com/blog/


--~--~-~--~~~---~--~~
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: Retrieving List of Model Names

[jurian]

I'll drop the idea of creating the 'get_all_related_model*' method.

Thanks


On Mar 31, 7:35 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sun, 2008-03-30 at 14:08 -0700, jurian wrote:
> > I'm quite new to Django source so I wanted to get some advice on some
> > additions I tought of making to the code base.
>
> > My final goal is to get a list of names of the models related to a
> > certain model (perhaps there is a very simple way of doing this I
> > don't know of).
>
> > First I though of adding a 'get_all_related_models' method to
> > django.db.models.options, but then I realized that I won't be able to
> > access the '_meta' attribute from the page templates, so I though of
> > changing it to 'get_all_related_model_names'.
>
> > Please let me know if I'm on the right track, or if I'm totally
> > missing something here.
>
> We already have a fairly straightforward way to get access to all the
> related fields -- related "models" is not fine-grained enough for most
> purposes, since there can easily be multiple fields on Model A relating
> to Model B. We use that functionality in querysets for example, when you
> specify an invalid field: the error tells you which field names are
> legal.
>
> Start from there and you could write a simple function like this for
> your own purposes that only includes reverse relations. I'm not sure
> there's any need for it to go into Django's core, but it can be
> implemented without needing any core changes, so you should be able to
> incorporate it into your own projects easily enough.
>
> Malcolm
>
> --
> The hardness of butter is directly proportional to the softness of the
> bread.http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---