I'm not sure about the exact colors, but the visual distinction is a
big plus in my book.
One possible place to document it would be in the information
regarding the TEMPLATE_DEBUG setting here:
http://docs.djangoproject.com/en/dev/ref/settings/#template-debug
- Gabriel
On Nov 2, 2:03 pm, Doug
1. Is there a reason Django's phone2numeric method doesn't work for
the letters Q or Z? I realize that those two letters are the ones that
share four letters to a number instead of the standard three, but
that's no reason to leave them out. Most modern phones include the
full alphabet on their keys
added or a comment should be added to the code
> explaining the reason for leaving them out.
>
> On Jan 14, 11:23 am, Gabriel Hurley wrote:
>
>
>
> > 1. Is there a reason Django's phone2numeric method doesn't work for
> > the letters Q or Z? I realize that th
Having been bitten by issue #1480 personally, I'm wondering what the
status of this ticket really is? Trac indicates it needs a better
patch and better docs, but there's no information about what changes
are needed.
If someone will give me some guidance, I'd be happy to wrap this one
up and see it
Great! I thought those modifications by "Anonymous" looked funny...
Thanks!
- Gabriel
On Feb 25, 11:25 pm, Russell Keith-Magee
wrote:
> On Fri, Feb 26, 2010 at 8:55 AM, Gabriel Hurley wrote:
> > Having been bitten by issue #1480 personally, I'm wondering what the
&
The Django Developers list for discussion of the development of Django
itself. Please ask questions related to using Django on django-users,
not here.
Just to point you in the right general direction, the allowed query
terms are defined in django.db.models.sql.constants the and then the
SQL is fil
I guess it depends whether he wants his new filter added to core, or
just for his project... That's why I gave him a starting point, just
in case ;-)
- Gabriel
On Mar 4, 1:12 pm, Jerome Leclanche wrote:
> On Thu, Mar 4, 2010 at 11:05 PM, Gabriel Hurley wrote:
> > The Django D
I've read through the history on this group about triage process and I
have an idea I'd like to offer gently:
When I'm looking for tickets to work on, I often wish there was a
triage stage between "accepted" and "ready for checkin". On other
trackers the "feedback" triage stage is for this purpose
t-hand.
Thanks!
- Gabriel
On Mar 6, 3:56 am, Russell Keith-Magee wrote:
> On Sat, Mar 6, 2010 at 9:40 AM, Gabriel Hurley wrote:
> > I've read through the history on this group about triage process and I
> > have an idea I'd like to offer gently:
>
> Thanks for th
Wow, that's a seriously old ticket! Decision needed for sure.
Wim, if you want to open a ticket for the docs but don't feel like (or
don't know how to) write a docs patch I'm happy to do so. I agree that
the current solution isn't clear enough. Just let me know what number
the ticket is.
- Gabri
You seem to be missing the point of the code you reference above. You
should probably read up on the "Sites" framework that ships with
Django:
http://docs.djangoproject.com/en/dev/ref/contrib/sites/
All the best,
- Gabriel
On Mar 12, 1:39 pm, aditya wrote:
> Description
> =
> This
- Gabriel
On Mar 12, 6:56 pm, aditya wrote:
> Could you be more specific? I'm not sure what you mean.
> Aditya
>
> On Mar 12, 5:26 pm, Gabriel Hurley wrote:
>
>
>
> > You seem to be missing the point of the code you reference above. You
> > should probably rea
I'm not arguing that the proposal is inherently bad, just that it was
being proposed without understanding the existing solution.
Personally, I use a custom model that inherits from Site to manage my
sites, so it's not like I'm thrilled with the current system either.
I would actually be +0 on add
Hey folks,
I was looking through the recent tickets and saw #13115 [1], which
looked interesting. It got closed by ramiro (whose judgment I normally
trust) as a "worksforme", but I don't think he quite got what the OP
wanted.
I thought I'd bring it up on here to see if it was worth reopening the
Wow, I read that section three times this morning (and who knows how
many times in the past), and I still managed to miss that about
wrapping fields inside of fieldsets in tuples. My apologies!
I'd almost say it could use a docs patch to make that feature more
obvious since it's now eluded several
The docs have this to say about is_active:
"This doesn’t control whether or not the user can log in. Nothing in
the authentication path checks the is_active flag, so if you want to
reject a login based on is_active being False, it is up to you to
check that in your own login view. However, permiss
I couldn't help notice that #13023 was mentioned in Russ' latest 1.2
status update as a ticket that "will require some significant design
work". Since I've accepted that ticket I'd love to get some feedback
from folks.
The ticket: http://code.djangoproject.com/ticket/13023
The ticket was opened b
i know of) the purge the
> session data for a given user on deactivation, and i can't just email
> them to politely ask them to log out.
>
> On Mar 16, 4:48 pm, Gabriel Hurley wrote:
>
>
>
> > The docs have this to say about is_active:
>
> > "This doesn’t co
ionality.
>
> I'd like to take the opportunity and thank you for this patch and another
> one in a ticket I filed. Thanks,
> Iván
>
>
>
> On Tue, Mar 16, 2010 at 8:10 PM, Gabriel Hurley wrote:
> > I couldn't help notice that #13023 was mentioned in R
sn't
intentional. If this is determined to be a feature, I'll open a new
bug ticket about max_num because I do think that should be corrected.
But it doesn't absolutely have to be corrected in connection with this
ticket.
Feedback?
- Gabriel
On Mar 16, 8:31 pm, Gabriel Hurle
gt; Hi Gabriel
>
> Sorry for taking so long to get back to you on this. I certainly
> appreciate the effort you've put into the analysis.
>
> On Fri, Mar 19, 2010 at 6:03 AM, Gabriel Hurley wrote:
> > There are two possible solutions, as I see it:
>
> > 1. Chang
point the patch should be
complete!
On Mar 18, 8:05 pm, Gabriel Hurley wrote:
> Thanks for a great reply Russ. I agree 100% about interpretation 3
> being the most useful and beneficial.
>
> The first concern about the original use case is something I'd
> considered, but I d
If you haven't already, take a read through the "internals" section of
the docs. It covers a number of the questions you've asked about
deprecation, what can be changed in minor (1.x) releases, etc.
http://docs.djangoproject.com/en/dev/internals/
They were definitely interesting for me.
Being a
Maybe it's an overly simplistic question, but: what makes the tests
slow currently? It's not simply the volume of them. It's more than
possible for Python to race through hundreds of tests per second under
the right conditions.
Some of Django's test modules obviously zip along, but others seem to
To be honest, my biggest question is "is this really about Django?"
It seems like this proposal could have gone to anybody, or it could be
a standalone app.
I also would like to know if you have examples of other successful
implementations of such a system that incorporate HTML, CSS, *and* JS
int
Before I even say anything: I think the core team does a great job,
they're as fair as humanly possible in their decisions, and Django's
stability is amazing.
My disclaimer out of the way, I'd like to share my own experience of
being a new contributor just to add another perspective.
I only start
I just want to second this suggestion from Russell:
On Apr 19, 8:11 am, Russell Keith-Magee
wrote:
> Lastly, pick anything to do with documentation. This isn't a coding
> problem, obviously, but writing up a documentation patch to clarify
> some issue will help you get to know Django's Sphinx ma
Brilliant! Absolutely brilliant!
- Gabriel
On Apr 19, 4:23 pm, Bitrot McGee wrote:
> Q: When will Django finally have every feature I want?
> A: "Ambition has its disappointments to sour us, but never the good
> fortune to satisfy us."
>
> Q: What the fuck is taking so long?
> A: "As we enjo
That's awesome. I'll definitely add to that when I have some time
tonight.
On Apr 20, 2:49 pm, Robert Coup
wrote:
> On Wed, Apr 21, 2010 at 9:12 AM, Jacob Kaplan-Moss wrote:
> > I like this a lot. Especially the "your next steps" part - it makes it
> > very obvious what the next thing interested
gt;> Another bit on proper documentation, some notes on quality, where to get
> >> help, what types of issues need discussion on this list would be great and
> >> I'm sure there's more that could be included with this type of tutorial.
>
> >> On Tue, Apr 20,
I just built something in a similar vein as this for my team's
internal use. Amusingly, I used Django's inspectdb feature to directly
interface with Redmine's database and provide a separate front-end.
The data feeds into a javascript graphing library.
The ability to visualize languishing issues,
I like the idea of having these "bundles" or "stacks" for media. Just
thinking out loud here, if there were a compression engine in play
that could do concatenation as well as minification you could have a
useful syntax for ordered combinations of scripts similar to how
ModelAdmin's fieldsets work
On Apr 22, 1:21 pm, Adam Nelson wrote:
> 2. Assign all of these tickets to 1.3 and nothing else:
>
> http://code.djangoproject.com/query?status=new&status=assigned&status...
A, only 900 tickets to work through for 1.3? Don't go too easy on
the core team! ;-)
All the best,
- Gabriel
--
I've been dancing around this idea for a while. I know it's not a new
thought, and Alex Gaynor and Justin Lilly even started work on "piano
man" [1]... I'd be curious to know what the state of that project is
and if a few more devs working on it might be able to bring it to a
place where it'd be re
I'm in a similar boat to Russell... LaunchPad's UI always seemed like
a complete disaster to me...
However, in reading through LaunchPad's FAQ to give it a fair chance,
I saw a couple of other features that Trac doesn't have to add to the
list:
* Out-of-the-box OpenID support
* "Bug Expiry" to
One of the GSOC projects that was accepted is about updating and
improving Django's test suite. The guy doing it has expressed interest
in using coverage.py to help with the project (whether as a long-term
part of django or just for the GSOC project), so there'll probably be
more concrete informati
On Apr 30, 8:02 am, Jeremy Dunck wrote:
> I haven't heard one proposed. I'll take a look at RedMine and/or
> steal ideas from launchpad -- but writing a new tracker isn't the
> problem I'm trying to solve.
FWIW, I currently use (and administer) Redmine for my company. I'd say
it's only a margi
I'd also be interested in working on this, as long as I'm not alone on
it. Have you and/or Alex set up any kind of mailing list for it? Do
you plan to use git's issue tracker or something else? What's the
process plan for getting development kick-started on it?
- Gabriel
On Apr 30, 11:22 am,
Is it worth upgrading to the 0.11.X branch with Trac 0.12 scheduled to
be out the door within a couple weeks?
On the one hand, a brand new Trac release would be more likely to
contain bugs than a bugfix branch that's now on it's 7th revision. The
configurable workflows and per-user permissions wer
I like the idea of boxing up the autodiscover code into a publicly
accessible utility class... it's a problem many people solve for
themselves (myself included) but even moreso it would go well with the
new startup.py proposal that's in the works.
Once it's easy to have things run once at startup,
Personally, I solved this by writing a wrapper around
django.utils.cache that can be dropped in transparently. It was a
really simple matter to have it take a cache prefix (in my case from
settings.py) and pass that into the original functions.
It's a pretty easy fix if the core team agrees that i
Hi, J. Alheid,
Don't be too afraid to get started. From looking at the history on
that ticket (as well as the current codebase), my guess is that
Jacob's concern is that there's no mechanism in place for handling
what happens to those objects if commit=False. The current patch tells
us what *not*
For the record, the "from settings_default..." method is exactly how
my team's largest projects are deployed. It works just fine for us!
Even more fun (though bordering on too tricky) is converting
INSTALLED_APPS to a set instead of a list so you can add *or* subtract
items.
This whole argument h
Extending the include tag seems like a fantastic idea! I end up
writing the {% with %}{% include %} combo all the time for my reusable
template snippets.
However, I feel like selectively clearing the context inside a
template tag is asking for trouble and/or confusion. It also sounds
like it goes
You're right that formfield_for_manytomany probably ought to be better
documented.
If you aren't sure how to write a patch for the docs, the best thing
to do is to open a ticket for the issue in Trac. That way it will be
logged and someone else can look at it, write a patch, and eventually
get it
Http301 doesn't seem entirely correct to me, however I have found use
for an Http302/HttpLoginRedirect exception that can be raised from
anywhere to handle unauthorized users.
If your authorization process is handled somewhere other than directly
in a view or decorator (like in a manager that chec
multiple tag
libraries and accidentally override your form rendering sounds like a
nightmare. So, whether these become filters, or arguments to the {%
form %} tag, I really can't support them being implicit in the form
tag that gets loaded. No magic here, please!
Those concerns aside, I real
Thanks for the thoughtful reply, Russ! Just a couple quick points:
> As noted in my reply to Preston, this should easily possibly using
> chrome; I'm not sure I see why you disagree. The new options may be
> funcitonal, but from my reading of the HTML5 spec, they're functional
> in terms of UX, no
I'll be there as well! Either set of dates works for me.
- Gabriel
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/hCK2OwboH40J.
To post to t
Options 2 and 4 from that list both involve database-level changes, and
thus aren't feasible (our lack of schema migration tools being the biggest
problem).
Of those, I'd go for option 3 as well. We definitely don't want to store
the full hash in the session for obvious security reasons, but a
FWIF, the code that generates that message is here:
https://code.djangoproject.com/browser/django/trunk/docs/_ext/djangodocs.py#L84
Feel free to open a ticket if you like.
All the best,
- Gabriel
--
You received this message because you are subscribed to the Google Groups
"Django develop
The RHEL/Python 2.4 question was addressed at length not more than a
month ago:
http://groups.google.com/group/django-developers/browse_frm/thread/b7390024b28a694d/f72c272152e968d7
Russell's reply there spells it out as clearly as anyone will be able
to right now...
All the best,
- Gabriel
I ran into this issue with daemons/scheduled jobs and "idle in
transaction" in Django quite a while ago. I have a nice writeup of the
problem and solution on this StackOverflow question if anybody's
interested:
http://stackoverflow.com/questions/1303654/threaded-django-task-doesnt-automatically-ha
I went to triage a few tickets tonight, and noticed that #8960,
#10235, #10608 and #13814 have all arrived at essentially the same
conclusion: there needs to be a single idiomatic way to get either the
current Site object if contrib.sites is installed, or a RequestSite
object if not. All four ticke
rrent Site/RequestSite as well.
- Gabriel
On Sep 30, 11:48 pm, Gabriel Hurley wrote:
> I went to triage a few tickets tonight, and noticed that #8960,
> #10235, #10608 and #13814 have all arrived at essentially the same
> conclusion: there needs to be a single idiomatic way to
Well, looking at those two tickets, #7028 is currently related to the
debate happening on this list ("rethinking raw_id_fields"), so the
best thing to do for that ticket is to actively participate in that
discussion.
For #6903 the ticket is in DDN, which means this is a perfect
opportunity for the
Sorry, that was phrased badly on my part. I meant to imply that if
someone else wrote a patch, he could help by reviewing it...
- Gabriel
On Oct 1, 11:47 am, Jeremy Dunck wrote:
> On Fri, Oct 1, 2010 at 1:41 PM, Gabriel Hurley wrote:
>
> ...
>
> > In both cases, once t
om request:
> request.site with default implementation to LazySite, with default
> implementation of Site.objects.get_current() if sites_installed() or
> RequestSite(request).
>
> That implementation would be overriden with middleware
>
> What do you think?
>
>
>
>
>
> On
when possible.
Thanks!
- Gabriel
On Oct 1, 4:12 am, Luke Plant wrote:
> On Thu, 2010-09-30 at 23:48 -0700, Gabriel Hurley wrote:
> > I went to triage a few tickets tonight, and noticed that #8960,
> > #10235, #10608 and #13814 have all arrived at essentially the same
> >
I added some feedback on the ticket. Looks like a good start!
- Gabriel
On Oct 4, 2:12 pm, Laurent Luce wrote:
> Hello,
>
> I added a patch to this ticket http://code.djangoproject.com/
> ticket/10944">#10944
>
> - add method get_url to Site model to return an absolute url based on
> a relat
You've got two sets of feedback on the ticket now. Basically the code
is good but it needs tests and docs before getting committed. If
you're unsure how to go about writing those, then you can certainly
ask for help here.
All the best,
- Gabriel
On Oct 4, 4:57 pm, Cesar Canassa wrote:
> I am
I think Russell put it very well in pointing out that one of the few
big technological impediments in Trac is that there isn't an easy way
to see the last-modification time of tickets. Particularly to the
point that it's hard to tell when a new patch is uploaded and an
accepted ticket might need ne
There has been repeated talk of putting together resources for new
contributors in a way that's more accessible and to-the-point than the
current contributing docs. Most recently Russell mentioned it in this
thread:
http://groups.google.com/group/django-developers/browse_frm/thread/9ebc3e57d539d1f
If you glance at the revision log for the committers page in the docs,
there are actually a couple more ;-)
http://code.djangoproject.com/log/django/trunk/docs/internals/committers.txt
On Oct 8, 6:15 pm, Łukasz Rekucki wrote:
> I just noticed we have 2 new Core Developers: Alex Gaynor and Andrew
I believe you are correct, since sitemaps are global objects, this
would not be thread-safe. Fixing it should be fairly easy, however.
Setting self.request was only necessary for two reasons:
1. Sitemap.get_urls() uses it, but either the request or the
current_site variable could be easily be pa
Hi alekam,
This is certainly the kind of ticket that we want to deal with in 1.3
since it's been around so long and deferred a couple times. Starting
the discussion here is definitely the right way to make it happen.
That said, at the very least it needs a thorough code review, a full
set of test
> What do you call this. I don't see how any software developer could
> consider constructive criticism as anything other than helping out.
You've posted three messages in this thread, but none of them seem
"constructive" to me. You've pointed out areas of disagreement and
used inflammatory hyperb
I got my first real taste of the new API today by thoroughly proofing
the docs for class-based views. I just wanted to say that there's some
great stuff in there, and I give a big thanks to everyone who
contributed! I'm really looking forward to using the new class-based
views ASAP.
Thanks!
-
Speaking on a semantic level, a "proxy" is a stand-in acting on behalf
of (or in place of) another entity. There is an implied near-
equivalence, but inherent in the idea of a proxy is that it is *not*
the same as the original. As in the case of assigning a proxy to vote
for you in corporate electi
I'd like to call attention to ticket #6707 [1], which deals with the
implementation of ReverseManyRelatedObjectsDescriptor.__set__.
Specifically, the problem is that the current implentation takes a
very efficient "clear everything and add all the keys back in"
approach to managing these relationsh
I see that this issue was also discussed in #13022 [5], wherein Russ
argued that the current signals are technically correct but that
solving #6707 would be worthwhile *if* it could be done efficiently.
[5] http://code.djangoproject.com/ticket/13022
On Oct 20, 2:45 pm, Gabriel Hurley wrote
if you ever have questions about the docs or how to
write patches, I'm happy to help!
All the best,
- Gabriel Hurley
On Nov 1, 2:13 pm, Paul Oswald wrote:
> Is it too late to have the 1.3 Milestone applied to these documentation
> issues?
>
> http://code.djangoproject.com
> Another documentation-related question I have; is it necessary to mark
> each passing referencing (and link) to on_delete with the version-
> added marker? I went back and forth, and eventually decided against
> it, for these reasons: (1) The passing references don't provide enough
> info to use
In a fit of coincidental timing, I was just being frustrated by this
very issue with inclusion tags today. I'm +1 on supporting kwargs with
"=". It is in fact *more* familiar to someone who works with HTML to
be able to assign attributes in arbitrary order, for example:
http://example.com"; class=
+0 on "... as ...".
Either one gets the job done and I'd gladly accept either as they both
solve the same problems.
Thanks!
- Gabriel
On Nov 10, 1:36 am, Jannis Leidel wrote:
> On 10.11.2010, at 09:20, Gabriel Hurley wrote:
>
>
>
>
>
>
>
>
>
>
IP addresses definitely don't belong in plain text since they're a
value... so that option can be ruled out.
Between the other two options, I'm torn: I think that using the
``"some_value"`` notation (quotes inside an inline code block) breaks
the visual flow for what's usually an obvious distincti
> I'm not sure how open the core devs
> are to non-core devs poking around in core parts of the framework
> though.
Anyone and everyone is welcome to write patches for any part of the
framework! There's no sacred portion that only a core dev can touch.
It sounds like you've given thought to the im
> Hmm, I don't agree. They are not 'values' in the Python sense - if I
> type 127.0.0.1 at a Python prompt I get a syntax error. They are no more
> values than integers and floats (less so, by the above definition), and
> we don't put any special markup around numbers. They would become values
> if
I like this idea for an additional reason:
I look at the Django timeline regularly, but I have ticket detail
changes filtered out. Therefore I *don't* see changes like
"unreviewed" -> "accepted", etc. I do, however, see ticket status
changes (closing, reopening, etc.). Thereby these kinds of chang
Having recently set up a Trac installation for another project, I can
tell you that making the actual change will require some hacking in
the trac.ini file. There's no way to do it through the admin.
All the best,
- Gabriel
On Nov 16, 7:02 am, Luke Plant wrote:
> On Tue, 2010-11-16 at 11:34
> Maybe trac can be improved in this respect by notifying
> reviewers when tickets that they have closed, or accepted, or provided
> feedback on, are updated.
In my experience Trac already does that... when a ticket is changed
(by anyone), the reporter, the owner, anyone on the cc list, and
anyone
Bear in mind that this is a *very* old Trac installation... ;-)
I don't have access to that server to see if the TracAdmin module is
current enough to support the "resolution add " command. If so,
that'd be the easy way. If not, like Daniel said, it's straight to the
DB!
- Gabriel
On Nov 16,
> >> Example workflow:
>
> >> * Alice creates a ticket, with an incomplete patch (no tests,
> >> incorrect implementation)
> >> * Bob reviews the patch, marks it "Accepted, needs tests, patch needs
> >> improvement"
> >> * Alice updates the patch, adding tests (but not changing the
> >> implemen
Hi Alex,
Neither of the ideas you mentioned (making auth.user more extensible/
replaceable and improvements to app loading) are new to the Django
community. In fact, both were candidates for last year's Google Summer
of Code. The app loading project even got accepted and had a good deal
of work do
Agreed with Alex. I brought this up on IRC a month or so ago, and the
(small) consensus was that it'd be great to have the ":real markup:"
generate TOC entries the way we want it to, but that doing so involves
hacking Sphinx (or at best writing a plugin for it) and nobody was
ready to jump into tha
#4 seems reasonable to me, with #3 as a runner-up. As you said: the
majority of users can ignore the new setting, which makes it far less
of a burden while still offering flexibility.
All the best,
- Gabriel
On Dec 3, 7:56 pm, Russell Keith-Magee
wrote:
> Hi all,
>
> I've been looking at #14
You wanna hand over your paycheck now, or later? :-)
I know someone with a functional white-hat timing attack script sitting
on their laptop. They've been honing the statistical analysis to get
the number of data points needed down to a less noticeable size, but
the technique can already be succe
I'm in favor of the patch you've provided, Luke. Raising an exception seems
like the best option here to me.
While it *is* a logical error to get the related objects of an unsaved
instance, the current behavior seems buggy and (as Ian Clelland points out)
it can be potentially harmful.
FWIW, I
And that's what I get for having an MLA reference sitting on my desk...
- Gabriel
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group,
On Thursday, January 6, 2011 6:29:32 AM UTC-8, James Bennett wrote:
>
> It'd also be a major
> maintenance/bookkeeping headache and, I think, *more* likely to result
> in us accidentally crossing the streams while trying to keep track of
> what goes on in which branch.
>
I have the same concern her
Adding Yet Another Setting doesn't seem like much of a solution here.
To the original poster's question I'd say that using anything but dashes for
slugify would be very uncommon, but I don't see any reason why the slugify
filter *couldn't* take an optional parameter to define what token should b
I did actually just come up with two problems involved in having a
customizable separator for slugify:
1) SlugField would also have to take a parameter to define the separator so
that there wouldn't be inconsistencies in the output of SlugField and
slugify. This seems like it would be a big pit
Though technically accurate, I would say it goes against the rest of the
purpose of that filter: "human readable".
And though technically inaccurate, everyone from hard drive manufacturers to
major web companies use KB, MB, etc. to represent filesizes. I'd argue that
it's become a de facto (if
I would be more in favor of seeing a new setting to configure
`get_current_site()` than seeing the existing `SITE_ID` setting shoehorned
into a new purpose (and being permanently misnamed for legacy reasons). For
the sake of allowing complete customization of the site lookup process I
suppose a
I haven't been tracking it closely, but last I heard on the subject is that
it's on target for the 1.4 release cycle. So basically once we get 1.3
pushed out (and have a little rest) that'll be towards the top of the heap
to be wrapped up and worked into trunk. There's almost certainly still som
On Wednesday, January 19, 2011 12:01:57 PM UTC-8, Carl Meyer wrote:
>
> Contrib.flatpages is an example
> of this -- the flatpage model has an FK to Site, so it doesn't make
> sense for flatpages to call a method which might return a Site object
> or might return something else. It needs a real
If you try this in any of the more recent versions (sorry I don't know
exactly when this was changed) you'll get a ViewDoesNotExist exception
telling you which view in which module it couldn't find. If you have DEBUG =
True you'll get a nice Django 500 error debug page giving you everything you
As Russ mentioned, check out ticket #14401 [1], and its associated wiki page
[2]. Those should offer some more insight. That ticket was my pet project to
start and it's come time to finish it (the vagaries of the real world be
damned).
If you have particular aspects you'd like to see better exp
write it up in reST, so
now's the time to make your voices heard!
Thanks so much,
- Gabriel Hurley
--
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.co
Hi Vivek,
It's great to hear you're interested in contributing! This year's GSOC is
just getting underway and while Django will likely participate as it has in
years past, we're not quite at that stage yet.
However, if you're serious about GSOC you'll have a much better chance of
being selecte
1 - 100 of 132 matches
Mail list logo
