This is the dynamically-typed equivalent of Joel Spolsky's suggested Hungarian solution to the problem.
I'd call it rather the strongly typed equivalent of Spolsky's Hungarian notation solution. I've seen very similar things worked out in Haskell, which is statically typed, but again (like Python) strongly typed. Presumably a similar system could be worked out for Java.
And while I agree that there is strong advantage to having variables richly annotated with what kind of text they contain, you're still going to need some way in the template to say something about the context in which some piece of text is being expanded - for example, if you want to pass a variable into some bit of javascript, you really don't want your template engine to turn & into &, but it would be nice to backslash quote marks and other potentially dangerous things in the string. So even with this kind of approach, you're still going to want to annotate spots in the template to describe something about where the field is being used, so that the appropriate type of quoting transformation can occurr.
That being said, with this approach there's virtually no call for some context marker that says "this here should be plaintext" (I guess maybe you might want that inside a CDATA chunk, but even there you'd want some way to quote the CDATA end sequence), so it's guaranteed that the default context is going to be the context in which the way to quote things is to html-encode them.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2007-04-23 01:13 am (UTC)And while I agree that there is strong advantage to having variables richly annotated with what kind of text they contain, you're still going to need some way in the template to say something about the context in which some piece of text is being expanded - for example, if you want to pass a variable into some bit of javascript, you really don't want your template engine to turn & into &, but it would be nice to backslash quote marks and other potentially dangerous things in the string. So even with this kind of approach, you're still going to want to annotate spots in the template to describe something about where the field is being used, so that the appropriate type of quoting transformation can occurr.
That being said, with this approach there's virtually no call for some context marker that says "this here should be plaintext" (I guess maybe you might want that inside a CDATA chunk, but even there you'd want some way to quote the CDATA end sequence), so it's guaranteed that the default context is going to be the context in which the way to quote things is to html-encode them.
There's also the occasional time when you'll want multiple encodings applied, such as when substituting into a javascript variable that you then insert into the innerHTML attribute of something else on the page.