I definitely understand why business logic should be kept out of the
template; I don't see why adding AND/OR support is any worse than
having if/if not/ifequal/ifnotequal/for.
During the Snakes & Rubies talk it was mentioned that many times there
has to be logic in the template, but just because
On 1/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hello,
> In my recent project I have been finding myself wishing that the {%
> ifequal %} tag had support for AND OR.
Have you considered passing a boolean into the template from the view
with the corresponding value? I don't think the
Adrian Holovaty wrote:
> On 1/12/06, kmh <[EMAIL PROTECTED]> wrote:
> > Good idea to rename DjangoContext. My favorite alternative:
> >
> > DjangoContext --> Context
> > Context --> PlainContext or SimpleContext
>
> I like this a lot! SimpleContext is good...Other thoughts?
Now I like EmptyConte
On 1/12/06, kmh <[EMAIL PROTECTED]> wrote:
> Good idea to rename DjangoContext. My favorite alternative:
>
> DjangoContext --> Context
> Context --> PlainContext or SimpleContext
I like this a lot! SimpleContext is good...Other thoughts?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.c
On 1/12/06, kmh <[EMAIL PROTECTED]> wrote:
>
> > Let's go ahead with this one: django.core.template becomes
> django.template.
> >
> > While we're at it, let's rename DjangoContext to something that
> > reflects the fact that you pass in an HttpRequest object and it has
> > context processors. Re
On 13 jan 2006, at 03.32, Adrian Holovaty wrote:
While we're at it, let's rename DjangoContext to something that
reflects the fact that you pass in an HttpRequest object and it has
context processors. RequestContext, SuperContext, FlexContext,
AdvancedContext -- those ideas are all pretty lame.
Hello,
In my recent project I have been finding myself wishing that the {%
ifequal %} tag had support for AND OR. I posted a http://code.djangoproject.com/ticket/1209"/>patch to ticket
1209 that does just this. I was hoping to start a bit of
conversation here to see if others thought this might
> Let's go ahead with this one: django.core.template becomes
django.template.
>
> While we're at it, let's rename DjangoContext to something that
> reflects the fact that you pass in an HttpRequest object and it has
> context processors. RequestContext, SuperContext, FlexContext,
> AdvancedContex
On 1/12/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > > django.core.template -> django.template
> > > - includes Context/DjangoContext
Let's go ahead with this one: django.core.template becomes django.template.
While we're at it, let's rename DjangoCo
On 1/12/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > One thing, with all of changes, the django.db.models thing ends up being
> > quite deep for such a core part. Thoughts?
>
> I think django.models sounds nice, although it would be confusing for
> existing users (aside from the 5-ish peop
On 1/11/06, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
> This all sounds good to me ( although I care less about this than some
> ). Good to compress the name churn into a short time period if possible,
> ie all in magic removal
>
> One thing, with all of changes, the django.db.models thing ends
On 1/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/7/06, kmh <[EMAIL PROTECTED]> wrote:
>
> > django.core.template -> django.template
> > - includes Context/DjangoContext
>
> +1. Another great change.
>
>
> > django.core.formfields -> django.fo
On 1/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> The reasoning behind using the same docs for the latest release (0.91)
> and SVN is that we make a *lot* of documentation improvements, and
> users of 0.91 should benefit from those -- i.e., the docs for 0.91
> shouldn't be frozen.
Fair enou
Currently, you can design your database to include a link to a file
that has already been uploaded 'meta.FilePathField' or you can actually
upload the file 'meta.FileField' (and yes 'meta.ImageField'). But the
main dilema i see is when you want to let your editors include their
own layouts for th
On 1/12/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote:
> The current docs reflect the 0.91 release, which I think is where the
> emphasis should lie.
> Next to that we should have a copy of the 0.91 in a development
> location for people tracking the development version.
>
> djangopr
On 1/12/06, Tim Keating <[EMAIL PROTECTED]> wrote:
> One quick question -- are you guys making the corresponding changes to
> the docs? (The tutorials, especially.) If not, I may be able to do some
> of that.
We've done some of the changes to the docs, but not all. If you're
interested in helping
On 1/12/06, Tim Keating <[EMAIL PROTECTED]> wrote:
> One quick question -- are you guys making the corresponding changes to
> the docs? (The tutorials, especially.) If not, I may be able to do some
> of that.
The current docs reflect the 0.91 release, which I think is where the
emphasis should lie
On 1/12/06, bsoltani <[EMAIL PROTECTED]> wrote:
> How difficult would it be to make Django display DEBUG information only
> to a certain type of user? i.e. have the nice debug error pages for
> the admins but not regular users?
>
> Not even sure if this is possible to implement
Of course it's po
One quick question -- are you guys making the corresponding changes to
the docs? (The tutorials, especially.) If not, I may be able to do some
of that.
On 12 Jan 2006, at 14:44, Simon Willison wrote:
http://www.flickr.com/services/api/misc.encoding.html
ROTFL!
Could you make that text a bit bigger? I’m not sure which encoding is
expected by the Flickr API :-p
--
Antonio
Antonio Cavedoni пишет:
>> The patch to #914 is just sitting there because there is no comment
>> from the core devs on it - but I think we should do either the
>> unicodefication or the patch from #914, with my preference being the
>> unicodefication.
>
>
> I’m +1 on the full unicodefication a
Simon Willison wrote:
We really need an official Django logging framework so stuff like this
can be logged (rather than the current email-to-admins workaround which
doesn't scale to large deployments).
Semi-related note: I really like current js-enabled error reports, which
are produced wi
For those that seem to like the idea of shorter comments, I whipped up
this piece of middleware for your projects. It's my first attempt at
middleware so the code might seem a bit immature for you advanced
djangoers out there. I opted to use the {# #} syntax, but that can
easily be changed in th
> Also its not very
> clear when modifying templates what all variables are available, and I had
> to regularly go back to view code to reconfirm the variable names etc.
You may find the built-in view/model docs (hit "/admin/doc/" with admin
installed) very helpful.
>> We really need an official Django logging frameworkIf you consider adding logging module into Django, take a look at keyword based logging.
http://agiletesting.blogspot.com/2005/06/keyword-based-logging-with-py-library.htmlRadekOn 1/12/06, Simon Willison
<[EMAIL PROTECTED]> wrote:On 12 Jan 20
On 1/12/06, Simon Willison <[EMAIL PROTECTED]> wrote:
On 12 Jan 2006, at 06:59, James Bennett wrote:> The Django docs say that template filters should always fail silently> and never raise exceptions; they should instead return either the> original input or an empty string, as appropriate. And when
How difficult would it be to make Django display DEBUG information only
to a certain type of user? i.e. have the nice debug error pages for
the admins but not regular users?
Not even sure if this is possible to implement
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 10 Jan 2006, at 20:35, Antonio Cavedoni wrote:
Maybe we could start a “unicode” branch right after “magic-removal”
is merged back into the trunk?
+1, sounds smart.
I've been bitten by unicode problems a bunch of times while using
Django and I'm not even trying to build an internationa
On 12 Jan 2006, at 06:59, James Bennett wrote:
The Django docs say that template filters should always fail silently
and never raise exceptions; they should instead return either the
original input or an empty string, as appropriate. And when writing
template tags, the tag's render() method sh
On 12 Jan 2006, at 07:23, Amit Upadhyay wrote:
Another request: if debug is on, and if the url contains ?
dumpTemplateContext, and client IP in settings.trusted_hosts [and
blah blah blah depending on how paranoid you are],
render_to_response, and family, ignores the actual template, and
Hi all
I've had a closer look at ticket #1165 where the wrong SQL column name
is used for PositiveIntegerFields. The problem is that the data type
for foreignKeys gets derived from its referenced field with the
__dict__ of the referenced field. This is correct for fields like
CharFields, where i.
32 matches
Mail list logo
