well, you may decide you dont want that to always be the *ahem* case :) this way around you have the ability to make that call on a case by case basis.
also the commands listed here are a tiny fraction, i have over 30 plugins already defined which can all be used in a very large number of ways because of the bracket type flexibility. | [reply] |
You mentioned people fuss about the use of three types brackets. I don't find anything bad with that. (Many sucessful templating system use customs brackets.) At worse, you'll have to escape parens and square brackets in your template. (We need to do the latter here at PerlMonks.) What I find to be the insurmountable obstacle is the possibility that a line a screen down might be executed before the line I'm looking at.
You only need a few forms of flow control. No matter how many plugins you have, you'll only have a handful of flow control directives. Too many would just lead to confusion, especially in a template system. Your implication that the number of plugins makes this impractical is nonsense.
Perl uses the concept of keywords (if, for, etc) to control the flow. You could do the same (i.e look for special words like "case".) If you want to extend the flow control to the plugins, you might find the approach taken by Paul Lucas in his HTML-Tree templating system (not to be confused with the HTML::Tree parser). The value returned by the plugin controls whether the body of the tag is skipped or not, and whether the tag is repeated or not. This would actually mesh nicely with your existing syntax.
Even Perl with its millions of plugins (modules) doesn't need to alter precedence in the manner you suggest*. Unless you have have a context-specific grammar (which would be bad for a templating system), there's no reason for this.
* — It has BEGIN, but it's rarely needed. A templating system would not need it.
| [reply]
[d/l]
[select] |
re : bracket escaping, my current implementation converts all the brackets in any data file it loads before beginning its processing... thats probably a slow way to do things but my code is improoving over time :)
re : the flow control thing, erm, i only mentioned the number of plugins to illustrate the example of the case statement was just one of many i could of made, many of the plugins could work equally well under any bracket type and thats why i chose to specify processing priority with the brackets rather than as someone said "making case always preceed its contents". I didnt intend to imply anything but that, and tbh most of the tags are nothing to do with flow control.. for instance
(notloggedin)
(refas path="db/users/")users(/refas)
##give access to the users dir through a <users> tag
<trylogin username="<qd>username</qd>" password="<qd>password</qd>">
<success>
You are now logged in!
Welcome <get ref="firstname">
<users><qd>username</qd>.xml</users>
</get>
[session add="username"]<qd>username</qd>[/session]
[insertfile]securepage.xml[/insertfile]
</success>
<fail>
<rem>go back to start and do not collect $200</rem>
[insertfile]login_form.aXML[/insertfile]
</fail>
</trylogin>
(/notloggedin)
(loggedin)
<insertfile>securepage.xml</insertfile>
(/loggedin)
note that within the brackets we could have it do multiple other things especially if we insert different files depending on the result. my current implementation of the insertfile calls for a parser restart, which allows for the file to contain another bunch of () < > and [ ] tag levels.
re : perl millions of modules not needing precedence altering... huh? im not sure im suggesting what it is you think im suggesting.. this schema is just for organising modules in an xml-like format, um... dunno mate.
| [reply]
[d/l]
[select] |