On Mon, Oct 24, 2022 at 6:33 PM Andrew Godwin wrote:
> It has not. While I cannot speak for the other members of the Board, I got
> burnt out in 2019, and then the pandemic began, and so it has not really
> been something I've pushed for in the past three years (and I believe I was
> one of the d
I'm going to avoid trying to get too much into point-by-point
back-and-forth argument here, and try to present the larger picture.
The Technical Board has multiple active responsibilities under DEP 10.
Let's look at some of them:
1. Canvas for feature proposals once per feature release of Django.
On Wed, Oct 26, 2022 at 12:02 PM Andrew Godwin wrote:
> At this point, it is my view that it is our job to govern with the people
> we have, and the time and energy they can provide, and that's my intention
> with these suggested changes.
>
If the problem in front of us is that the Technical Boa
Organizing sprints is a fine idea, but:
* They should be designed around the assumption of remote-first, not
"hybrid" or in-person-first, and there should be no language in the
description whatsoever about in-person participation being important. There
simply are too many factors involved in tryin
On Wed, Oct 26, 2022 at 4:34 PM Andrew Godwin wrote:
> I have copied in the DSF Members mailing list as it is a
> governance-related DEP, but if we could keep all discussion on the thread
> in the Django Developers mailing list, as per DEP 0001, that would be great.
>
My main concern remains the
On Fri, Nov 25, 2022 at 2:32 PM 'Adam Johnson' via Django developers 1.
CORS in core
>
> django-cors-headers’ implementation is a bit janky, for example it uses a
> regex to filter paths. It also lacks the key ability to set up different
> CORS policies per path. Both of these could be done with a
It feels like this needs to be a broader conversation about not just
changing DATABASES to accept a URL, or integrating a particular
database-settings project, but to re-think how Django does
settings-from-environment as a whole.
When I'm setting up new Django-based projects, django-environ
(https
https://code.djangoproject.com/ticket/34063
The short summary of that ticket is that there was a significant
behavioral difference between django.test.Client and
django.test.AsyncClient: with AsyncClient, any view or middleware
which attempted to access request.POST without first accessing
request
On Fri, Dec 30, 2022 at 12:01 AM Carlton Gibson
wrote:
> When I looked at the trace you posted in IRC yesterday, my first thought was
> "3.2?". I think supporting Django 3.2 at this point isn't worth the effort.
It's also broken in 4.0 and 4.1. I just posted the first trace I got
back from my te
On Fri, Dec 30, 2022 at 1:09 AM Carlton Gibson wrote:
> All you're talking about is adding this to your test cases right?
>
> # Work around Django #34063 until 4.2.
> request.body
As far as I can tell it needs to go in whatever code will *read*
request.POST, not the code that generates the reques
On Fri, Dec 30, 2022 at 1:27 AM Carlton Gibson wrote:
> It's frustrating when this happens, but the backport policy has proven its
> worth time and again.
> I **really** don't see the case for making an exception here.
> (The policy has more value than the inconvenience in any of these cases, or
On Fri, Dec 30, 2022 at 2:04 AM Carlton Gibson
wrote:
> No it's not. It's a bug in AsyncClient and AsyncRequestFactory, that means
> if you're using those on older versions of Django, you'll need to work
> around.
> This is no different than any of a thousand other cases where there's been
> a bu
I have put it to the Steering Council:
https://forum.djangoproject.com/t/request-for-technical-board-steering-council-vote-requested-backport-ticket-34063/17920/1
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" g
On Fri, Dec 30, 2022 at 2:24 PM Tim Graham wrote:
> As perfectionists, it's always hard to say (and hear) "no" when this sort of
> request comes up.
I wrote a 2,000-word argument explaining why I believe this warrants
backporting. I think that deserves more engagement than just a "no".
> I'm un
On Fri, Dec 30, 2022 at 11:22 PM Carlton Gibson
wrote:
> Under normal circumstances you just use the sync Client, as you've always
> done. `response = client.get(`/my-async-view/`)`.
> Django handles that the **view** is async for you.
>
> It's only if you need to write an actual **async test**,
On Sat, Dec 31, 2022 at 2:12 AM 'Adam Johnson' via Django developers
(Contributions to Django itself)
wrote:
> In the past I have also been frustrated at particular bug fixes not being
> backported. But I've gradually come to appreciate just how valuable the
> backport policy is. It keeps Django
On Sun, Jan 1, 2023 at 12:54 PM Tim Graham wrote:
> Older Django releases are currently maintained with minimal support that
> allows existing projects to continue running securely. I don't think we
> should invest resources in promoting them as a place to use experimental
> features. A benefit
On Sun, Jan 1, 2023 at 7:01 PM Tim Graham wrote:
> Incidentally, I don't think it's important for the ultimate decision here,
> but I looked at the below analysis of ticket #32189. Carlton's analysis on
> the ticket that request.POST is empty when using 'content-type':
> 'application/json' rema
On Thu, Mar 9, 2023 at 10:27 AM 'Adam Johnson' via Django developers
(Contributions to Django itself) wrote:
> The Django project has a .gitignore file:
> https://github.com/django/django/blob/main/.gitignore
>
I think this person was asking for the default ‘startproject’ template to
include a mi
On Tue, Aug 6, 2024 at 4:37 PM אורי wrote:
> No. I didn't see in the documentation of LoginRequiredMiddleware
> any MIDDLEWARE setting.
>
>
> https://docs.djangoproject.com/en/5.1/ref/middleware/#django.contrib.auth.middleware.LoginRequiredMiddleware
>
>
> https://docs.djangoproject.com/en/5.1/re
On 11/14/05, Radek Svarz <[EMAIL PROTECTED]> wrote:
> I believe that PythonistL did not asked about running it on CGI. He asked to
> run it on the shared webhosting. And noted some issues.
Django runs perfectly well on shared hosting. Plenty of hosts out
there offer Python/FCGI which is perfectly
On 11/14/05, Stephen Rainey <[EMAIL PROTECTED]> wrote:
> I agree with you that it's pure marketing fluff and I guess you see that
> was my point. It just got me to thinking when I was reading about
> developer adoption. I do like your lightweight ideas. It might be good
> to do something rather l
On 11/14/05, limodou <[EMAIL PROTECTED]> wrote:
> I want to know if there is easy way to create form?
You might want to look over this:
http://www.djangoproject.com/documentation/forms/
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
On 11/14/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> I don't recall anybody proposing "AJAX in the core".
I've seen it asked for more than once, particularly in the IRC
channel. People ask for Django to pick one AJAX library and integrate
it. To me, that's "AJAX in the core".
> While Ajax i
On 11/14/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> 1) Let's keep different forums separate. I hope you responded to those
> unnamed guys in the IRC channel.
> 2) My car has an integrated CD-player. Does it mean it is "in the core"? I
> respectfully disagree with your definition of "in the c
On 11/14/05, hugo <[EMAIL PROTECTED]> wrote:
> Actually the only thing I can think of that would be good if django had
> it, would be a REST style API to access model stuff that automatically
> will be returned in JSON format. That would allow JavaScript code to do
> easy database queries without
I've been poking around through the bundled comments app, trying to
work out exactly what it can do and how to use it (also looking
through the djangoproject.com code for hints), and it looks to be
incredibly robust and useful; is there any ETA for documentation for
it? Just basic tips on weblog-s
On 11/15/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> What are these mysterious "AJAX effects" you talking about in your posts? Is
> it the same as "AJAX in the core" or different beast?
As I mentioned in an earlier message, many "AJAX libraries" provide a
large stable of DHTML components whi
On 11/15/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> What problem does this actually solve? Why do you care that people would
> use a bundled JS library? Should we also excise the template system from
> Django to avoid offending Kid? The ORM to avoid offending SQL object?
> What would be left?
On 11/15/05, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> We're looking for a volunteer to update and maintain Django's FAQ
> (http://www.djangoproject.com/documentation/faq/). It's pretty
> unhelpful at the moment, unfortunately. We'd love it if someone
> could become the FAQ maintainer and k
On 11/15/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> Now I am confused. AJAX stands for Asynchronous JavaScript And XML. But
> "AJAX effects" == visual effects?
Many so-called "AJAX libraries" are as heavy on the "visual DHTML
effects for use with AJAX" as on the actual meat of "AJAX" itself
On 11/15/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Yes, it's a very useful snippet indeed. :) It's on the documentation
> to-do list; I'd like to get it out of the way this week.
Huzzah!
Thanks, Adrian.
--
"May the forces of evil become confused on the way to your house."
-- George Ca
On 11/16/05, hugo <[EMAIL PROTECTED]> wrote:
> keep in mind that things should at least have lower-level APIs that
> could be used even if the selected toolkit isn't used itself, but some
> other toolkit is.
Again, +1. Some sort of (hopefully RESTful) API which can respond to
queries and toss bac
On 11/20/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> I just saw http://code.djangoproject.com/ticket/853 , which advocates
> simplifying Django's first-time user experience as much as possible.
> I think this is an admirable goal, and one that would dramatically
> improve the number of people
Just a quick comparison, since I'm working on learning Rails at the moment...
With the proposed changes to models and views, starting a Django
project and adding an application creates this structure:
project/
apps/
appname/
models.py
views.py
settings.py
On 11/20/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> I see it as an indicator of good architectural design rather than
> something people should regularly use.
In that case I'm even more suspicious of it; it smells a little of
TMTOWTDI, and it raises the question of why we'd provide a "good
a
On 11/22/05, Beorn <[EMAIL PROTECTED]> wrote:
> There are two parts to "ease of learning". One is how easy it is to
> get started, the other is how easy it is to keep going. Ruby does
> pretty well on both fronts.
One of the things that bothers me about Rails is that you get the
"instant gratif
On 11/23/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> Pluralisation is a nice idea in theory, but in practise it causes
> more problems (in terms of confusion over whether something is
> singular or plural) than it solves.
Sounds good, though the verbose_name_plural and/or module_name
attribut
On 11/23/05, Beorn <[EMAIL PROTECTED]> wrote:
>
> I don't think scaffolding is bad just because it can't support all
> admin interface situations. It's great while you're prototyping, and
> may be perfectly fine for many applications where you just want a
> simple admin interface. Django's admin
On 11/23/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> In defence of live introspection, Matt Biddulph made the excellent
> point at the web frameworks night earlier this week that the Rails
> method is extremely useful early on in your design process when you
> are rapidly iterating your DB des
On 11/23/05, hugo <[EMAIL PROTECTED]> wrote:
> Actually I think that verbose_name_plural should go and instead of
> that, an class method for proper pluralization should be added:
Even better. That gets my vote.
--
"May the forces of evil become confused on the way to your house."
-- George Ca
On 11/24/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> The way we are using it at the moment (listing sites powered by
> Django, detailing backwards incompatible changes etc) is great. I
> think we should expand our promotion of it to encourage more user-
> generated documentation. Just a few mo
On 11/24/05, Simon Willison <[EMAIL PROTECTED]> wrote:
> There's a list of user-contributed documentation on the front page of
> the wiki which you are welcome to add things to:
OK. I'd seen that, but at first glance I didn't catch the link to
Ian's presentation and so it seemed like they were al
On 12/6/05, Maniac <[EMAIL PROTECTED]> wrote:
> So when the view's code change during development one should alsways
> remember to update this invalidators list. Not very DRY :-(
Except it's a decorator, so it's right there with your view code.
--
"May the forces of evil become confused on the
On 12/6/05, Maniac <[EMAIL PROTECTED]> wrote:
> But still you have to blindly copy strings from code to decorator
> parameters.
Any way of implementing this is going to require you to specify
*somewhere* which GET parameters are relevant to caching a particular
view, and it'd be hard to implement
On 12/7/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Thoughts?
Models: +1, hooray for properties.
DB connections: +1
Object creation/model import: +1
Table-level functions: -0, there may be good underlying reasons for
it, but it strikes me as needless cluttering of the syntax.
Overriding:
On 12/10/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> Dojo seems to rely on adding its own unnamespaced attributes to normal
> elements. Is this compatible with strict use of XHTML?
No, it's not; this would result in a yellow screen of death if a page
were served as application/xhtml+xml. Also
On 12/11/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> changing to:
>
> reporter.articles
> reporter.articles.filter(headline__startswith='This').order_by('headline')
> reporter.articles.add(headline="John's second story",
> pub_date=datetime(2005, 7, 29))
>
> And
>
> changing to:
>
> article.re
On 12/11/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
> Its pretty orthogonal to most of the other suggestions.
Yeah, but as proposed lookup syntaxes go, this one is by far the best.
And implementing special methods like __len__ would make it just about
perfect, IMHO; the closer we can get to mo
On 12/12/05, Radek Svarz <[EMAIL PROTECTED]> wrote:
> very nice proposal. but please avoid pluralization. it is very odd in other
> languages than English.
I think pluralization is something to be dealt with elsewhere; so long
as this takes advantage of module_name, verbose_name and/or
verbose_na
On 12/12/05, Radek Svarz <[EMAIL PROTECTED]> wrote:
> so I think it should be either:
> 1.
>reporter.article.add(...)
>article.reporter.id
>
> or:
> 2.
>reporter.articles.add(...)
>articles.reporter.id
>
To me, the pluralization makes sense; a reporter has many articles, so
'a
On 12/12/05, Radek Svarz <[EMAIL PROTECTED]> wrote:
> the issue is, how do you define the pluralization. just adding s at the end
> works only in some cases and does not usually work in other languages. (eg.
> in Czech: class Anketa - plural is ankety not anketas)
Currently, with verbose_name_pl
On 12/12/05, Radek Svarz <[EMAIL PROTECTED]> wrote:
> Ie. verbose_name_plural defines the name for code (object instances)? Based
> on the tutorial I thought it is mostly used for admin presentation texts.
Well, in part I misspoke. What you want is both module_name and
verbose_name_plural.
--
"
On 12/12/05, oggie rob <[EMAIL PROTECTED]> wrote:
> The "len" idea is not great anyway - it is much more costly to get and
> len 10,000 rows than to use SQL count, as get_article_count does.
I would hope that the __len__ method would be implemented as something
that does an SQL count.
--
"May t
On 12/12/05, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> I think all in all it's a good idea, but I do have one big objection:
> one of the things that's always bugged me about ORMs is that they
> shield you from knowing when you're hitting the database. This sucks
> when it comes time to opti
On 12/14/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Or maybe get rid of the "models" cruft:
>
> /admin/myproject/blog/entry/add/
+1
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
On 12/31/05, limodou <[EMAIL PROTECTED]> wrote:
> I know that in url dispatcher, I can get a parameter from the regular
> expression, and then pass it to a method which need it. But I wish I
> can also get the parameters from other places, e.g. POST, cookie, etc.
> It seems that I couldn't do that
In the IRC channel tonight there was some discussion (mostly motivated
by ticket #1204) about template tags and filters failing silently,
particularly those in the markup app. Since it was kind of late and
people were popping in and out it sputtered, but I think it's an
interesting topic to bring
On 1/12/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> Thinking about this further, it could result in a security hole. If a
> filter that removes dangerous markup failed silently and that markup
> was spewed on to a page it could lead to an XSS vulnerability.
I would hope that the author of suc
On 1/14/06, Simon Willison <[EMAIL PROTECTED]> wrote:
> Basically, you define your own inner class called "Manager" if you want
> to add custom methods to Person.objects (or modify the behaviour of
> existing methods). If you don't define this inner class the default
> Manager will be used.
I can
On 1/16/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
> On 1/16/06, nikki <[EMAIL PROTECTED]> wrote:
> > Ok your take is appreciated since it is somewhat different then the
> > common mis?understanding. The common lore on MySQL is that its good
> > enof for Google, Yahoo, Amazon so
On 2/10/06, limodou <[EMAIL PROTECTED]> wrote:
> Maybe you consider that it's nothing, so I think you also don't want a
> tool to do that for you automatically. But I want, and I think maybe
> someone else want also.
What, exactly, is it about Python files which make it, in your view,
unreasonabl
On 2/10/06, limodou <[EMAIL PROTECTED]> wrote:
> So what I mean not about HOW TO READ settings from settings.py, but
> HOW TO MODIFY settings.py and urls.py.
Well, one way would be to import the settings module of the project
under a name like 'mysettings' (e.g., 'import myproject.settings as
mys
On 3/1/06, xamdam <[EMAIL PROTECTED]> wrote:
> Using no-magic branch from about a couple of weeks ago.
If possible, update your copy of magic-removal to the latest revision;
there's been a HUGE amount of work done on it recently, and if this is
a bug it may already have been fixed. If you still s
On 3/2/06, limodou <[EMAIL PROTECTED]> wrote:
> Django is developing very quickly, so many things to catch up.
> Has anyone written a change logs let us know the latest changes you.
Does the Trac timeline not count? ;)
--
"May the forces of evil become confused on the way to your house."
-- Ge
On 3/6/06, Kevin <[EMAIL PROTECTED]> wrote:
> The generic views use RequestContext (was DjangoContext) and that
> requires request.user be set.
>
> I'd be nice if that middleware dependency could be removed since my
> site never needs authentication and so the extra middleware is
> redundant.
I'd
Someone in the IRC channel tonight was asking why the built-in User
model, when rendered by formfields, doesn't render the password field
as an input of type "password", and it struck me that this is a good
question, because there are plenty of use cases where you'd want that
behavior to happen.
On 3/13/06, limodou <[EMAIL PROTECTED]> wrote:
> -1 I agree with gabor. Many orm models don't process validation, and
> these things should be implemented by manipulator. Why do so much
> things in model?
Among other things, the model is the place where the types of data are
specified for a parti
On 3/13/06, limodou <[EMAIL PROTECTED]> wrote:
> In most cases we do not do anything alone use model, but always there
> is a ui layer, such as gui or web. They have to do any such thing.
There should be the ability to generate an HTML form for
creating/changing an instance of a model, yes, but t
On 3/13/06, limodou <[EMAIL PROTECTED]> wrote:
> Maybe or maybe not. What django has implemented is exactly as what I
> said, I think the ways is good. And I remember there was a discussion
> about js invalidation, why we need this. Because we want to make
> mistakes can be found early, but not un
On 3/14/06, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> This is based on a simplistic assumption that everytime we are talking about
> validation in django context we are talking about model based validation.
No, it's based on an assumption that the facilities for doing custom
validation that curr
Last night in #django a couple of good points were brought up by
someone who was just starting to explore Django and had decided to
learn from magic-removal rather than trunk; both of them, I think, are
worthy of discussion, so here goes:
1. The new example of usage for a generic view is counteri
On 3/19/06, gismo <[EMAIL PROTECTED]> wrote:
> I know I can change the extension. But there is a lot of editors,
> people write some extension for them, and only way to handle file type
> is the extensions.
On some operating systems, that's true, but not all.
> Everytime template act like html b
On 3/19/06, limodou <[EMAIL PROTECTED]> wrote:
> But there is no editor can deal with django template, so .html maybe
> the most suitable file extension.
TextMate has a bundle for Django templates.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
--~--~--
On 3/19/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I think good documentation is the best way to solve this one.
...snip...
> Assuming the URLconf is in a file "urls.py" and the models are in a
> file "models.py" in the same directory, you can just do this:
>
> from models import Entry
On 3/21/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> Actually, the availability of connection splitting/pooling tools for
> various backends makes me less inclined to want to add it to Django,
> but that's all academic now :)
I like multiple-backend support for the express purpose of doing
On 3/23/06, Wilson Miner <[EMAIL PROTECTED]> wrote:
> Too crufty to wrap it in a div class="description" so I can set it off
> somehow in the styles?
How about p class="description"? It's a bit more semantic.
--
"May the forces of evil become confused on the way to your house."
-- George Carli
On 3/24/06, David S. <[EMAIL PROTECTED]> wrote:
> I am wondering if it is still planned to release some Dojo integration soon
> and if there is any idea what that will look like.
I've been working on the Dojo/Django integration, and I'm pretty close
to having something that works and that I can
On 3/24/06, David S. <[EMAIL PROTECTED]> wrote:
> Sounds thorough. Are there plans for templates to support this, ala Rails
> helpers? It would be nice to use the events system to full effect so perhaps
> that sort of helper/template tag idea would not work very well.
I'm not planning to implem
Quick update: I now have a magic-removal install with all of the admin
JS ported to Dojo packages. There are some crufty bits that still need
to be cleaned up, but it works!
Next step: I need to know what sort of Dojo functionality people are
going to rely on, because we're going to have to do a
On 3/28/06, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> From the top of my head we need dojo.io, but I assume it is included
> indirectly by other packages.
Ack. Yeah, I just forgot that one when I compiled my list.
--
"May the forces of evil become confused on the way to your house."
-- Geor
On 3/28/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> If possible I would like to see dojo *not* included in django's SVN repo.
> just a pointer to where DOJO is installed on your docroot should be
> sufficent for most things, and remove the need to figure out what
> things should/shoiuldn't be i
On 4/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Is there any mecanism of database connection pooling in django ?
Not at the moment, but some of the changes in the magic-removal branch
seem like they'd make this much easier to implement in the future.
--
"May the forces of evil become c
I've just finished up the first attempt at Django/Dojo integration;
this is, essentially, the Django admin app refactored to make use
exclusively of Dojo packages (both from Dojo itself and from a custom
Django namespace) for all its JavaScript needs. So I've bundled it up
and made it available fo
One more thing I forgot: though the Dojo "Event + I/O editon" dojo.js
provides all the Dojo modules the admin needs at the moment, the
package includes a full Dojo source tree, so if you want to start
playing with this and improving it or experimenting with things you've
wanted to do once Dojo/Dja
On 4/4/06, Bryan Chow <[EMAIL PROTECTED]> wrote:
> One issue I noticed is that the calendar and clock widgets do not
> render properly on Firefox -- they're positioned above the top of the
> page instead of beside the field.
What version of Firefox are you using? I'm unable to replicate that
with
On 4/4/06, Bryan Chow <[EMAIL PROTECTED]> wrote:
> Tested on Debian Sarge (Firefox from backports.org) and Windows XP.
That's extremely weird... I just set up a fresh copy and tested on FF
1.5 on Ubuntu, and it looks fine. It also was fine on FF 1.5 on a Mac
at work. Could you completely clear yo
On 4/4/06, limodou <[EMAIL PROTECTED]> wrote:
> And there are many people except me consider that: django need a good
> urls system:
You've taken this completely out of context; as I understand it, Jacob
and Adrian were not saying that the *entire* URL system should be
replaced, only that the 'ge
On 4/4/06, Bryan Chow <[EMAIL PROTECTED]> wrote:
> I just realized that both the calendar and clock widgets were within a
> fieldset with 'classes': 'collapse'
Hmm. I'll try that tomorrow and see if I can replicate it and find out
what causes it.
--
"May the forces of evil become confused on the
On 4/4/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> * I want to do url configuration in exactly one place
One place for each project? One place for each application? One place
for each model? The problem is that each of these has perfectly valid
use cases for wanting to specify its own URL st
On 4/4/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> I feared this might turn out a problem. I haven't so much experience
> with different projecs, can you explain a litte about the problems with
> this?
Tying the URL structure to the internals of the application's code,
which is what you seem
On 4/4/06, Bryan Chow <[EMAIL PROTECTED]> wrote:
> I just realized that both the calendar and clock widgets were within a
> fieldset with 'classes': 'collapse'
I've got a test app running with date/time fields inside a collapsed
fieldset, and it's rendering just fine in all the browsers I can thr
On 4/4/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Have you read through the proposal? I don't tie the URL structure to the
> internals of of the application's code. Quite to the opposite.
Then why did the original email say that it would "tie the urls to the
field names in the model"?
--
"
On 4/4/06, James Bennett <[EMAIL PROTECTED]> wrote:
> On 4/4/06, Bryan Chow <[EMAIL PROTECTED]> wrote:
> > I just realized that both the calendar and clock widgets were within a
> > fieldset with 'classes': 'collapse'
OK, now I'm able to replic
On 4/4/06, Bryan Chow <[EMAIL PROTECTED]> wrote:
> I just realized that both the calendar and clock widgets were within a
> fieldset with 'classes': 'collapse'
http://files.shtuff.us/admin-dojo.tgz
Fixed now :)
--
"May the forces of evil become confused on the way to your house."
-- George Ca
On 4/7/06, Rudolph <[EMAIL PROTECTED]> wrote:
> Put this line:
> {{ app.name }}
> above the for loop instead of inside it.
Weird... I submitted the patch that added the captions, and that's how
it is on my working copy, but somehow in generating the diff that line
got moved. Best solution for thi
On 4/7/06, Rudolph <[EMAIL PROTECTED]> wrote:
> It could be solved by putting the django-admin stuff inside a tag with
> a django-admin class. Then ".django-admin p" or ".django-admin
> #content" will format only the admin stuff and not your site.
It could be, but I think I'm with Wilson in feeli
On 4/8/06, Petar Mariæ <[EMAIL PROTECTED]> wrote:
> I suggest we change urlify.js in a way that will not block out
> non-English chars. Instead it should translate them into their English
> feel-a-like, as suggested in #1602.
If we decide to go the sound-alike route, a good resource to start
from
A good question was just raised by a friend of mine who's trying out
Django: we encourage the use of a URLConf for each application to
ensure pluggability, but manage.py doesn't create one when you start a
new app.
How would people feel about changing that so that 'manage.py startapp'
creates a u
On 4/13/06, Bjørn Stabell <[EMAIL PROTECTED]> wrote:
> Could you make it available as a patch against the latest magic-removal
> branch?
Already done; it's in Trac: http://code.djangoproject.com/ticket/1613
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
401 - 500 of 1014 matches
Mail list logo
