On 9/24/07, Ludovico Magnocavallo <[EMAIL PROTECTED]> wrote:
> I have always read that Django does not support model inheritance or
> subclassing, but in my experience some forms of it work. Take the
> following for example, straight from a running app:
It used to work in older versions of
On 9/24/07, Sebastien Lannez <[EMAIL PROTECTED]> wrote:
> Is it a limitation of SQLLite ? If not, how can we implement this
> mapping ?
Django does not currently support any form of subclassing or
inheritance for model classes. Please search the archives of this
list, the django-developers list,
On 9/24/07, 张沈鹏(电子科大08年本科应届) <[EMAIL PROTECTED]> wrote:
> why create and get_or_create can't use id to set foerign key ?
Read the documentation for 'get_or_create', specifically for the
'defaults' keyword argument it accepts.
--
"Bureaucrat Conrad, you are technically correct -- the best kind
On 9/21/07, Brian Harring <[EMAIL PROTECTED]> wrote:
> The only spot I can see this potentially causing issues is for
> the 'literal' fast pathing, since it just reuses what was passed in-
> forcing that to unicode in __init__ ought to resolve that. If it's
> something other then that,
On 9/21/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> Please, read my whole post.
> I don't want to create my own implementation of filters.
> I don't want to create my own implementation of changelist sorting.
> etc.
If you don't need a custom implementation of those bits, don't write
custom
On 9/21/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> I like newforms-admin very much, because it's customizeable.
> But now imagine that you have 10 usual models in admin interface, but
> 11th needs to be special.
> One possible example: you need to show, how much LogEntries for each
> model was
While I'm all in favor of faster template variable resolution, I've
been poking at the new Variable class and noticed that the patch was
apparently never updated for a post-Unicode Django; in some fairly
simple tests I've been able to break it pretty badly by passing in
Unicode strings and
On 9/19/07, David Cramer <[EMAIL PROTECTED]> wrote:
> I don't believe .create() allows you to say myforeignkey=1, correct me
> if I'm wrong, but I think it throws an error about it needing to be a
> instance.
OK, so let's do this exhaustively.
>>> my_id = 3
>>>
On 9/19/07, David Cramer <[EMAIL PROTECTED]> wrote:
> Yes, my biggest argument is I want to use .get_or_create() and I don't
> have an instance of the row (the id) I'm trying to insert. I'm *not*
> going to query for this instance (I'll write SQL before I add extra
> queries just to do an
On 9/16/07, Christopher Lenz <[EMAIL PROTECTED]> wrote:
> contrib.formtools.FormPreview implements a different kind of
> approach, and can't be used for this.
I would personally think that, if there's a need for this, the
solution would be to extend or subclass FormPreview somehow to enable
it,
And now that I've marked #5515 accepted, I'm done.
Couple more "master tickets":
* Pagination template tags: #3169
* SQLite "off by one" date filtering errors: #3689
* Generic views unit tests: #5506
The mighty effbot informs me that, since the sprint started:
237 commits
413 tickets closed
On 9/16/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> s/would/will/ -- I'm gonna try to have this wrapped up in the next couple
> days.
Cool. I've paused for a bit of a break, but here's some info on what
I've been doing.
My process today has been to simply go to the big list of open
And a nice number to think about with respect to this sprint:
When I started this morning, effbot's timeline scraper showed 278
tickets closed since the start of the sprint. As of the last update
seven minutes ago, it shows 402 tickets closed.
We should do this more often :)
--
"Bureaucrat
On 9/16/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> I noticed a small problem in a change to some admin docs for a patch I
> submitted that was accepted. Should I reopen the closed ticket and
> attach the patch to it or should I create a new ticket and reference the
> first one?
Re-open with a
While scanning the open tickets list I noticed there are lot of
tickets which fall into the following categories:
* Requests for very specific admin customizations which will be
obsoleted by newforms-admin, or which are already possible with the
limited customization offered by the current
On 9/15/07, Robert Coup <[EMAIL PROTECTED]> wrote:
> I think something changed a while back. Try creating an account at the
> url below, then log in and enter your email address/name into Trac
> like normal. Its linked (not particularly clearly from the
> contributing page).
It's not technically
On 9/6/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> No problem that we didn't have an update this past week. As for next
> weekend, I'll be really busy myself, but I might be able to do a quick
> roundup.
If it'll be of any help, I'll already be keeping an eye on stuff
pretty closely during
On 9/5/07, Ilya Semenov <[EMAIL PROTECTED]> wrote:
> There's a core class django.db.models.loading.AppCache which populates
> the list of project apps and models. It works pretty well unless a
> specific set of conditions is met.
My comment_utils app had this issue for a while, too, since I was
On 8/26/07, David Larlet <[EMAIL PROTECTED]> wrote:
> I agree that users do not try to read the local docs for the moment,
> but maybe it's because the ReST style discourage them to do so. Let's
> try to add html doc with the djangoproject's css and maybe more users
> will use local docs. A lot
On 8/26/07, Sandro Dentella <[EMAIL PROTECTED]> wrote:
> While I completely agree on what you say, I'd point out that not only
> differences from 0.96 to trunk should be noted, if possible, but also
> between svn versions following latest release. As an example when
> test.clinet.login changed
And after we checked in an updated tutorial with admonitions
explaining the exact source of the error for those who run into it, we
*still* got someone opening a ticket telling us the tutorial needs to
use "maxlength" instead of "max_length".
How about if we just go back to "maxlength" for even
On 8/25/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> However I don't see any other way to kill the max_length problem. One
> the one hand, the max_length problem is is an RTFM issue - but on the
> other hand, if multiple users keep making the the same error over and
> over again, there
On Aug 17, 12:00 pm, Gary Wilson <[EMAIL PROTECTED]> wrote:
> Yes, I do not like the idea of adding a new order_by parameter
> either. However, there is a bit of an issue involving the
> archive_index view though because it also uses a num_latest parameter,
> IMHO implying that the items will be
On 8/18/07, Szekeres István <[EMAIL PROTECTED]> wrote:
> In [5]: u=User()
> I think it is a problem that this is
> - not mentioned in the documentation
> - not handled anywhere in django code.
This is what the forms and validation systems are for -- to enable you
to validate data before trying
On 8/17/07, Deryck Hodge <[EMAIL PROTECTED]> wrote:
> So instead of 0.97-pre the version would be 0.97-pre-SVN-5919. This
> might help make it easier to track down what revision people are
> running since so many of us run off trunk. This, of course, would
> have no impact on official releases.
And I just realized I missed #3134, which argued for a slightly
different solution, in the form of an 'order_by' parameter to the
views.
Personally, I think it's easier to just skip the parameter and rely on
the fact that you can apply whatever ordering you like to the QuerySet
before passing it
After being somewhat startled by the results of the archive_year
generic view and finding that the source of my confusion was an
explicit "order_by()" being done in that view, and finding another in
archive_index, I opened #5188 with a patch which removes these calls
to "order_by()".
I think the
On 8/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Proposal #1 seems simpler, but this is not a strong opinion. :-)
The only thing that's keeping me from posting a patch for this right
now with option 1 is a lingering doubt about whether one of the
queries would be preferable; in the
The generic archive_month view has had some problems in the past with
"off-by-one"-style errors; see, for example, #992, nostalgic for me
because it was the first patch of mine ever accepted into Django.
Unfortunately, the view now includes too *much* instead of too little,
as mentioned in #3031,
After a little bit of chat with SmileyChris on IRC, a suggestion for
the "design decision needed" backlog:
It'd be stupid easy to write an app which slurps open tickets that are
at "DDN", and lists them with an up-or-down vote interface (courtesy
of Jonathan's django-voting app). Apache-style
While closing out a duplicate ticket tonight, I noticed that the
original was only a month old,
and did a bit of subtraction. The frightening result: we've had about
three hundred new tickets filed since that time. Meanwhile, there are
currently over three hundred and twenty tickets sitting stuck
On 8/8/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> A couple of other areas are going to be at least equally as
> interesting...
I hereby amend my list of worries to include Malcolm's ;)
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
On 8/8/07, Tom Tobin <[EMAIL PROTECTED]> wrote:
> I'd ideally like the Django installer to detect if django.template was
> already on the system, and drop Django into the same spot. As far as
> versioning, Django should check for a minimum version of Django
> templates (i.e., the version at the
On 8/7/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> I want to hear the use-case first. I may change my mind, but nobody's
> come up with a good reason so far.
I think Tom's primary goal is to provide an easy path to use the
Django template system in non-HTML contexts without having to
On 8/6/07, Alex Nikolaenkov <[EMAIL PROTECTED]> wrote:
> Can you publish your plan concerning contributing applications? The first
> thing I'll do in django & python will be typography support.
You might want to have a look at this before starting your own project:
On 8/5/07, Brett Hoerner <[EMAIL PROTECTED]> wrote:
> Not on our live site. And I just made a fresh django-trunk project to
> test it, didn't work there either. Although aren't resolvers just
> normal Python REs, so you could possibly have set this for yourself
> somehow?
I'm almost certain it
Finger slipped on the "send" shortcut, continuing where I left off...
On 8/5/07, James Bennett <[EMAIL PROTECTED]> wrote:
> And again, I'll reiterate that the type of user who doesn't understand
> case-sensitivity is the type of user who -- verified by repeated
> rea
On 8/5/07, Alex Nikolaenkov <[EMAIL PROTECTED]> wrote:
> Imagine that your site hosting photos has got the following urls
> belonging to different users:
> http://mysite.com/John/
> http://mysite.com/john.
Except those aren't different URLs. And now that I'm slightly more
awake I'm wondering why
On 8/5/07, Alex Nikolaenkov <[EMAIL PROTECTED]> wrote:
>The urls are pretty same. But the second one causes 404 Response.
>While typing the second url the user tries to access typing its
>address and types "Simpsons" instead of "simpsons". In terms of
>nix-like systems this is a
On 8/4/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
> On 8/4/07, A Mele <[EMAIL PROTECTED]> wrote:
> > Does that mean generic relations are production ready although they
> > are not yet implenteed in the admin?
>
> Exactly - the code's fine; there's just no admin support yet.
Though if you
On 8/2/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> Can this possibly be right? If I want to include a single variable that
> includes some HTML (such as {{ form.as_table }}), do I have to turn off
> auto-escaping for everything else in the page?
>From the descriptions above -- of using the
On 8/2/07, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> I'm -1 for {% autoescape on %} and {% autoescape off %}.
> This is also like PHP magic_quotes!
No, it's not. PHP's magic_quotes is set at a higher level; because the
behavior will be on by default and the only mechanism to change it
will be a
On 8/1/07, Tom Tobin <[EMAIL PROTECTED]> wrote:
> Thank you for taking this opportunity to remind me of the autoescaping
> proposal. I must have forgotten it somewhere along the way here.
> (Next time, you *could* just say you're -1.) :P
I'm just saying: let's do this.
Malcolm's right: the
On 8/1/07, Deryck Hodge <[EMAIL PROTECTED]> wrote:
> May I ask a clarifying question here? Is autoescaping going to be on
> by default, or no? And what exactly is it that's being added here --
> a template tag for turning on/off autoescaping?
The proposal is:
* Autoescaping is on by default.
On 7/22/07, oggie rob <[EMAIL PROTECTED]> wrote:
> but everything I can think of is safer & cleaner by restricting
> it to TEMPLATE_DIRS locations (e.g. adding the extra directories, sym
> linking, or just maintaining another copy in an existing TEMPLATE_DIRS
> spot). The advantage is of course
On 7/22/07, Tai Lee <[EMAIL PROTECTED]> wrote:
> Don't you mean *disallow* use of {% include %} and *enforce* use of {%
> ssi %} (only)? If he has no control over the template code html
> authors are generating, and {% include %} is part of django, those
> template authors would be able to access
On 7/21/07, Czubakabra <[EMAIL PROTECTED]> wrote:
> Django templates shoudn`t permit html coder to include files located
> above TEMPLATE_DIRS paths.
> What do you think about it?
I'm personally ambivalent about where the "include" tag should be able
to search, because I can see cases where it'd
On 7/13/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I'm biased, because I have an immediate need for this in a project,
> but this seems general and useful enough for inclusion in QuerySet.
Implementing the check in __nonzero__ and having people test by doing
'if some_queryset' or 'if not
On 7/13/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> My question for the rest of the second message was a question of how
> much separation between forms and models there should be. For me the
> validation issue is key. We currently don't have any standard way to
> programmatically validate
On 7/12/07, Johan Bergström <[EMAIL PROTECTED]> wrote:
> The way i see it, there are two main reasons to decouple this:
> * Concurrency (for instance: flup and all db connectors are
> decoupled)
> * Less updates to merge into tree (user already handles other
> decoupled updates him/herself)
On 7/11/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> This sounds like a strange way to ask if Django is using prepared
> statements[1] or their equivalents, rather than simply supplying
> values directly within the SQL statement itself. To my knowledge,
> Django doesn't support them, and I
On 7/10/07, Sean Patrick Hogan <[EMAIL PROTECTED]> wrote:
> The "pythonic" way is a new addition to Django if I'm not mistaken.
Yes, it was added between the 0.95 and 0.96 releases.
> I personally prefer calling by string because (I'm assuming here) it doesn't
> load the function unless it
On 7/9/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> I don't know if this is what Adrian was referring to, but I would
> think an ideal "project" would be nothing more than settings.py,
> urls.py (which might be split into multiple files), a set of templates
> and static media content.
Jannis has, I believe, previously mentioned in his SoC updates the
possibility of changing the default app skeleton Django uses for the
'startapp' target, or at least providing an alternate skeleton more
suited to distributable/packageable applications. I'd like to revisit
that, and the way we
On 7/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I personally don't understand why we can't use email addresses as
> usernames.
You can, you just need to roll your own form.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
On 7/5/07, anna <[EMAIL PROTECTED]> wrote:
> It's complicated to explain, but basically, anything that goes onto
> our systems must be approved and only certain versions of Python are
> approved for use/development (2.4 and possibly earlier ones, but I'm
> not sure). We haven't yet chosen a
On 7/5/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Oooh, this is something I've wanted to do for ages...See
> http://code.djangoproject.com/ticket/5 , which was marked as wontfix
> by Jacob (but I'd still like to see this feature).
I'd also be interested to get input from the SoC student
On 7/5/07, anna <[EMAIL PROTECTED]> wrote:
> Yes, I understand that. But does that mean that it's developed in
> 2.3, 2.4 and 2.5 or just one of those? I know this is a weird
> question, but I'm doing research for work and need to know this info.
> The fact that it's just compatible with
On 7/5/07, anna <[EMAIL PROTECTED]> wrote:
> Can anyone tell me what version of Python the latest version of Django
> (and previous versions if available) is written/developed in? Or can
> you tell me where I can find that info?
Django is compatible with any version of Python greater than 2.3,
On 7/5/07, Carl Karsten <[EMAIL PROTECTED]> wrote:
> So far I have only heard reasons why it isn't that important, but no reasons
> not
> to.
I'm cautiously skeptical. Probably the best route to take with
something like this would be to develop and release it as a standalone
utility; this lets
On 6/26/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> Except that if people aren't using memcached, but locmem, for example,
> invalidating the cache only does so for that current process, which
> would result in the same problem we're currently having. That is,
> unless I'm reading the code
On 6/19/07, Jonas <[EMAIL PROTECTED]> wrote:
> It's true that we are around circles, and I understand that you wann't
> make that little change. It's more comfortable to have the framework
> configured to your localization that:
And it's already quite easy to do so, just by changing a couple
On 6/19/07, Joseph Heck <[EMAIL PROTECTED]> wrote:
> Out of curiousity, what's the reason to try and keep them separate
> instead of just layering it over the session mechanism?
I'd be +1 on just switching the whole thing (messages for all users,
authenticated or not) to using sessions, in which
On 6/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> However all that is beside the point. The patch that Jonas has posted in
> #4590 is just to change the default settings. I'm not sure if that's
> worth doing or not. Currently I'm somewhere between -0 and +0, since
> it's completely
On 6/16/07, Jonas <[EMAIL PROTECTED]> wrote:
> I think that Django should use an international standard date and time
> format.
Where do you propose this be used? At the database level, your DB will
store date/time values in whatever internal format it prefers. At the
level of input and output
On 6/12/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> What happens if a phone number begins with 0 (as some international
> numbers are given in the U.S.)? Shouldn't it really be a CharField? It
> sure as heck isn't an integer.
United States phone numbers consist only of a three-digit area code,
On 6/10/07, Brian Harring <[EMAIL PROTECTED]> wrote:
> Aside from that, would really help if I had a clue what folks are
> actually using dispatch for with django- which signals, common
> patterns for implementing their own signals (pre/post I'd assume?),
> common signals they're listening to,
On 6/6/07, Andrew R <[EMAIL PROTECTED]> wrote:
> No matter what I try, I get:
>
> django.template.TemplateSyntaxError: 'javadoc_filter' is not a valid tag
> library: Could not load template library from
> django.templatetags.javadoc_filter, No module named javadoc_filter
Cross-replying
On 6/7/07, Noam <[EMAIL PROTECTED]> wrote:
> I don't see how you will be able to use blocks as variables. The only
> thing you can do with a block is to display it in the rendered page -
> you can't use it in any other way. And if you want to write the same
> thing a few times in your page,
On 6/7/07, Ilya Semenov <[EMAIL PROTECTED]> wrote:
> The proposed behaviour would run 1+N queries, first for getting
> different grouping values:
This is a very good point, and I think it's enough to make me -1 on
regroup returning a QuerySet :)
> Second, in multi-threaded environment that
On 6/7/07, Noam <[EMAIL PROTECTED]> wrote:
> I want every page in my site to have a title. I want the title to
> appear both in the browser title and in the page itself. An example of
> the HTML I want is this:
>
>
> Bug System - Report a New Bug
>
> Report a New Bug
This seems like an unusual
On 6/4/07, gh <[EMAIL PROTECTED]> wrote:
> I contacted R Munn about the SQLAlchemy integration in January but I
> understand he has dropped it. I would like to volunteer as a guinea
> pig for testing once someone takes this on ... but figuring this out
> via google is a
> pain.
If half as many
Also, you might want to have a look at the WSGI ecosystem and
specifically Paste Deploy, which can kind-of be made to work with
Django and does a lot of what you seem to want, but in a
framework-neutral way.
Anyway, I think we're just talking past each other at this point, so
I'll bow out.
--
On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
> Is this considered part of the stable API? Is it part of the backward
> compatibility guarantee?
I can't make a hard and fast promise, but since there are quite a few
bits of Django itself which rely on this API and would have to be
On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
> I can't extend Django applications with extra features that require
> auto-discovery. I'm working on a CMS using Python, and I want to know
> which applications support special features that my CMS can build upon
> (something similar to
In all seriousness: django.contrib.bikeshed.
--
"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
On 5/29/07, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
> Right now, django applications are strange creatures. They are python
> packages with some magic. They have to have a "models" module.
> Everything else is free form. We have strong conventions like urls.py,
> maybe admin.py, but they all
I noticed a patch sitting on #4412 tonight which seems interesting but
definitely needs a decision; the idea is that, rather than
implementing a separate widget or set of widgets to handle grouping of
options (via the HTML "optgroup" element), the Select and
SelectMultiple widgets should look at
On 5/27/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> If you have a specific proposal on how to bundle CSS files together in
> the way you describe, feel free to suggest it.
I've done this for JavaScript, and it wasn't terribly hard -- I wrote
a little script that takes a list of JS
On 5/25/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Given the frequency of this request, I'm OK with adding a context
> processor in django/core/context_processors.py that sets a "MEDIA_URL"
> variable in the context. I'm also OK with having that be in the
> default
On 5/18/07, Jason Davies <[EMAIL PROTECTED]> wrote:
> Is there any way around this, or is it just something inherent to
> Python?
Personally, I think the sanest way to handle a standalone app is to
assume it'll be directly on the Python path and build around that
idea; asking people to install
On 5/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> It's probably more important to check the web page than follow the
> developers' list, I would say. It's a bug if we don't update the webpage
> after a real incompatible change.
I've posted a followup reminder to django-users about
On 5/15/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> Will there be a branch for the SoC work?
If a student wants a branch, I'm sure we'll provide one, but we won't
force it on them; it should be up to each student/mentor pair to
decide how best to manage their project (I'm mentoring one, for
On 5/10/07, Sebastian Macias <[EMAIL PROTECTED]> wrote:
> Do any of you guys when the django-admin.py updatedb command will be
> completed? updatedb is basically all django is missing for me and many
> developers at the company I work for to abandon CakePHP and move to
> django.
As far as I
On 5/10/07, foobarmus <[EMAIL PROTECTED]> wrote:
> Unfortunately, pushing access control up the stack means I
> have to rewrite all the functionality has been carefully and
> comprehensively facilitated by my RDBMS. Also it means that access
> control logic has to be written into every app that
On 5/9/07, foobarmus <[EMAIL PROTECTED]> wrote:
> It's a tightly modelled, configurable, business administration tool.
> If used in a business of significant size, I would expect and hope
> that a DBA was employed to administer the database. Many of the tables
> will contain information that is
On 5/6/07, Honza Král <[EMAIL PROTECTED]> wrote:
> I know Jacob was planning on rewriting the comments framework to work
> with newforms. Is there any work done there?
I believe the plan is -- much as with newforms-admin -- to take
advantage of the rewrite and build more flexibility into the
On 4/30/07, Simon G. <[EMAIL PROTECTED]> wrote:
> We've warned people off using the svn version to run production sites
> because of the post-1.0 code breakage that's going to be happening.
> So, we don't need to worry as much about stability of trunk, since
> 0.96 is the stable, recommended
On 4/26/07, tonnzor <[EMAIL PROTECTED]> wrote:
> This feature is demanded and it is easy to implement w/o side effects.
> We should do it.
The ticket for this has been closed multiple times and Adrian has
asked that it not be reopened. Malcolm has asked that this thread be
allowed to die. That
On 4/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Why isn't patch #2070 added to trunk yet? The current patch(es) won't
> work with trunk either. Is this "in the works"?
>From a quick glance at the discussion in the ticket, it appears that
there hasn't been much activity on it since
On 4/22/07, Florian Apolloner <[EMAIL PROTECTED]> wrote:
> I would like to be able to do something like this:
> http://groups.google.at/group/django-users/browse_thread/thread/62ef2b417fad1b8d/532c9b3fdf2ad36d
>
> Any chance to get this into the new admin?
Please keep in mind when suggesting
On 4/18/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> I can also see a solution which would maintain backwards compatibility
> for old sites:
> TEMPLATE_AUTOESCAPE=False in conf.global_settings
> TEMPLATE_AUTOESCAPE=True in conf.project_template.settings
I'd be against this; any solution which
On 4/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On or off by default seemed to be the only debate (and it's not really a
> debate -- Adrian didn't like it).
I don't *like* it, but I've come around to accepting that it's better
for us not to point the gun at a developer's foot and say
Short and sweet: since we're already planning some
backwards-incompatible changes for the next release, how about we
hammer out auto-escaping of template output while we're at it? Even
those of us who don't like it (myself included) are probably at the
point of accepting that we have to do it
On 4/13/07, Anders Olsson <[EMAIL PROTECTED]> wrote:
> portable and decoupled from the project where it is used. But doesn't
> the project being the top level python package make it almost
> impossible to move an app from a project to another without modifying
> the import statements?
If you
On 4/12/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> The options that apply to the admin interface have been factored out
> as options to the admin class. Here's more information:
Since it doesn't seem to have come under the axe yet, I'd like to go
ahead and suggest that 'choices' stay in
On 4/12/07, jp <[EMAIL PROTECTED]> wrote:
> That doesn't make a whole lot of sense to me. I would think that with
> the newforms admin stuff it would be an ideal time to completely
> remove all display-related information from the models. It really just
> doesn't belong there.
What
On 4/7/07, Noah <[EMAIL PROTECTED]> wrote:
> I'm worried about a trend I've seen before in other frameworks etc.
> They start off easier to use and over time get more and more
> generalized and then become so general and so academically correct
> that there is no point in using them because
On 4/4/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> I can work around this problem in a messy way in the deserializer by
> manually resetting the sequence to the largest PK value that was found
> during deserialization, but that isn't really clean, and doesn't fix
> the manual allocation
On 4/4/07, Max Derkachev <[EMAIL PROTECTED]> wrote:
> That's not a problem. The API lookup can be easily emulated in custom
> class. The problem is that it tries to load the profile from django's
> internal models cache, and that can't be easily emulated. One needs to
> cheat django the hard way
501 - 600 of 901 matches
Mail list logo
