Sure there is.
This is handled by the Objective-C MiscMergeKit template engine by
having all variables and directives enclosed in a starting and ending
tag.
Ie, #if (x)# text #else# text #endif#
or ${if (x)} text ${else} text ${endif}
The actual starting and ending tags can at any point be changed using a
#delimiters new-left-delimiter new-closing-delimiter # directive.
Ie,
## write html template info
#delimiters {$ $} #
write shell script template info
{$delimiters # # $}
write more html template info
I haven't found it all that useful to switch delimiters in the middle of a
template, but I definitely have found it useful to switch delimiters
at the start of a file.
On 10/8/05, Jason Pettiss <[EMAIL PROTECTED]> wrote:
> It's an interesting question... I guess it's a tradeoff between syntax
> stability and error robustness. The former favors smart users who are
> used to dealing with the absolutes imposed by programming languages, the
> latter, artsy-fartsy types who honestly have trouble terminating html
> elements properly.
>
> JSP for example has absolute delimiters which are glaring (and ugly).
> You get one of those wrong, your whole page breaks fantastically, and
> without a nice error system or checking the logs, you won't know where
> the problem is. Taglibs just make things worse because in a page that's
> designed to generate HTML they hide really well... and still even one
> mistake and BOOM! Developers dislike it, artists fear it...
>
> Velocity needs just a single character most of the time, and it's very
> tolerant of mistakes. Most of the time it'll spit out a full page and
> the non-technical user can see exactly where they screwed up, and why.
> This makes it very friendly for the user, and intuitive for most
> purposes, but at the expense of having an absolute way to escape and
> delimit... which means sometimes the mechanism breaks down. Typically
> this is just a minor annoyance to a non-technical user, who most of the
> time doesn't grasp the difference between dynamic and static content
> anyway-- and so is using trial and error, and will do so here, to get
> over the little stumbling blocks imposed by a very liberal syntax.
>
> Due to the lack of reliable escaping, Velocity would break down entirely
> if the page being generated were, say... oh I dunno... another Velocity
> template! Fortunately this is highly uncommon and I don't think it's
> the intention of the language. Velocity also isn't well suited for
> strict content where whitespace and newlines really matter-- like
> certain WML-- but then again, JSP is pretty terrible at this too. As a
> general purpose template language in a world awash with XML and HTML
> lookalikes, Velocity does well. If the web were composed of shell
> scripts I am sure it wouldn't be as well accepted.
>
> I do think there's got to be a way to get the flexibility and liberal
> syntax in the 90% scenario, yet have a way to reliably escape, delimit,
> control whitespace conventions, etc, in the "other" cases. Also-- the
> template language I want also lets me choose the syntax markers and
> define them in the content. Then all I have to do is choose delimiters
> which don't appear that often in the page, and I'm always basking in the
> sunny 90% scenario... ;-)
>
> About the macro-with-body... that's really just two macros on either
> side of some content, isn't it? Its nice to not have to remember to
> "close", but you have to do that with for loops and if statements and
> comments anyway, right?
>
> --jason
>
> Daniel Dekany wrote:
>
> >Friday, October 7, 2005, 11:12:21 PM, Chad Meadows wrote:
> >
> >
> >
> >>I simply don't quite understand what seems to be a pushback to
> >>acknowledging there is a community of people who do not like the syntax. I
> >>have shown the syntax of velocity side by side with freemarker among those
> >>who had never seen either. Velocity was preferred.
> >>
> >>
> >[snip]
> >
> >DISCLAIMER: This will NOT be a FreeMarker advertisement. Also, I do NOT
> >like the FreeMarker syntax (but not because of it usage of cryptic
> >delimiters... there other things historically bungled in it), although I
> >surely prefer it over Velocity's.
> >
> ><meta-discussion>
> >The unimportant thing what I want to say is that Jonathan behaves
> >roughly in this case because he becomes angry when he faces exactly the
> >same case of, well, apparent lack of professional experience (read:
> >***IGNORANCE!!!***, just I don't wanted to say that :)) again and again
> >and again... the syntax stuff. (Plus, he is pissed of on Jakarta people
> >in general, so it's not the place where he will try to keep cool his
> >blood when it wants to boil.)
> ></meta-discussion>
> >
> >
> >So, what "apparent lack of professional experience" do I refer to?
> >
> >One thing is that evaluating a template language primarily based on the
> >first impression "look and feel" goodness of its syntax is, well... Even
> >evaluation a template engine primarily based on it syntax is, well...
> >(as far as the syntax is within the borders of sanity, that is). But let
> >this alone now too.
> >
> >The other thing is, that unfortunately a syntax that look simple,
> >especially one that look good for non-programmer person at the first
> >glance, always have the dark sides, that are not apparent first. But
> >later... later you will swallow them because you are already get used to
> >the basic syntax... but the point is, it turns out that the syntax is
> >not that good after all. Like, I agree that WebMacro-style syntax (like
> >Velocity's) looks friendly at the fist glance, but unfortunately it
> >turns out that this type of syntaxes has some problems, which eventually
> >fade out the advantage of first-impression natural look (I will not deal
> >with strictly VTL specific design mistakes and bugs, since those has
> >trivial fixes):
> >
> >- To show it in VTL: #else#**#blah#end. I bet most non-programmer will
> > not figure out easily that they should use that #**#, and anyway it's
> > awkward. But it could be solved as #{else}blah. Still, then the syntax
> > has already lost from its minimalism. Because, there are two ways of
> > writing the same thing, and then wouldn't be simpler if there is only
> > one way, the way that's always safely works? Anyway, especially for
> > non-programmers, the delimiting issue is something more mystical than
> > for a programmer: "Hm.... I don't want space here... will #elseblah be
> > OK? (try) Sh*t... now what to do? (phone)" (Of course, it's the kind
> > of thing that the guy will not foresee when he falls in love with Vel.
> > at the first glance.) But, if you want, let's say it's a minor issue.
> >
> >- The $foo VS ${foo} thing. The same as with #else basically.
> > Complicates things... why not just one *safe* way (it's clean for
> > everybody where's the end of the expression), which is ${foo}. Instead
> > of two ways? Much simpler, the documentation will be sorter... Yes,
> > more typing, but I think it worth it in the case of template language.
> > But, again if you want, let's say it's a minor issue.
> >
> >- BTW as a side note, with $foo you can really use "complex"
> > expressions, like ${x + 1}. With ${...} it naturally works.
> >
> >- Again $foo VS ${foo}. You have high chance that something that meant to
> > be static text will be interpreted as a reference. Like $Id: ...$
> > Not a that minor issue... And yet another catch to remember.
> >
> >- And the most important for the last... how do you call a macro with
> > body (like <my:stuff>...</my:stuff> in JSP) with this syntax? I know,
> > Vel. doesn't support it anyway, except for some built-in directives,
> > but many template language will definitely want to (like JSP,
> > FreeMarker, Viento), for good reason IMO. Now I don't go into the
> > endless variations of solutions that I tried "on paper" and then
> > thrown away, because they had too many catches, or was too verbose, or
> > look far too alien. Can anybody show me a good solution with more-less
> > WebMacro (Velocity) style? (And don't forget to count with the text
> > editors, for which a syntax highlight should be possible.)
> >
> >I have rumbled a lot about template syntaxes in the past. I really tried
> >to find out syntaxes that have a WebMacro (or Velocity) look-and-feel,
> >or just otherwise natural look if you see what I mean. (Note that not
> >supporting macros with body is not acceptable for me.) For my biggest
> >regret, I have found that at the end of the day, the simplest and most
> >reliable syntaxes, the best compromises, were are always those where
> >there are strictly required delimiters at the left and right side of the
> >directives, like <#...>, or [#...], or even <%...%>, also ${...}, or
> >#{...}, etc, i.e. not the WebMacro look-and-feel stuff at all.
> >Furthermore at least the left side delimiter should be something that
> >doesn't clash with anything that can easily occur in the static text, so
> >just [...] is not enough, you need some additional strange character
> >after the "[" (and even before the "]" if you want really text-editor
> >friendly language). Yes, these syntaxes look alien at the first glance,
> >but I believe that after that initial emotional shock (%-/ "Whaaaat?"),
> >you will be better with them. They free of ambiguities (no cookbook
> >tricks needed), they are safer (less chance of accidental clashes),
> >while their rules can still remain damn simple. And, that they are
> >necessary more verbose than WebMacro style syntaxes is a myth... they
> >are just little bit more verbose, no important difference in that.
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
