On Dec 11, 12:10 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Mon, 2007-12-10 at 15:45 -0800, Vinay Sajip wrote:
>
> [...]
>
> > Plus, I've probably
> > missed some obvious point which kills the idea stone dead :-(
>
> Since views are just Python functions, they don't necessarily have
> What am I forgetting?
This is a completely personal and probably selfish desire, but I'd
love to see the comments system rewrite in there. It's been on that
informal wiki-list ever since I started using Django.
--~--~-~--~~~---~--~~
You received this message
http://code.djangoproject.com/ticket/4102
--
Collin Grady
If condition persists, consult your physician.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send
On further inspection, it looks like this could be just a couple of
one-liner additions to db/models/base.py.
self.db_values = db_values
On Dec 11, 3:09 pm, Simon Litchfield <[EMAIL PROTECTED]> wrote:
> When we load/save a model to/from the database, wouldn't it be nice if
> the model kept a
When we load/save a model to/from the database, wouldn't it be nice if
the model kept a copy of those 'last saved' values, as say
myinstance.original.myfield, or myinstance.last_saved.myfield etc.
Internally, we could then make the UPDATE/INSERT statements only
include the rows that have
Joseph Kocherhans said the following:
> I'm close to checking this in and adding a note to
> BackwardsIncompatibleChanges, but I'm still a little uneasy about
> generating the form fields at form instantiation time. It just feels
> weird to me, but I can't really come up with any actual reasons
On 12/9/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> OK, so after chatting a bit with Joseph on IRC I'm working on revising
> my original patch. The changes it makes still need some discussion, so
> I'll outline them here.
>
> 1. The "instance" argument to ModelForm.__init__() essentially
[EMAIL PROTECTED] wrote:
> I agree with James, it makes good sense for the presentation of data
> to be handled exclusively in the presentation layer. However one idea
> I had was that perhaps in a model data could be marked as always safe,
> always unsafe. For example in a blog, it would make
2007/12/10, oggie rob <[EMAIL PROTECTED]>:
>
> > * Escaping is solely and entirely a function of presenting data in HTML.
> > * As such, escaping belongs in the component of Django which handles
> > presentation of data in HTML.
> > * As such, the template layer is the correct place for this.
>
On Dec 11, 1:01 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> I suspect is_active should be False for those users (since they
> cannot log in and that's the point of is_active). So I'd probably be +1
> for changing is_active to False on AnonymousUser.
Ok,
On Sun, 2007-12-09 at 14:55 -0800, SmileyChris wrote:
> Changeset 6299 [1] added some "useful" methods and attributes to
> AnonymousUser.
>
> One of these attributes is is_active = True
>
> This is a change in functionality, because previously if you used
> (like I was) {% if user.is_active
On Dec 10, 6:58 pm, "Joseph Kocherhans" <[EMAIL PROTECTED]> wrote:
> On 12/9/07, Gary Wilson <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > Vinay Sajip wrote:
> > > On Dec 7, 6:35 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> > >> On Dec 7, 2007 12:56 PM, Vinay Sajip <[EMAIL PROTECTED]> wrote:
>
>
On 12/8/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> The same is true of a weekly Django update message. There is
> absolutely nothing stopping you from writing a weekly blog message and
> publishing it somewhere.
I posted a quick proof of concept:
On Monday 10 December 2007 20:26:30 Jakub Stolarski wrote:
> Hi,
>
> I didn't see discussion on that topic so here's my question:
>
> Did you think about enabling user to use his own render_to_response
> (or something similar) in generic views?
No, but I've seen hundreds of other proposed
Hi,
I didn't see discussion on that topic so here's my question:
Did you think about enabling user to use his own render_to_response
(or something similar) in generic views?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
> Thanks for the speedy responses. I'll keep quiet now :)
Except to say that the mark_safe function works in view (as well as in
filters). Sorry I missed that, it solves my concerns nicely.
-rob
--~--~-~--~~~---~--~~
You received this message because you are
I agree with James, it makes good sense for the presentation of data
to be handled exclusively in the presentation layer. However one idea
I had was that perhaps in a model data could be marked as always safe,
always unsafe. For example in a blog, it would make sense to have the
text marked at
> * Escaping is solely and entirely a function of presenting data in HTML.
> * As such, escaping belongs in the component of Django which handles
> presentation of data in HTML.
> * As such, the template layer is the correct place for this.
All good arguments :)
I'm frustrated that the template
On 12/9/07, Gary Wilson <[EMAIL PROTECTED]> wrote:
>
> Vinay Sajip wrote:
> > On Dec 7, 6:35 pm, "Marty Alchin" <[EMAIL PROTECTED]> wrote:
> >> On Dec 7, 2007 12:56 PM, Vinay Sajip <[EMAIL PROTECTED]> wrote:
> >>
> >>> this be allowed/disallowed/checked for? As for standard template
> >>>
On 12/10/07, oggie rob <[EMAIL PROTECTED]> wrote:
> Shouldn't this operation occur in the newforms framework, since the
> distrust comes from user-entered data, and the decisions on what
> should be trusted and what shouldn't come from the form developer?
No, no, no, a thousand times no.
In
> I dunno about you, but I get data from places other than forms.
Well then, who makes decisions about trust for that data?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
On Dec 10, 2007 12:18 PM, oggie rob <[EMAIL PROTECTED]> wrote:
> Shouldn't this operation occur in the newforms framework, since the
> distrust comes from user-entered data, and the decisions on what
> should be trusted and what shouldn't come from the form developer?
I dunno about you, but I
Hi all,
This might seem like beating a dead horse...
In the template docs, this phrase is in the notes for escaping:
"Generally, template authors don't need to worry about auto-escaping
very much."
which to me, sounds about right. But clearly template authors DO have
to worry about auto-escaping,
On ticked #5894 (http://code.djangoproject.com/ticket/5894) I have
supplied a patch, is there anything else that needs to be done to
ensure it moves forward?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django
Because this method overloaded in subclasses of HttpRequest
On 10 дек, 12:52, David Reynolds <[EMAIL PROTECTED]> wrote:
> On 10 Dec 2007, at 5:35 am, Eratothene wrote:
>
> > Don't bother I have just figured out why.
>
> Can you say why, just for completeness of the archives?
>
> Thanks,
>
>
On 10 Dec 2007, at 5:35 am, Eratothene wrote:
> Don't bother I have just figured out why.
Can you say why, just for completeness of the archives?
Thanks,
David
--
David Reynolds
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you
26 matches
Mail list logo
