On 3/9/08, Gary Wilson Jr. <[EMAIL PROTECTED]> wrote:
>
>
> In many instances, there are ways to move the complexity out of the
> templates
> and into the code. This is a big reason why the template language is so
> limiting, as it forces you to put the complexity in the code where it
> should
> b
Yuri Baburov wrote:
> I don't like the point of view that "everyone has his own library",
> because it's too childish. It isn't a solution at all, it's just a
> despair after attempts to find a good enough solution.
> You did a great thing inventing simple and useful ORM, good template
> language,
I don't like the point of view that "everyone has his own library",
because it's too childish. It isn't a solution at all, it's just a
despair after attempts to find a good enough solution.
You did a great thing inventing simple and useful ORM, good template
language, lots of other great stuff.
Bu
On Fri, Mar 7, 2008 at 9:18 PM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>
> Though me and you are C++ experts, please forget about C and C++.
> I'd like to see any tiny bit of *constructive criticism*.
Constructive criticism doesn't mean that I am obliged to agree with
you. I think that your pr
Though me and you are C++ experts, please forget about C and C++.
I'd like to see any tiny bit of *constructive criticism*.
Don't know why, but you are arguing not against my arguments.
On Fri, Mar 7, 2008 at 6:26 AM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
>
> On Fri, Mar 7, 2008 at 8:53
OK, folks; time to drop this particular argument. As you can see from
this thread, a consensus here is not forthcoming, and now we're all
just wasting time.
I'd encourange anyone who likes Django templates but wants something
more programmer-oriented to take a look at Jinja (inspired by Django)
o
There must be a lot of us who have created a similar filter. My particular
version looks like this:
from django.template import resolve_variable
def lookup(value, key):
return resolve_variable(key,value)
so that it behaves like the normal attribute access.I use this to do things
like send a lis
On Thu, Mar 6, 2008 at 8:25 PM, Ian Kelly <[EMAIL PROTECTED]> wrote:
> Why do I have a sudden fear that a branch is going to spawn called
> "newtemplates"?
That won't be happening. As Jacob noted eloquently, this
filter/feature isn't something worth adding at this time.
It's quite easy to add
On Thu, Mar 6, 2008 at 7:06 PM, Collin Grady <[EMAIL PROTECTED]> wrote:
> To keep things consistent though, you'd then likely have to change normal
> access
> to work like that as well, so instead of foo.bar to look up the key "bar"
> you'd
> have to change it to use foo["bar"], which would b
Matthew Marshall said the following:
> What's wrong with ``{{ foo[bar] }}`` ?
>
> That's how it's done in python, javascript, php, and others. Most people
> writing html templates will be somewhat familiar with at least Javascript.
To keep things consistent though, you'd then likely have to ch
On Tuesday 04 March 2008 14:54:38 Jacob Kaplan-Moss wrote:
> Second, there's the question of weather this is a first-class
> language-level feature or a filter. If it's the former, there's a
> syntactic decision to be made; some have proposed something like ``{{
> foo.$bar }}``, but anything that
On Fri, Mar 7, 2008 at 8:53 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
>
> I suggest {{ foo->bar }} syntax. It is simple, common to programmers,
> easy to remember and recognize, does not interfere with any other
> features.
-1.
1) The primary audience of the Django template language is desi
I suggest {{ foo->bar }} syntax. It is simple, common to programmers,
easy to remember and recognize, does not interfere with any other
features.
On Wed, Mar 5, 2008 at 5:50 PM, vcc <[EMAIL PROTECTED]> wrote:
>
> I got another ID: foo.(bar)
> It's clear and no conflict, also can use nested, for
- Original Message -
From: "Collin Grady" <[EMAIL PROTECTED]>
To:
Sent: Thursday, March 06, 2008 3:59 AM
Subject: Re: Pick a value from list variable in templates
>
> vcc said the following:
>> I got another ID: foo.(bar)
>> It's clear an
vcc said the following:
> I got another ID: foo.(bar)
> It's clear and no conflict, also can use nested, for example
> foo.(one.(tow.(three))).
> or maybe: foo(bar) is look better.
But that suffers the same issue as the __bar__ syntax - it's already used by
function calls - you need to stop try
I got another ID: foo.(bar)
It's clear and no conflict, also can use nested, for example
foo.(one.(tow.(three))).
or maybe: foo(bar) is look better.
Best regards,
vcc
_
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
On Wed, 2008-03-05 at 11:16 +0200, Lauri Ahonen wrote:
>
>
> On 3/4/08, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
>
> It's also the thin edge of the wedge in some sense: Django's
> templating
> language is intentionally super-simple. Presentation
On 3/4/08, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
>
>
> It's also the thin edge of the wedge in some sense: Django's templating
> language is intentionally super-simple. Presentation stuff only in
> tempates, all selection/business logic in the views. So by the time your
> context gets to
-
> From: "Ian Kelly" <[EMAIL PROTECTED]>
> To:
> Sent: Wednesday, March 05, 2008 2:18 PM
> Subject: Re: Pick a value from list variable in templates
> > Besides, it introduces a naming conflict. When I write {{ foo.__bar__
> > }}, do I mean `getattr
On Tue, Mar 4, 2008 at 1:37 PM, Lauri Ahonen <[EMAIL PROTECTED]> wrote:
> Is there a sound technical reason not to add a filter, ie. is there a
> performance penalty involved? Or is there a fundemental problem with the
> design that I had in the first posting? I'm going to be adding this
> functio
- Original Message -
From: "Ian Kelly" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, March 05, 2008 2:18 PM
Subject: Re: Pick a value from list variable in templates
> Besides, it introduces a naming conflict. When I write {{ foo.__bar__
> }}, do I mean `getattr(fo
On 3/4/08, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
>
> On 3/4/08, Lauri Ahonen <[EMAIL PROTECTED]> wrote:
> > Exactly. This seemed like such a basic concept (select from array based
> on
> > variable value) that I was sure that it's hidden in django somewhere. I
> > can't be the first one to
On Tue, Mar 4, 2008 at 10:16 PM, vcc <[EMAIL PROTECTED]> wrote:
> > vcc said the following:
> >> How about: {{ foo.__bar__ }} ?
> >
> > Except you can't use _ as the first character in a template lookup like
> > that,
> > and the __foo__ naming method is already taken by existing things like
- Original Message -
From: "Collin Grady" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, March 05, 2008 12:49 PM
Subject: Re: Pick a value from list variable in templates
>
> vcc said the following:
>> How about: {{ foo.__bar__ }} ?
>
> Except you can&#
vcc said the following:
> How about: {{ foo.__bar__ }} ?
Except you can't use _ as the first character in a template lookup like that,
and the __foo__ naming method is already taken by existing things like __get__,
__contains__, and other such methods/attributes :)
--
Collin Grady
Necessity
- Original Message -
From: "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, March 05, 2008 1:54 AM
Subject: Re: Pick a value from list variable in templates
>
> On 3/4/08, Lauri Ahonen <[EMAIL PROTECTED]> wrote:
>> Exactly. This seemed
On Tue, 2008-03-04 at 19:23 +0200, Lauri Ahonen wrote:
>
>
> On 3/4/08, Collin Grady <[EMAIL PROTECTED]> wrote:
>
> Luke Plant said the following:
>
> >> It is already in core. See:
> >>
> http://www.djangoproject.com/documentation/templates/#v
On Tue, Mar 4, 2008 at 6:54 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> Second, there's the question of weather this is a first-class
> language-level feature or a filter. If it's the former, there's a
> syntactic decision to be made; some have proposed something like ``{{
> foo.$bar }}
On 3/4/08, Lauri Ahonen <[EMAIL PROTECTED]> wrote:
> Exactly. This seemed like such a basic concept (select from array based on
> variable value) that I was sure that it's hidden in django somewhere. I
> can't be the first one to need this?
The problem is, unfortunately, a lot more thorny than it
On Tue, Mar 4, 2008 at 11:23 AM, Lauri Ahonen <[EMAIL PROTECTED]> wrote:
> Exactly. This seemed like such a basic concept (select from array based on
> variable value) that I was sure that it's hidden in django somewhere. I
> can't be the first one to need this?
Yes and no. The thing is that a Py
On 3/4/08, Collin Grady <[EMAIL PROTECTED]> wrote:
>
>
> Luke Plant said the following:
>
> >> It is already in core. See:
> >> http://www.djangoproject.com/documentation/templates/#variables
>
>
> >No, it isn't - {{ foo.bar }} is the same as foo['bar'] not foo[bar], so
> it won't
> >do what they'
Luke Plant said the following:
> It is already in core. See:
> http://www.djangoproject.com/documentation/templates/#variables
No, it isn't - {{ foo.bar }} is the same as foo['bar'] not foo[bar], so it
won't
do what they're talking about - they want to have a variable bar as, say, 3,
and
ha
On Sunday 02 March 2008 23:20:53 Nikanj wrote:
> Hi,
>
> I whipped together a filter like below. Is there a good reason why
> such functionality should not be in Django core?
It is already in core. See:
http://www.djangoproject.com/documentation/templates/#variables
Regards,
Luke
--
"God d
Hi,
I whipped together a filter like below. Is there a good reason why
such functionality should not be in Django core? I know the error
handling is ugly, but it fills my needs quite nicely. I'm using it in
templates like {{ myModel.getLocalizedNames|pick:userLanguage }}
def pick(value, arg):
34 matches
Mail list logo
