My apologies, I did not intend to trigger an offtopic discussion, even a semi-related one. My intent was merely to point out that Django's templating system is far from perfect, and that improving it is definitely a goal of Django, even if we reject a particular change that may appear to be for the better. I put forward PHP as an opposing example because, for all the flaws it has, you must admit that the ability to use the entire host programming language in the context of a template is both incredibly powerful and quite intuitive. The natural counter is that, as you have pointed out, it is also trivial to misuse, and indeed the case may be made that PHP's method encourages (nay, nearly requires) mixing logic and presentation, which has major disadvantages.
I did not expand that point in full in an attempt to downplay the example, but it seems that I created the opposite effect. Again, my apologies for that. If we may return to the topic at hand, in my (admittedly uneducated) opinion, Jacob is going too far to unilaterally declare that the template syntax will not be changed, without any qualifiers. It is, however, not a change to be made lightly, and would require a solid reason and the support (even begrudgingly) of both developers and users. From both my own impressions and the comments of others, this particular change does not seem to have anything that even comes close to a solid reason, nor does it have any apparent support beyond the person proposing the change. Thus, while I disagree that "We're not [ever] changing the template syntax.", I think it's fair to say that this particular change has been rejected for now. As Chuck pointed out, there is always the chance that the tides will change at a later date. If that seems like rough treatment, consider this: If the Django project was not interested in improving itself, it would have allowed no room for discussion at all. So while the rejection may seem to be unanimous, as if we were all jumping in to drown you out, the reality is that we were trying to give it a chance to win us over, and it just didn't. Or, more succinctly: We appreciate the suggestion and applaud your intent, but *waves hand* "This is not the change you're looking for." -FM On Thu, May 27, 2010 at 12:33 PM, Tom Evans <[email protected]> wrote: > I never claimed it wasn't; it was stipulated that Django's template > system wipes the floor with all others, and it is inconceivable to > think more favourably of a different system. > > I was trying to point out that there are features which are available > in other template languages, which people may consider to be superior, > but which do not fit into the django philosophy. > > wrt calling functions that take arguments, allow me to re-state: in > smarty you can call _arbitrary_ functions. Template tags allow you to > call _specific_ functions. It's a design decision, and I'm very glad > that you cannot in django - if you've ever had to edit ZPT, you would > understand. > > At the end of the day, if you truly disagree with the syntax/style of > django's templating engine, it is trivial these days to plug in a > different engine. > > Cheers > > Tom > > On Thu, May 27, 2010 at 1:23 PM, Chuck Harmston <[email protected]> > wrote: >> The inability to assign variables is an intentional design decision; one of >> Django's core tenets is that business logic and presentational logic should >> be separated. The template language was crafted to provide non-programmers >> (front-end developers and designers) the ability to work directly on >> templates without having to touch the business logic. Though there are use >> cases where defining variables would be helpful, it's a good flag that >> you're approaching the problem the wrong way. >> Additionally, you can call functions that take arguments, it just takes a >> slightly different form than you might expect: custom template tags [2]. >> This allows you to extend the functionality of the template language while >> still maintaining the separation of business and presentational logic. >> An interesting historical example of the above two paragraphs: the smart {% >> if %} tag [1], which was borne of the lack of an ability to use complex >> logic in Django templates. >> And the important footnote: I don't mean to stifle your suggestion; quite >> the opposite, actually! As Jacob has admitted [3], there is an occasional >> need in the Django for designers to tell the programmers to STFU. To extend >> the previous example: the smart {% if %} tag was originally shot down but >> was ultimately implemented in core [4]. >> [1] http://djangosnippets.org/snippets/1350/ >> [2] http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#passing-template-variables-to-the-tag >> [3] http://groups.google.com/group/django-developers/browse_thread/thread/18bca037f10769e9/cfd908f97b44e324?lnk=gst#cfd908f97b44e324 >> [4] http://code.djangoproject.com/changeset/11806 >> >> >> On Thu, May 27, 2010 at 7:36 AM, Tom Evans <[email protected]> wrote: >>> >>> Most PHP templating languages allow you to do things that are by >>> design not in django's templating, for example in Smarty, one can >>> assign new variables on the fly in the template, and even do crazy >>> stuff like call functions that take arguments. >>> >>> Whether that is 'better' or not is a point of view - as you've a >>> commit bit, and patches for this sort of stuff in django are rejected, >>> I'd guess you are of the view that it is not ;) >>> >>> 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 [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/django-developers?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
