Re: math tag

[Yishai Beeri]

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 following result when
the URL is http://localhost:8001/?x=2=3=4
if x = 2, y = 3, 2 + 3 = 6
if x = 2, y = 3, 2 * 3 = 6
if x = 2, y = 3, z = 4, (2^4) * (3^4) = 1296
if x = 2, y = 3, z = 4, (2 + 3) / 4 = 1



While I think there are common display issues that require a little more  
than the current tags, this example is the exact opposite. This is exactly  
the case where the math should be done in the view, never in the template.  
What if you want to display these calcs in a table, or in a  tag? Copy  
the entire template over and change the tags?


Cases for display logic include, off the top of my head:
- substract, mainly for knowing how much width is left in some element for  
display (total width - sum of widths for some elements we loop through)

- multiply (again, width calculations)
- divide + remainder - supplements divisibleby in cases you need to know  
the size of the tail you're left with


But I can't think of any such use for stuff like pow (^), or even complex  
parenthesized expressions.


Yishai

--
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 group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: math tag

[Tom Evans]

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 template with a
>> pre-calculated result.
>>
>> So, my inclination would be to say no, this doesn't have a place in
>> the default list of tags.
>>
>> Yours,
>> Russ Magee %-)
>
> The example I provided is a bad one, but the math tag is general
> purpose. It can potentially reduce the number of custom filters or
> amount of work needed in the view function.
>
> Here's another take:
> {% load mathtag %}
>  {% with x=request.GET.x y=request.GET.y z=request.GET.z %}
>    if x = {{ x }}, y = {{ y }}, {{ x }} + {{ y }} = {% math x y "$1 *
> $2" as result %}{{ result }}
>    if x = {{ x }}, y = {{ y }}, {{ x }} * {{ y }} = {% math x y "$1 *
> $2" as result %}{{ result }}
>    if x = {{ x }}, y = {{ y }}, z = {{ z }}, ({{ x }}^{{ z }}) *
> ({{ y }}^{{ z }}) = {% math x y z "($1**$3) * ($2**$3)" as result %}
> {{ result }}
>    if x = {{ x }}, y = {{ y }}, z = {{ z }}, ({{ x }} + {{ y }}) /
> {{ z }} = {% math x y z "($1 + $2) / $3" as result %}{{ result }}
>  {% endwith %}
>
>
> Given the frequency of such request by other users warrants a re-look
> IMO.
>

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.

There is a reason for view functions, we can express the icky logic
that determines what to display on the page in a nice, concise manner,
and leave the formatting and display of that information to the view
layer.

>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.


Cheers

Tom

-- 
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 group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: math tag

[Daniel Moisset]

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 data display enhances the design" is a
good argument for a simpler template language. "Template writers are
dumb" isn't

Regards,
   D.

-- 
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 group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: math tag

[Tom Evans]

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 screw it too, using that logic...
>
> Saying "separating logic from data display enhances the design" is a
> good argument for a simpler template language. "Template writers are
> dumb" isn't
>
> Regards,
>   D.
>

Bit of a leap there, that is not what I said. Designers and developers
have different skill-sets, it is nonsense to pretend otherwise.

Designers typically do not have the programming skills of a developer,
so expecting them to edit templates containing business logic is error
prone, and difficult to apply unit tests to. This is precisely why the
MVC pattern is so persistently popular, by separating business logic
from presentation.

Unit tests can be easily applied to view logic, where as template
output is more nebulous to test. I'm not saying designers screw up
more than developers, but developers are more attuned to producing
business logic than designers, since that is their job.

Django itself has a similar position, forbidding (or making no-ops)
things like {{ User.objects.all.delete }} in templates, to avoid
unintentional data loss by the designer.

Cheers

Tom

-- 
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 group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: math tag

[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 template,
the "solution" on the other hand is inconvenient at best.

I must admit the examples are badly written and do not reflect the actual
problem. The point here though, is that a general purpose math tag should be
available by default. *The* math tag may be too flexible for its own good.
If we have a dumber solution, I'm fine with that so long it supports the
simplest cases, and that would be + - * / % min max and ().

One real world problem that I always have is trying to output Javascript
with Django template. Precomputing the values inside the view and pass them
into the template is annoyingly redundant when the values can be derived
from other objects in the context.

-- 
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 group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: math tag

[Johannes Dollinger]

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 template, 
> the "solution" on the other hand is inconvenient at best. 
> 
> I must admit the examples are badly written and do not reflect the actual 
> problem. The point here though, is that a general purpose math tag should be 
> available by default. *The* math tag may be too flexible for its own good. If 
> we have a dumber solution, I'm fine with that so long it supports the 
> simplest cases, and that would be + - * / % min max and ().

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 logarithmic scale.
* floor/ceil: Display floored or ceiled values.

I'd still be -1 regarding a {%math%} tag. The cleanest solution would be proper 
support for common operators mixed with a set of default filters for primitive 
functions (e.g log, floor, ceil, abs).

__
Johannes


-- 
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 group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: math tag

[Daniel Moisset]

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 logarithmic scale.
> * floor/ceil: Display floored or ceiled values.
>

What does the core team think about a math library with useful (like
in the examples above) filters? i.e, {% load math %} ... {{ x|abs }}
{{ y|log:"10" }}
Most cases I can think of are unary, so they lend nicely to the filter syntax..

In addition to the above, I can think of the following from the python
math module:
 * isinf (and maybe isnan)? to pretty print infinities
 * trunc. actually this/ceil/floor are somewhat covered by the float
formatting functions, but sometimes not enough.

I've found use at some project to binary conversions/bit
querying functions (to nicely display bitflags), but that might be
overkill for a general purpose library in the core.

> I'd still be -1 regarding a {%math%} tag. The cleanest solution would be 
> proper support for common operators mixed with a set of default filters for 
> primitive functions (e.g log, floor, ceil, abs).

Regards,
   D.

-- 
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 group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: math tag

[Gabriel Hurley]

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 out to be issues within Django that need to be resolved to make it 
possible then those could be fixed.

But as an immediate feature proposal for trunk, this one's been pretty 
strongly shot down.

-- 
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 group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: math tag

[Ian Kelly]

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 subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Ignorable 404s

[Aymeric Augustin]

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 endless 
discussion. An empty default would avoid that.

Luke suggested to replace them by a single setting IGNORABLE_404_URLS here: 
http://code.djangoproject.com/ticket/15954#comment:2

The two old settings would be deprecated, following the usual path. In the end, 
that will decrement the number of settings :)

That new setting would behave a lot like DISALLOWED_USER_AGENTS.

I am +1 on this suggestion, what do you think?

Best regards,


-- 
Aymeric Augustin.

-- 
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 group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Ignorable 404s

[Yishai Beeri]

+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, Aymeric Augustin  
 wrote:



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 endless  
discussion. An empty default would avoid that.


Luke suggested to replace them by a single setting IGNORABLE_404_URLS  
here: http://code.djangoproject.com/ticket/15954#comment:2


The two old settings would be deprecated, following the usual path. In  
the end, that will decrement the number of settings :)


That new setting would behave a lot like DISALLOWED_USER_AGENTS.

I am +1 on this suggestion, what do you think?

Best regards,





--
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 group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Suggestion for improvement to template block/extends tags

[amagee]

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 commonly done with the
{% extends %} tag already.  The base template is absolutely not
referencing the names of the templates that descend from it; that
would be silly as you point out.

On May 3, 10:25 am, Russell Keith-Magee 
wrote:
> On Fri, Apr 29, 2011 at 4:48 PM, Jonathan Slenders
>
>
>
>
>
>
>
>
>
>  wrote:
> > Hey, this pattern are nested decorators in templates.
>
> > Most people here are probably against having nested template tags with
> > the same name. I think it does only make sense when there's somehow a
> > distinction between a
> > "placeholder" and "content". Because otherwise, templates don't know
> > which block in the parent template need to be chosen when several have
> > the same name. (You'd say the most inner block, but that's not obvious
> > -- I think.)
>
> > I once wrote a {% decorate %} template tag for a little similar
> > behaviour.
> >https://github.com/citylive/django-template-tags/blob/master/src/djan...
>
> > That would become:
>
> > template.html:
> > {% decorate (either "a.html" or "b.html") %}
> > middle
> > {% enddecorate %}
>
> > b.html:
> > {% decorate "a.html" %}
> > left {{ decorator.content }} right
> > {% enddecorate %}
>
> > a.html:
> > first {{ decorator.content }} last
>
> > Hope that helps.
> > I once tried to get this into django trunk, but did not yet got
> > accepted.
>
> For me, this:
>
> > {% decorate (either "a.html" or "b.html") %}
>
> is enough of a reason to reject this proposal -- I fundamentally have
> no idea what this is trying to say, or why it's trying to say it this
> way. Why does a base template need to reference the names of the
> templates that descend from it? For me, this is completely bass
> ackwards.
>
> I'm also slightly confused as to why your proposal isn't already covered by:
>
> template.html
> {% block decorated %}
> middle
> {% endblock %}
>
> a.html
> {% extends template.html %}
> {% block decorated %}left {{ block.super }} right{% endblock %}
>
> b.html
> {% extends template.html %}
> {% block decorated %}first {{ block.super }} last{% endblock %}

This isn't the problem I'm trying to solve.  template.html extends
from a.html / b.html, not the other way around.  My original post
shows that the problem is different to this, I think.


>
> Yours,
> Russ Magee %-)

