Re: [SMARTY-DEV] syntax error: expecting '=' after attribute name

Boots wrote: > First, under this scheme, "include" should now be an attribute of xx, > but that is NOT what is suggested here. So it looks like a somewhat > shady feature is proposed only so that it can then be used to hack > another feature -- ugh. I guess it does look that way, but I've come across this before, with more "legitimate" uses, but this was the first time (albeit an ugly hack) where I couldn't easily work around it. > FWIW, the correct way to comment in Smarty is of course to use the > built-in comment construct {* ... *}. On the other hand, you may object > because you cannot nest comments. Do the same thing you'd have to do in > PHP to get around that: Actually, it's not the nested comments which are the problem, more the lack of end-of-line comments in templates (not that I'd argue for that to be added). I found it useful during development be able to temporarily switch off individual smarty elements quickly and simply; sticking xx at the start of the element achieved (or would have achieved :-) precisely that. > As a bonus, code need only be searched for occurences of the otherwise > unused {if 0} to find the locations of those "temporary" patches. Likewise, searching for "{xx" is trivial. > > > But also consider situations where > > > {checkbox name="test" value="testval" checked} > > > is more readable than > > > {checkbox name="test" value="testval" checked=1} > > That's sort-of specious because actually, it isn't easier at all, > perhaps even harder. "Easier" here isn't just about using less > characters--it is about imparting unambigous meaning concisely, and > IMHO, the first example fails that test. That depends on your target audience: <input type=checkbox name="test" value="testval" checked> .. would be more familiar to most HTML coders (although I take Monte's point about XHTML). I also find that options like "enabled" or "disabled" are preferable to "enabled=1" or "enabled=0". In any case, this isn't something I feel strongly about; I do think that (if it could easily be parsed, which it seems is not the case) then this would be useful but never essential, and taking on board the comments about XHTML I don't feel I can make a string case for it. To tackle the one specific point I was trying to solve, though: In principle, at least, what would be the opinion on implementing {// ... } as a single smarty element comment, ie making the following two equivalent (aside from the former's problems with nesting): {* {somefunc somevar=someval} *} {// somefunc somevar=someval} -- Mark Rogers, More Solutions Ltd :: Tel: 0845 45 89 555 If you can spare a minute, please visit www.votesophie.co.uk