http://code.djangoproject.com/ticket/11461
DebugNodeList catches all exceptions, sticks them in a
TemplateSyntaxError, and stuffs the original exception in the new
exception. I'm not sure why this is done, but it breaks debugging and
exception handling.
What is the advantage of swallowing the ex
On Oct 16, 5:56 am, Tobias McNulty wrote:
> On Wed, Oct 14, 2009 at 10:27 AM, Jacob Kaplan-Moss
> wrote:
> > I'm trying to avoid having two incompatible messaging systems in
> > Django. I agree that linking messages to sessions makes more sense
> > than linking them to users [1], but we can't
On Oct 16, 12:03 pm, SmileyChris wrote:
>
> class LegacyFallbackStorage(FallbackStorage):
> storage_classes = (UserMessageStorage, CookieStorage,
> SessionStorage)
Here's a working implementation even:
http://code.google.com/p/django-notify/source/detail?r=35
No need
On Oct 16, 2:04 pm, Tobias McNulty wrote:
> Just to make sure I understand this correctly, let me try to summarize
> what this would mean:
>
> * the proposed app controls {{ messages }} and is responsible for
> retrieving anything set in the Message model
Thanks to Luke's work with lazy message
On Oct 17, 1:51 am, Jacob Kaplan-Moss wrote:
> I'd like this shortcut to be (similar to?) Simon's TemplateResponse
> (http://code.google.com/p/django-openid/source/browse/trunk/django_ope...).
+1 btw
--~--~-~--~~~---~--~~
You received this message because you are
Interestingly, I made a snippet [1] two years ago something like this.
Granted, it was a bit more convoluted: you build a decorator and use
that everywhere (I was a bit anal about DRY, so you can render a
prefix template path for that decorator)
Personally, I just use direct_to_template for proje
On Oct 23, 6:16 am, Philippe Raoult
wrote:
> While we're talking about that, is there a reason the default manager
> isn't iterable (default mapping to .all()) ?
I've always thought this would be the logical thing to do, too.
--~--~-~--~~~---~--~~
You received thi
Just chiming in that I'm also +1 to visual distinction, -1 to current
colors.
On Nov 3, 4:27 pm, Tobias McNulty wrote:
> I'm not a big fan of the red/green either. They imply that Django code is
> "bad" and user code is "good". What about something more subtle, like
> different shades of gray
On Nov 29, 6:40 am, Luke Plant wrote:
> Hi all,
>
> I started work replacing Django's if with the "smart-if" template tag
> by Chris Beaven (http://www.djangosnippets.org/snippets/1350/)
Neat! I'm assuming you'll be posting this to your bitbucket soon? :)
> 1) Handling non-existent variables
> 2
On Dec 1, 6:08 am, Luke Plant wrote:
> > I was with you right up until the equality comparisons (Null ==
> > Null -> False etc). As noted by Alex, it conflicts with the answer
> > given by {% ifequal %}; it also differs with Python's behavior.
>
> Yeah, I hadn't thought of that. I don't think it
On Dec 1, 6:08 am, Luke Plant wrote:
> Given that the 'Null' stuff has now been removed, we could
> move back to your way to reduce the code a bit, but I'm not sure it is
> worth it.
I'd say reduce the code again.
And I think you missed adding some files in your repo?
--
You received this mes
Prompted by Luke's whitespace removal patch for django-contrib-
messages, I thought I'd bring this up.
The Django contributing guide says "Unless otherwise specified, follow
PEP 8."
Should new code use two lines between top level classes & functions,
like PEP 8 suggests, or should the contributin
I applied and pushed all but your final whitespace revision.
When Tobias reads this thread again, I'm sure he'll give you commit.
The fail_silently sounds good, and yes these failures were a rather
big oversight.
On Dec 2, 10:35 am, Luke Plant wrote:
> I've been going through the code carefully
This should be a high priority fix.
Anyone new to Django and using the installation of 1.1.1 (which the
download page recommends over trunk) will currently be unable to
follow the tutorial.
I was having a face to face meeting today with someone who had exactly
this problem.
On Nov 6, 1:53 am, Rus
Because that link intrigued me, I challenged myself to write my own
generic lexer & parser based on what I had read:
http://gist.github.com/250128
On Dec 6, 2:07 pm, Luke Plant wrote:
> On Saturday 05 December 2009 20:09:21 Luke Plant wrote:
>
> > I'm not likely to able to look at this before T
On Dec 17, 8:57 am, Alex Gaynor wrote:
> On Wed, Dec 16, 2009 at 2:53 PM, Mike Malone wrote:
> > How's that different than the current situation, where we return an
> > absolute URL reference that can be converted into an absolute URL
> > using request.build_absolute_uri?
>
> It allows an objec
On Dec 22, 1:52 pm, Johannes Dollinger
wrote:
> There's a small bug in b64_decode(), the padding should be
> r = len(s) % 4
> pad = '=' * (r and 4 - r or 0)
Or even simpler:
pad = '=' * (-len(s) % 4)
--
You received this message because you are subscribed to the Google Group
On Jan 5, 9:24 pm, harrym wrote:
> I'm working a templatetag that determines whether to use 'a' or 'an'
> in front of English words. My particular use case for this is in a
> tumblelog app I'm developing - many different types of entry may be
> added (link, html, quote, etc), and I'm linking to
On Jan 6, 11:09 pm, Jeremy Dunck wrote:
> I realize I'm very late giving feedback on the API, sorry and feel
> free to ignore if I'm too late.
>
> That said, from the docs, the API to set the effective messaging level
> is awkward:
>
> ==
> # Change the messages level to ensure the debug mes
On Jan 11, 2:12 pm, Russell Keith-Magee
wrote:
> I concur. get_level()/set_level() sounds like a reasonable change to
> me. Can I have that in the form of a ticket and patch? :-)
http://code.djangoproject.com/ticket/12575
--
You received this message because you are subscribed to the Google Grou
Looking around, this looks like a problem for other frameworks too
(see http://trac.turbogears.org/ticket/1164)
If we're to accept that turbogears example, it sounds like we're not
properly encoding the cookie in core, rather than patching messages.
On Jan 23, 2:23 am, Tobias McNulty wrote:
> Hi
I was thinking that it would help third-party apps to be able to work
across both 1.1 and 1.2 installations without workarounds if the 1.1
branch had a csrf_token tag, just to stop templates choking with a
"Invalid block tag: 'csrf_token'" message.
Does this fit within the policy for supporting ol
> Addressing the limitations of the builtin auth.User is something I
> hope to look at in the 1.3 timeframe.
In that case, would it be reasonable to have an open ticket for the
specific request of being able to customize the length of the email
field in the contrib.auth User object?
I'm guessing
Bah! Yes, just like that.
However, it would be nice to release a 1.1.2 containing this for those
who use released versions as opposed to svn branches before 1.2 hits.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, s
My ticket in #6510 [1] deals with this, along with a nice abstraction
of common recursive nodelist gathering patterns.
Although the ticket description, comments (and even tests in my patch)
mention {% block %}, this has *nothing* to do with conditional
inheritance.
If the patch is deemed too much
team, they haven't been able to keep
> up with the backlog. We either need more volunteers to do triage, or
> we need to accept as a community that progress isn't going to be as
> fast as we may like.
More volunteers! Come one people! *SmileyChris blows his triage
trumpet*
> T
On Feb 27, 3:06 am, Russell Keith-Magee
wrote:
> I'm a little confused by this ticket.
>
> The original report was about something that is clearly a bug -- the
> inconsistency between block handling for {% if %} and {% ifequal %}.
> I'm 100% in agreement that this inconsistency should be fixed.
>
Would whitespace handling be identical to the current template system?
--
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, send email to
d
Yes, I was thinking the other day that it would be a cool solution for
serve() to be able to use storage backends
On Apr 16, 7:09 am, Kevin Howerton wrote:
> Why not just use the backend feature that already exists?
>
> I have an S3 backend that does this...
>
> It checks if it's on S3, if not it
On Apr 21, 9:46 am, Jeremy Dunck wrote:
> [...] Even so, the perception of ignored tickets is part of the
> problem-- whether tickets are actually ignored or not, the perception
> still would discourage contribution.
>
> I'd like to highlight tickets that have sat in each queue for a period
> of
On Apr 21, 10:13 am, SmileyChris wrote:
> In a similar vein, it'd also be great if under the ticket summary,
> some "hooks" based on the current ticket state could be added.
--
You received this message because you are subscribed to the Google Groups
"Django devel
Can't investigate too much more until tomorrow, but it's a pretty big
regression so I thought I'd bring it up here for discussion as well as
starting a ticket.
http://code.djangoproject.com/ticket/13556
--
You received this message because you are subscribed to the Google Groups
"Django develop
On May 18, 5:41 pm, Karen Tracey wrote:
> On Tue, May 18, 2010 at 12:45 AM, SmileyChris wrote:
> > Can't investigate too much more until tomorrow, but it's a pretty big
> > regression so I thought I'd bring it up here for discussion as well as
&g
On Jul 10, 1:47 am, Stijn Hoop wrote:
> Hi,
>
> I am trying to use the 'natural keys' feature of django to make a sort
> of "future proof" fixture loading possible.
> [...]
> With the patch linked below[1] I have successfully used dumpdata and
> loaddata for a .json export of my tables. Of course
On Jul 11, 12:14 am, Russell Keith-Magee
wrote:
> > So you can't put reverse now in settings.py unless there is some
> > late-binding construct, like
>
> > LOGIN_URL = RevLink('accounts:login', account_type='user')
>
> You shouldn't have to put reverse() calls into settings.py -- you
> should only
On Jul 13, 9:10 pm, Margie wrote:
> Yes, I know from tickets I have posted that modifying exclude
> dynamically is "not allowed".
Why wouldn't you just modify self.fields?
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this gr
On Jul 15, 1:14 am, Russell Keith-Magee
wrote:
> We need to be able to define templates for:
>
> a) The layout for a single widget (e.g., a DateWidget)
> b) The layout for a single row of a form
> c) The layout for an entire form (top errors, fields, hidden fields)
> in as_* style.
We also nee
On Jul 27, 9:22 pm, Carl Meyer wrote:
> The common thread, of course, is making it possible to write reusable
> caching code without special-casing particular backends.
I agree with Carl.
We have an abstracted api - having a property with different meanings
for different backends makes things a l
I look forwards to the addition of this...
--~--~-~--~~~---~--~~
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
Here's how I see it:
- 99% of the time, templates are HTML
- most template variables should be escaped
- developers are human and will miss variables that need escaping
My proposal is that all templates variables are escaped by default.
Think about it for a bit before you throw the idea away. T
(oops, posted this before in the django users group)
I noticed http://code.djangoproject.com/ticket/2131 was marked as a
wontfix today with the comment, "Django isn't meant to serve static
files".
I don't want to go reopening the ticket, but couldn't this still be
useful functionality?
What if I
I realise there are better ways to send most files. I ask about this
because I'm looking at implementing that "special case" soon
(authenticating files via logged in user in Django), and I was just
wondering about ways to do it.
--~--~-~--~~~---~--~~
You received
gabor wrote:
> my guess is (b)
I think (b) is pretty much a given. Looking back in the developers
group history, I see this is a recurring problem that seems to keep
getting put in the "too hard" basket.
See:
http://groups.google.com/group/django-users/browse_thread/thread/21da889ecb9c63dd/145e3
Ivan Sagalaev wrote:
> The regular HttpResponse already can serve files in some fashion:
>
> f = open(filename)
> return HttpResponse(f, mimetype='application/octet-stream')
>
> Here the file-like object will work as an iterator sending one line at
> a time.
Thanks Ivan, this alleviates
Brilliant, Christopher. This is exactly the solution I'd be pleased
with!
We still have the problem of invalidating every single template written
so far in Django, however...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
[EMAIL PROTECTED] wrote:
> that's why i suggest looking at this as a data validation issue. (not
> simply as escaping) we do lots of validation in the model already.
But it is an escaping issue.
There's nothing wrong with allowing html to be entered in (for example)
a comment field. It should
James Bennett wrote:
> Security by annoyance is security that people learn to hate and turn
> off as soon as they can, so in the end it doesn't really make them any
> more secure than they were before.
Having used TAL a lot (like KID, automatically escapes), I did not
actually find this annoying.
Hi Jacob,
On Jun 21, 2006, at 5:16 PM, SmileyChris wrote:
> > Having used TAL a lot (like KID, automatically escapes), I did not
> > actually find this annoying.
Jacob Kaplan-Moss wrote:
> I really wish there was a way of saying this that didn't make me
> sound like a je
> Yes, Django should be accessible to newbies, but newbie-friendliness
> needs to be balanced against the needs of experienced web developers
> (who likely already know all about XSS).
To exume an old horse and continue beating it, experienced web
developers may know all about XSS, but they will
Hi Malcom,
Thanks for the comments.
Does the template source *need* to provide information on what is
escaped or not?
The view is handling a lot of the output format anyway, I personally
don't see a problem with looking there to see how a template is being
escaped.
Then again, I guess escaping
When using templates and the user interface, the logic seems backwards
to check for an anonymous user as opposed to a logged in user.
By using user.is_anonymous in a template, you assume that if it's false
then the user is logged in, where in actual fact "user" may just not be
getting passed to c
I like it too.
To attone for my duplicate thread, I have created a ticket and patch
for this.
http://code.djangoproject.com/ticket/2332
I'm not sure how you "declare is_anonymous as depreciated", Malcom so
I'll leave that to you ;)
--~--~-~--~~~---~--~~
You rece
Yea, I'm not really that sold on .is_loggedin() either... some
alternatives:
.is_real_user()
.is_known()
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
I think we still need the AnonymousUser and from the number of
references to is_anonymous in python modules I think we still need a
negation of it.
So how can we work towards a consensus on the best name for a function
which is the negative of is_anonymous?
On a side note, in templates I don't t
Gary Wilson wrote:
> I think I now vote for is_authenticated since the is_loggedin versions
> could more easily be taken the wrong way (by trying to lookup all users
> who are logged in). I would be less inclined to try and lookup all
> users who are authenticated. Make any sense?
Makes sense t
Hrm...
Will there ever be a difference between "user.is_anonymous" and "not
user.is_authenticated"?
If not (and I can't think of a reason), do we really need to keep
is_anonymous?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Go
As long as you're using RequestContext however, the user would always
either be an anonymous user or an authenticated user.
But I guess you don't have to use RequestContext, therefore I'm
answering my own question...
So Adrian (or other submitters), do you need any more work done to
Gary's patch
Great job on the patch, Malcom!
I posted this in the ticket, then felt guilty because you told me not
to. So I'll post here for discusion.
A couple of points:
If a markup filter fails due to an import error, I don't think it
should be marked as safe.
>From a skim read of the patch, I'm missing th
Malcolm Tredinnick wrote:
> On Mon, 2006-07-17 at 03:30 -0700, SmileyChris wrote:
> > A couple of points:
> > If a markup filter fails due to an import error, I don't think it
> > should be marked as safe.
>
> Why not? The returned result is the empty string in t
> 'escape' and 'safe' have a different meaning for fireworkers, too ;-)
Or bank robbers :-P
Back on topic, I like finalization too (even though I cringe having to
write the american Z version).
--~--~-~--~~~---~--~~
You received this message because you are subsc
I got sick of waiting so attempted it myself.
http://code.djangoproject.com/ticket/61
It all works for me, the only thing it needs is some tests and work on
the "rel" stuff (which is used if it's used with edit_inline I think?).
But it is a complete working patch, feel free to test it out / submi
I have been thinking about where escaping belongs recently and maybe my
logic is all wrong but I'll write down some of my thoughts.
This is a related thread to the ones about auto-escaping but I have a
specific discussion I wish to persue. And it's not really limited to
"auto" escaping so bear wi
James Bennett wrote:
> The view decides which template to use, and what variables will be
> made available to the template, but that's not really the same thing;
> the question here is "which layer of Django decides what the actual
> output bits will be that go over the wire?" And the answer is m
Trying to mark http://code.djangoproject.com/ticket/2478 as spam but I
get rejected. Go Akismet.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django
It's been closed now, but any reason why I can't comment in Trac now?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.co
Hi Mike,
In case you are interested, I wrote a ticket that (in addition to
adding some other paginator functionality) provides a PaginatorPage
object which is a wrapper for a specific page.
http://code.djangoproject.com/ticket/2093
I just updated it to provide some useful properties: next_page_n
I think you meant "I used property() so you can use
request.session.expires = 213123. "
I wouldn't worry about the smart times -- just having seconds is good
enough.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Way back in ticket http://code.djangoproject.com/ticket/1278, Adrian
declared that a settings context processor was not going to happen. The
reason being that it could give template authors direct access to the
db password / secret key.
Recently I coded up
http://code.djangoproject.com/wiki/SafeS
Ok, I agree that if we start putting individual settings it will lead
to a bit too much pollution.
But Ivan, you need to access the STYLE_URL setting. Having access to
settings via SafeSettings could be useful still, right?
--~--~-~--~~~---~--~~
You received this
James Bennett wrote:
> On 7/28/06, Roland van Laar <[EMAIL PROTECTED]> wrote:
> > Would it be better to couple it with the mimetype? A text/plain should
> > by default not be excaped.
>
> What would be *best* is for there to be no magical implied
> escaping/unescaping of anything, only explicit es
Changeset [3268] made the following change for the resolve method in
django/template/__init__.py:
-obj = settings.TEMPLATE_STRING_IF_INVALID
+if ignore_failures:
+return None
+else:
+return settings.TEMPLATE_STRING_IF_INVALID
Bec
Guess I should just make a ticket anyway:
http://code.djangoproject.com/ticket/2637
--~--~-~--~~~---~--~~
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@g
Hi Russ,
Thanks, that explains the problem with my patch perfectly :)
Your solution looks great: it still solves the original problem while
bringing back the correct functionality if TEMPLATE_STRING_IF_INVALID
is not set.
I can't see that you've missed anything (but then again, I didn't
manage t
When moving an app to a different project, I had to go through and fix
all the references to my project name in code. Is there a better way to
import my code? Currently I import like:
from projectname.appname.models import Model
It seems like this inhibits portability of apps somewhat. Perhaps t
I greatly appreciate the hard work of the current committers, but I am
starting to wonder if there are too few of them to handle the number of
tickets being entered into Trac.
Closed tickets with resolution of fixed: 1382 (invalid, wontfix,
duplicate or worksforme: 699)
Open tickets: 501
Open tic
Malcolm Tredinnick wrote:
> Raw statistics like this can be misleading and I think they are in this
> case. Yes, it's slightly disappointing to see the number creep up from
> month to month, but it's not a tragedy. Django still works, it's still
> usable in serious applications.
I agree it's still
This suggestion was dismissed pretty fast last time it brought up. I
don't think this is the direction that the Django developers want to go
down.
Have you checked out my AutoEscaping alternative?
(http://code.djangoproject.com/wiki/AutoEscape%20alternative#SuggestedSolution)
It's simple and effe
Michael Radziej wrote:
> I'd appreciate if we could find a
> way to state what kind of patches are interesting for the
> committers and what not *before* the patch is created fully. This
> is of course more important for large patches.
I think this is the core of my underlying concerns of how t
Back on topic, check out my alternative that I thought may appease the
Django gods if they are so outraged by adding another tag type.
http://code.djangoproject.com/ticket/2721
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Googl
I can't get 2070 to work either. I found
http://code.djangoproject.com/ticket/2613 which fixed up my uploading
problems (at least on the dev server) - have you tried that one?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Seems I've been bitten (again) too by the akismet snake. Grr...
--~--~-~--~~~---~--~~
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 u
I just uploaded a patch to allow windows users to run the test suite:
http://code.djangoproject.com/ticket/2099
I would mark as [patch] but Akismet won't let me (I've emailed Tom for
another whitelist).
--~--~-~--~~~---~--~~
You received this message because you
Using CSS you could make your tag a block tag with 100% width. This
way, the whole cell will be filled with the tag, so you can click
anywhere in it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django develope
Unfortunately it has only changed for creating new users, not editing
the password of existing ones.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to dj
I posted the ticket http://code.djangoproject.com/ticket/2855, but just
wanted to make sure it makes sense to the developers.
My test models:
from django.db import models
class TestCharModel(models.Model):
testchar = models.CharField()
class TestBoolModel(models.Model):
testbool = models
Don Arbow wrote:
> No, a BooleanField should not default to False, the default should be
> application specific. If you want a default value, specify it in your
> model definition.
I don't have to specify a default value of an empty string for my
CharField. Why should I have to specify a default
On Nov 8, 6:39 am, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Let's have a branch of the month, announced on devel and users. The
> branch is then frozen, merged with trunk, and will be merged at a fixed
> date into trunk if no critical and unfixable bugs are found. This would
> encourage at lea
I have created a patch for this pesky bug.
http://code.djangoproject.com/ticket/2315
It's pretty much a one-liner fix, so could a committer please review
and submit?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
It would be nice to have a verbose_name option for fields in newforms
for when you want an alternate to the magical pretty_name. I've been
trying to think about where best to put a it.
The end goal is that BoundFields have verbose_name property which can
return the verbose name or fall back to th
It seems like a great opportunity as newforms develops to clean up the
database fields mess. Most of the arguments you pass a database field
are not related to the database.
Is this part of the goal of newforms, or am I thinking too big?
With newforms, we can just have one optional argument (for
Hi Rob,
Below are instructions for Windows (replace the items in square
brackets). If you're using *nix, I'm sure you can figure out the
equivalent ;)
set DJANGO_SETTINGS_MODULE=[projectname].settings
set PYTHONPATH=[django_projects_folder]
python runtests.py
On Nov 17, 1:33 pm, "Rob Hudson" <[
On Dec 19, 11:08 am, "Waylan Limberg" <[EMAIL PROTECTED]> wrote:
> something like this:
>
> user = User.objects.get(pk=user_id, default=None)
Except this would break (or at least limit the functionality of)
objects which use "default" as a field name.
--~--~-~--~~~--
Although the new user form was a good start, it wasn't really a
complete solution to ticket 61 (auth.User admin form shouldn't require
people to edit hashes)
I wrote up a form which allows staff members (with correct permissions)
to change user passwords: http://code.djangoproject.com/ticket/3166
On Dec 27, 1:43 pm, limodou <[EMAIL PROTECTED]> wrote:
I'd like a dict to hold the default values, so we can get then from a
instance or somewhere easily, but not set each field a default value.
for example, the new forms __init__.py can has a defaultvalues
parameter is a dict. When it will be r
I have a template tag to output a field with my format. It seems to
have stopped working since the BaseForm/Form seperation
def form_line(field):
output = []
output.append(field.label_tag())
for error in field.errors:
output.append('%s' %
escape(error))
output.append(str(field
Hrm... pretty obvious now. I was using my own base form class
overriding the Form class instead of BaseForm.
On Dec 27, 10:51 pm, "SmileyChris" <[EMAIL PROTECTED]> wrote:
I have a template tag to output a field with my format. It seems to
have stopped working since the BaseForm
It seems like the newly added apply_changes method (to
form_for_instance) could be useful in other cases too if it was a bit
more "open-minded".
I don't see why apply_changes should bother about creating a field list
again when that has already been done in form_for_instance. Can't it
just use t
On Dec 29, 6:57 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
This wouldn't work, because self.fields is a dictionary of newforms
Field objects, *not* database Field objects. The "f.attname" wouldn't
be available.
It was just concept code to see if there was any merit in the idea. If
you th
Patch created: http://code.djangoproject.com/ticket/3232
On Dec 30 2006, 8:45 am, "SmileyChris" <[EMAIL PROTECTED]> wrote:
On Dec 29, 6:57 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> This wouldn't work, because self.fields is a dictionary of
Rather than clog up the main "1.0" discussion, let's move this to a
side discussion.
We need to come to a consensus on Django autoescaping - I'll put in my
2c for my alternative
(http://code.djangoproject.com/wiki/AutoEscape%20alternative) of
course, but whichever direction we go, it'd be good to
1 - 100 of 338 matches
Mail list logo