Thanks for checking this out :)

-- 
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 group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django urls in JavaScript

[Dimitri Gnidash]

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 already done, 
> checkhttps://github.com/django-extensions/django-extensions/blob/master/dj...,
> it can be easily converted to JSON (I have a branch that does it, but
> it's not up-to-date).
>
> I also have the urls module in JavaScript already, but as part of a
> larger library (https://github.com/mlouro/olivejs/blob/master/olive/
> urls/urls.js), both have been used in projects.
>
> An example:
>
> /* below is the output from "manage.py show_urls" in JSON format */
> olive.urls.load({
>     'dashboard': '/dashboard/',
>     'time_edit': '/projects//time/save//',
>     'task_edit': '/projects//task/save//'
>
> });
>
> olive.urls.get('task_edit', {
>         'project_id': 2,
>         'task_id': 1
>     })
>
> On Mar 24, 3:31 pm, Matt Robenolt  wrote:
>
> > I think the biggest problem with translating the reverse() lookup is the
> > lack of kwargs and named capture groups in Javascript regex. So a pattern
> > such as: /page/(?P\d+)/ would not translate whatsoever. Then on the
> > Javascript side, we wouldn't be able to use:  reverse('goto_page', [],
> > {page_id: 5});  It would have nowhere to map up the page_id variable to. We
> > could probably get away with some sort of pseudo regex rules in Javascript.

