On Tue, Mar 12, 2013 at 12:04 PM, Moritz Heidkamp < [email protected]> wrote:
> Matt Gushee <[email protected]> writes: > > 3) {% if not loop.last %} also raises a parser error. This was a fairly > > important feature for me, because I have a couple of templates that > > generate JSON from arbitrary-length lists of objects, and there needs to be > > a comma *between* the objects in JSON. So I was doing this: > This doesn't seem like a very good idea to me. You might generate > invalid JSON if the values you pass into the template don't happen to > have textual representations which also happen to be valid JSON values > (if I understand the way Jinja works correctly here). I'd suggest using > a proper JSON emitter like the one contained in medea > (http://wiki.call-cc.org/eggref/4/medea) instead. In this specific case it is highly unlikely there will be any invalid data, but I'm sure you're right in general. In the round of development just completed, I was concentrating on reimplementing the site in a new language, with as few changes as possible. And my memory isn't 100% clear as to why I chose to generate JSON with templates when I coded the site in Python--because Python certainly has a JSON library, if not several of them. It may have been because I wanted the JSON to be readable. It would be nice for development if JSON libraries had a 'pretty-print' option for the output. On Tue, Mar 12, 2013 at 1:11 PM, Peter Bex <[email protected]> wrote: > Not to sound like a broken record, but I'd add that this applies 100% to > HTML/XML as well. I would suggest using SXML or something similar over > a string-based templating language. This allows you to prevent > injection bugs as well as accidental mismatching of opening/closing tags. Hmm. 11 or 12 years ago I might have said something very similar ... you see, I was an XML consultant and trainer for a time. And I don't disagree in principle, but I am approaching this from a pragmatic perspective. As far as the current web site goes, I don't think it matters very much. It's a simple site, solely maintained by me, and the data being passed around is very tightly controlled, etc. And if I were only concerned about my own site, I probably would use SXML. The reason I used Ersatz for this project is that I wanted to try it out before moving on to some other projects intended for use by others. And in fact, I feel it is important for these upcoming projects to have a designer-friendly templating system. It doesn't necessarily have to be Ersatz, but I'm not sure what else would fulfill that requirement. I see the suggestion to use XML, but I'm really skeptical as to whether that would be acceptable to non-technical people. It may be that the landscape has changed a bit--I've been out of the loop for a few years--but based on my past experience as an XML geek, it seems to me that most people, even some experienced programmers find all the angle brackets really intimidating. Many designers are familiar with [X]HTML of course, but I've seen too many people go into fight-or-flight mode as soon as they start seeing unfamiliar tag names to feel optimistic about any kind of non-HTML markup. Also, backing up a step to your SXML recommendation, I actually don't see what SXML per se has to do with preventing injection bugs. After all, it is just a representation of a data tree, and if it is used template-wise, *something* has to be interpolated. Now, I have seen that at least some of the SXML tools for Chicken have built-in escaping for markup characters (as does Ersatz, by the way) but what about malicious Javascript? But maybe I'm missing something pretty obvious ... I do have to admit I don't know as much as I should about the whole malicious-code injection issue. Finally, an idea has occurred to me. What about a templating system where what actually gets used at runtime is SXML, but designers could create templates in XHTML, then when they are satisfied with the design, use a preprocessing tool to convert them to SXML? That would at least ensure well-formed markup. Anyway, thanks to everyone for the discussion, and any additional thoughts you may have. -- Matt Gushee
_______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
