4 ms·
This is good. Of course, this is how the if tag should work in django to begin with.
by apgwoz 17y ago
This is good. Of course, this is how the if tag should work in django to begin with.
- jacquesm 17y agoagreed. The 'crippling' has gone a bit too far I think, I can see the reason why they want to limit what you can do within a template but to not have the ability to combine expressions gets tedious really quickly. The argument seems to be that a template designer should not be able to break the site, that's not a very strong one because after all any brace or % sign removed will break the site just fine.
- yummyfajitas 17y agoI'm not entirely sure how {% if a == b %} will break the site, but {% ifequal a b %} will not. Maybe if someone destructively overloads __eq__?
- vesp 17y agoAgree. Seriously, don't know what they're waiting to commit this to the trunk. IMHO the template system in Django is too restricted and should get some steroids, despite the designer point of keeping it simple. I think you can get the best from both worlds.
- jacquesm 17y agoI think part of the resistance here is that rolling this in to trunk would be an admission they got it wrong in the first place. There is a lot of psychology behind the scenes in open source projects. In big companies this can express itself as NIH and other symptoms like that, in open source projects it usually means that sooner or later somebody admits they were wrong in the past or that a project will fork or that there will be 'unofficial' patches. The python absence of a 'switch' statement is another nice example of such an issue.
- ubernostrum 17y agoBefore you go reading hidden motivations into the design of Django's template language, I think you should read Jacob's explanation of his approach to templating: http://jacobian.org/writing/salt/ http://jacobian.org/writing/salt/ Personally, I'm inclined to agree with him, and I take a stance similar to what's expressed in one of the comments there: it's better to leave a potentially-good feature out, but provide the means for people to implement it when they need it, than to burden the language with a potentially-bad feature that's hard to disable.
- jacquesm 17y agoIf you have an if, and ifequals and their functions are such that if you need to do a combined if something and something > somethingelse you have to resort to either duplicating a bunch of code or including small fragments of html in order to avoid the duplication severely decreasing readability then your design is simply lacking. There is an outstanding ticket on adding boolean functionality to the ifequals conditional. The argument that others 'should learn to cook' can be countered with that if you're a cook you should cook what people like to eat, not to dictate your taste to others. The if, ifequals and other animals in the conditional zoo could be replaced with a single multi purpose and powerful if statement such as listed in the link above. You either have an if or you don't, if you have one it might as well work. There is not much 'bad' about an if statement that would be worse than the endless duplication of template code that the current construct forces you to adopt. This is a problem because any django apps that are going to be released using the more powerful 'if' statement will immediately have an extra dependency. I have yet to see a single good argument about what would be so dangerous about having a more powerful if statement in the template language.