On May 4, 4:13 pm, Yishai Beeri wrote:
> +1 on breaking backwards compatibility, defaulting the arg to None.
Just a note. Defaulting to None in itself does not break
compatibility. Defaulting to None allows to do the url reversal from
inside response_add. But then the tradeoff of preserving backw
+1 on breaking backwards compatibility, defaulting the arg to None.
However, in [1] Julien suggests to also allow a callable - which I think
would be very useful, and provide all the flexibility one would need.
So IMHO:
- if arg is callable, call it with signature as suggested in [1]
- if a
On May 4, 10:59 am, Dario Ocles wrote:
> Hello everybody.
>
> Ramiro Morales and me were working on this ticket #15294 [0] and
> Julien linked this one #8001 [1]. We had a little discussion about two
> possible solution for #8001 and Julien suggested that we should hear
> your opinion (you can rea
Hello everybody.
Ramiro Morales and me were working on this ticket #15294 [0] and
Julien linked this one #8001 [1]. We had a little discussion about two
possible solution for #8001 and Julien suggested that we should hear
your opinion (you can read all comments on ticket #15294).
The discussion w
Hey Marco,
I have forked your library on GitHub and added the management command
to build a list of urls and output the file in the format that is
specified by django-js-utils.
https://github.com/Dimitri-Gnidash/django-js-utils
Cheers
On Mar 24, 11:37 am, Marco Louro wrote:
> That's also alrea
Hi Russ.
{% decorate (either "a.html" or "b.html") %}
This isn't actual syntax; it's just trying to communicate that the
subtemplate (not the base), can extend either a.html or b.html. It
would be implemented by {% decorate base_template %}, where
base_template is a context variable. This is co
+1 on both: combine to regex IGNORABLE_URLS, and on empty defaults with
commented-out suggestion in generated settings.py
As a bonus, the transition for someone who has placed non-default values
in IGNORABLE_(STARTS_ENDS) to regexes is near trivial.
On Tue, 03 May 2011 23:16:12 +0300, Aymeri
Hello,
Currently, there are two problems with settings.IGNORABLE_404_(STARTS|ENDS):
- STARTS + ENDS is too limited: for example, there's no way to exclude
icon requests of iOS >= 4.2. A list of regexps would be more flexible.
- The default values are fairly arbitrary and prone to
On Tue, May 3, 2011 at 12:57 PM, Johannes Dollinger
wrote:
> * __mul__: Display a value of 0.42 as 42%.
This would be better implemented as a "percentage" filter, IMO. It
would be a natural candidate for inclusion in django.contrib.humanize.
--
You received this message because you are subscri
This is a case where there's nothing stopping anyone (as far as I can
see) from creating such a tag as an external library. If it garners
significant community support and has numerous compelling use cases, then it
would be a candidate for inclusion in trunk. If, in developing it, there
turn ou
On Tue, May 3, 2011 at 3:57 PM, Johannes Dollinger
wrote:
>
> FWIW, here are some concrete use-cases for math in templates:
>
> * __mul__: Display a value of 0.42 as 42%.
> * __neg__/__abs__: Display the absolute value and signum of a number
> separately.
> * log: Display a number on a logarithmi
Am 03.05.2011 um 18:27 schrieb Phui Hock:
> Or, in a sane world:
>
> if x = {{ x }}, y = {{ y }}, {{ x }} + {{ y }} = {{ x_plus_y_res }}
> if x = {{ x }}, y = {{ y }}, {{ x }} * {{ y }} = {{ x_star_y_res }}
>
> and so on.
>
> While it is a common consensus that logic should never be in the t
>
> Or, in a sane world:
>
> if x = {{ x }}, y = {{ y }}, {{ x }} + {{ y }} = {{ x_plus_y_res }}
> if x = {{ x }}, y = {{ y }}, {{ x }} * {{ y }} = {{ x_star_y_res }}
>
> and so on.
>
While it is a common consensus that logic should never be in the template,
the "solution" on the other hand is in
On Tue, May 3, 2011 at 3:24 PM, Daniel Moisset wrote:
> On Tue, May 3, 2011 at 9:19 AM, Tom Evans wrote:
>>
>> From another POV, there is no chance for the designer to screw the
>> template up and calculate the wrong value, if he is only allowed to
>> output data.
>>
>
> And the view writer can s
On Tue, May 3, 2011 at 9:19 AM, Tom Evans wrote:
>
> From another POV, there is no chance for the designer to screw the
> template up and calculate the wrong value, if he is only allowed to
> output data.
>
And the view writer can screw it too, using that logic...
Saying "separating logic from d
On Tue, May 3, 2011 at 4:46 AM, Phui Hock wrote:
> On May 3, 7:43 am, Russell Keith-Magee
> wrote:
>> This stems back to the design motivation of Django's template language
>> -- you shouldn't be doing math in the template. Instead, you should be
>> doing your math in the view, and providing the
On Tue, 03 May 2011 06:59:02 +0300, Phui Hock wrote:
Holy god, not to be rude, but given that this is completely unreadable
I'm
even more -1 than I ever would have been on the basis of the principle
of a
dumber template language.
Alex
My apologies. All that is doing is rendering the foll
17 matches
Mail list logo