-- 
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 group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Make redirection customizable in ModelAdmin view

[Dario Ocles]

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 was about if we have to take care of backward
compatibility on this issue.

I uploaded two patches to #8001, one of them taking care of backward
compatibility.

I think that the reason for keeping backward compatibility, is just
that it is good.

And the reasons for deprecating the old behavior are:
- Cleaner code.
- This is not a documented part of Django's API, so we either can or
cannot take care of backward compatibility.
- I don't like to put any ugly try/catch.


I'm sorry for my English.

Regards,
Dario Ocles (burzak).

[0] http://code.djangoproject.com/ticket/15294
[1] http://code.djangoproject.com/ticket/8001

-- 
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 group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Make redirection customizable in ModelAdmin view

[Julien Phalip]

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 read all comments on ticket #15294).
>
> The discussion was about if we have to take care of backward
> compatibility on this issue.
>
> I uploaded two patches to #8001, one of them taking care of backward
> compatibility.
>
> I think that the reason for keeping backward compatibility, is just
> that it is good.
>
> And the reasons for deprecating the old behavior are:
> - Cleaner code.
> - This is not a documented part of Django's API, so we either can or
> cannot take care of backward compatibility.
> - I don't like to put any ugly try/catch.
>
> I'm sorry for my English.
>
> Regards,
> Dario Ocles (burzak).
>
> [0]http://code.djangoproject.com/ticket/15294
> [1]http://code.djangoproject.com/ticket/8001

Thanks for bringing this up, Dario. I'll try to summarise here the
discussion that we've had in those tickets.

As part of the effort in #15294 to remove all hardcoded urls from the
admin's codebase, it was suggested that the hardcoded
post_url_continue parameter in the response_add method be addressed as
well:

def response_add(self, request, obj, post_url_continue='../%s/'):
...

post_url_continue is generally used to redirect you to the new
object's change page after it's been created. Since it is impossible
to reverse that object's change page url if you don't know the
object's model details and primary key, it was suggested that
post_url_continue default to None and that the url be reversed from
inside the response_add method.

Now, it was also pointed out that the current use of post_url_continue
was a bit limiting in that it assumes the value to be a formattable
string with one format parameter (i.e. the pk). There is a backwards
compatible way of dealing with this [1], and a backwards incompatible
way [2]. The former first assumes that it receives a formattable
string like in the "old" way, and if that generates an error then it
assumes it's a pre-formatted string. The latter only assumes it's a
pre-formatted string. I personally tend to prefer the latter as the
implementation is cleaner and also more flexible -- it is based on the
assumption that it is the developer's responsibility to provide a pre-
formatted string if they want to override the default behaviour,
instead of letting Django's response_add method do the formatting for
you.

If we go with [2] then this may be a small inconvenience for people
who are relying on the current behaviour of response_add, but the
upgrade path is very easy (i.e. just format the string yourself).
Also, response_add is not officially documented.

So, this all leads to the reason why this was brought up to the dev
list: shall we go ahead and break backwards compatibility? As far as I
can tell from the policy [3] we're pretty safe to go ahead, but it'd
be helpful to collect more opinions on this (and if possible also more
generally on the rest of the admin's codebase).

Thanks a lot!

Julien

[1] 
http://code.djangoproject.com/attachment/ticket/8001/8001_redirection_backward_compatibility.diff
[2] http://code.djangoproject.com/attachment/ticket/8001/8001_redirection.diff
[3] http://docs.djangoproject.com/en/dev/misc/api-stability/

-- 
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 group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.