SparkView and JQuery-tmpl

[gs]

SparkView conflicts with JQuery-tmpl as both use the ${} convention,
here's a JQuery-tmpl example:

http://github.com/jquery/jquery-tmpl/blob/master/demo.html

<script id="sometmpl" type="text/html">
<li>${$i}) <a href="${url}">${name}</a> (${cityJoin})</li>
</script>

Anyway around this? Anyway to tell Spark to ignore a block of text? I
suppose I can include it as an external dependency, but that seems
awkward.

Another option would be to go back to the default viewengine, but I
have quite a bit in Sparkview and would rather not go back.

Thanks!

[Louis DeJardin]

Ouch! That's the worst conflict yet!

If you don't to have an addtl round-trip, but don't mind having a second file, you could use <xinclude/> with parse="text"...

http://github.com/jquery/jquery-tmpl/blob/master/demo.html
<script id="sometmpl" type="text/html">

<xinclude href="sometmpl.html" parse="text"/>
</script>

http://github.com/jquery/jquery-tmpl/blob/master/sometmpl.html

<li>${$i}) <a href="${url}">${name}</a> (${cityJoin})</li>

The ximport parse="text" will treat the entire contents of the target file the same as if it was actually present at that location, but it's treated as literal text for output - zero parsing or processing.

Of course that doesn't work if you want to mix server-side code in with the jquery-tmpl stuff. It's not ideal, but to reduce friction you could create a partial to represent the jq ${} characters?

_t.spark
${"${"}<render/>${"}"}

http://github.com/jquery/jquery-tmpl/blob/master/demo.html
<script id="sometmpl" type="text/html">

<li><t>$i</t>) <a href="<t>url</t>"><t>name</t></a> (<t>cityJoin</t>)</li>
</script>

Wow - that's a bad idea! You can't tell the jqt apart from the elements, and the <t>url</t> in the <a href=""> won't be picked up in any case.

This kind of feels like the same class of problem as the css # conflict. I'd agree with the conclusion that "# " is a reasonable default, even if it's a breaking change you have the option of configuring "#" when you upgrade so you're not forced to change all of your views. Would be worth considering making autoencoding default to true at the same time, since it's the same kind of downconfig-when-you-upgrade event.

But! That said! It might be nice if there was a way to mark a region that suppresses or alters the parser's understanding of a syntax...

<script type="text/css" ignore="#">
#header {yarg:3;}
</script>
<script id="sometmpl" type="text/html" ignore="${}">

<li>${$i}) <a href="${url}">${name}</a> (${cityJoin})</li>
</script>

Though the syntax parsing phase itself is too early to do start-end element pairing. If it was possible at all, would need to be a syntax more explicit than an element pair's attribute.

<script type="text/css"><?ignore #?>
#header {yarg:3;}
<?ignore /#?></script>
<script id="sometmpl" type="text/html"><?ignore $?>

<li>${$i}) <a href="${url}">${name}</a> (${cityJoin})</li>

<?ignore /$?></script>

http://github.com/jquery/jquery-tmpl/blob/master/demo.html

Thanks!

--
You received this message because you are subscribed to the Google Groups "Spark View Engine Dev" group.
To post to this group, send email to spar...@googlegroups.com.
To unsubscribe from this group, send email to spark-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/spark-dev?hl=en.

[James Hughes]

Would it not be possible (in future) to have a CDATA style area within a Spark file?  Basically an area that just spits back plain text?  I mean if you are trying to mix serverside stuff with this sort of client stuff you are really asking fro trouble anyway.  It is possible to override/hack the jquery tempalte engine to look for different delimiters which might be an easier option?

 

James 

[Curtis Mitchell]

Yeah, it seems like you should be able to escape the jquery-tmpl delimiters since they're parsed after the spark code has been processed.

Sent from my mobile

---

From: James Hughes <kou...@gmail.com>

Sender: spar...@googlegroups.com

Date: Tue, 22 Jun 2010 20:27:05 +0100

To: <spar...@googlegroups.com>

ReplyTo: spar...@googlegroups.com

Subject: Re: SparkView and JQuery-tmpl

[Louis DeJardin]

@James, yeah, I specifically avoided basing something off the <![CDATA[ syntax, though that was one of the first things that comes to mind… It seemed like htm, aspx, and xml editors each treat them a bit differently, and even the way cdata in treated by ie and ff varies. So that seemed like the water was muddy enough already trying to add another meaning to that would confuse the issue even more.

 

Unless you meant a totally different start and end marker - not CDATA itself but similar meaning - just “treat this bit as literal until you hit the end-code”. That would work fine. Kind of like the effect xinclude parse=”text” has without requiring an additional file.

[Asbjørn Ulsberg]

Wouldn't a reasonable solution here be to do exactly like string
formatting in .NET[1] by just doubling '{}' to work make them work as
their own escape character? E.g.:

<li>(${{$i}}) <a href="${{url}}">${{name}}</a> (${{cityJoin}})</li>

It doesn't look pretty, but what's being accomplished here isn't exactly
elegant either, so I think it's a reasonable tradeoff.

____
[1]
http://stackoverflow.com/questions/91362/how-to-escape-brackets-in-a-format-string-in-net

-Asbjørn

On Tue, 22 Jun 2010 22:30:22 +0200, Louis DeJardin
<lode...@microsoft.com> wrote:

> @James, yeah, I specifically avoided basing something off the <![CDATA[

> syntax, though that was one of the first things that comes to mind... It

> spar...@googlegroups.com<mailto:spar...@googlegroups.com>.

> To unsubscribe from this group, send email to

> spark-dev+...@googlegroups.com<mailto:spark-dev%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/spark-dev?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Spark View Engine Dev" group.
> To post to this group, send email to

> spar...@googlegroups.com<mailto:spar...@googlegroups.com>.

> To unsubscribe from this group, send email to

> spark-dev+...@googlegroups.com<mailto:spark-dev%2Bunsu...@googlegroups.com>.

[Rob G]

@Louis - I agree with @James' suggestion, and by that I mean a "CDATA-like" tag - perhaps we can add a <verbatim> tag to cover this - or has that pesky HTML5 taken that one too? ;-)

If we agree on a tag, then I can add it part of the work I'm doing with the SparkSense plug-in since I'm knee deep in that code anyway - or someone else can do it they prefer. I know James Foster added the <markdown> tag so he has some experience in this area.

If you don't like <verbatim>, then how about <asis> or <handsoff> or even <canttouchthis> :-) Just kidding, but I really do think this is going to be needed more often as jQuery-templ gains traction, and if we want Spark to get a bigger foot hold at the same time. I think it's the least friction for this conflict even though there may be some restrictions for those happy-go-lucky server-client-side-code-mixers out there *tut tut* :-).

Thoughts?

All the best,

RobertTheGrey

[Rob G]

Hey Asbjørn,

This would wreak havoc with the intellisense stuff - I wouldn't know if I was coming or going :) But that's just selfish reasons really - escaping is a very common solution to this kind of problem, but I do think that "harder to read" will damage the uptake of the view engine - especially for new folk who may not understand the reasons right away.

My 2 pennies,

Cheers,

RobertTheGrey

2010/6/22 Asbjørn Ulsberg <asbj...@gmail.com>

[Louis DeJardin]

Maybe something that follows CDATA’s lead for punctuation, just with a different keyword. Since you’re turning off the Spark syntax, maybe that, spelled backwards?

 

<script id="sometmpl" type="text/html"><![KRAPS[

    <li>${$i}) <a href="${url}">${name}</a> (${cityJoin})</li>

]]></script>

 

Nah - the leading < would be invalid…

 

On a more serious note, how about a creative misinterpretation of the existing <xinclude> element with parse=”text” when the href attribute is missing?

 

<script id="sometmpl" type="text/html">

 <xinclude parse=”text”>

    <li>${$i}) <a href="${url}">${name}</a> (${cityJoin})</li>

 </xinclude>

</script>

 

Not the tersest thing in the world, but you could say it has some symmetry with the existing use of xinclude to include another file verbatim.

 

<script id="sometmpl" type="text/html">

  <xinclude href=”xxx” parse=”text”/>

</script>

[Asbjørn Ulsberg]

True.

How about introducing a new tag (<verbatim>) as you propose, but in
circumstances like this (and others) allow an XML namespace+prefix to be
easily added to all Spark elements? They should reside in a default
namespace nonetheless, imho.

-Asbjørn

>>> spark-dev+...@googlegroups.com<spark-dev%2Bunsu...@googlegroups.com>
>>> <mailto:spark-dev%2Bunsu...@googlegroups.com<spark-dev%252Buns...@googlegroups.com>

>>> >.
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/group/spark-dev?hl=en.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "Spark View Engine Dev" group.
>>> To post to this group, send email to spar...@googlegroups.com<mailto:
>>> spar...@googlegroups.com>.
>>> To unsubscribe from this group, send email to

>>> spark-dev+...@googlegroups.com<spark-dev%2Bunsu...@googlegroups.com>
>>> <mailto:spark-dev%2Bunsu...@googlegroups.com<spark-dev%252Buns...@googlegroups.com>

>>> >.
>>>
>>> For more options, visit this group at
>>> http://groups.google.com/group/spark-dev?hl=en.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "Spark View Engine Dev" group.
>>> To post to this group, send email to spar...@googlegroups.com.
>>> To unsubscribe from this group, send email to

>>> spark-dev+...@googlegroups.com<spark-dev%2Bunsu...@googlegroups.com>

>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/spark-dev?hl=en.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "Spark View Engine Dev" group.
>>> To post to this group, send email to spar...@googlegroups.com.
>>> To unsubscribe from this group, send email to

>>> spark-dev+...@googlegroups.com<spark-dev%2Bunsu...@googlegroups.com>

>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/spark-dev?hl=en.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups
>> "Spark View Engine Dev" group.
>> To post to this group, send email to spar...@googlegroups.com.
>> To unsubscribe from this group, send email to

>> spark-dev+...@googlegroups.com<spark-dev%2Bunsu...@googlegroups.com>

[Asbjørn Ulsberg]

How about just adding a <text> element? Overloading <xinclude> doesn't
give us anything <text> doesn't, does it?

-Asbjørn

On Wed, 23 Jun 2010 04:00:31 +0200, Louis DeJardin
<lode...@microsoft.com> wrote:

> Maybe something that follows CDATA's lead for punctuation, just with a
> different keyword. Since you're turning off the Spark syntax, maybe
> that, spelled backwards?
>
> <script id="sometmpl" type="text/html"><![KRAPS[
> <li>${$i}) <a href="${url}">${name}</a> (${cityJoin})</li>
> ]]></script>
>

> Nah - the leading < would be invalid...

> syntax, though that was one of the first things that comes to mind... It

> seemed like htm, aspx, and xml editors each treat them a bit
> differently, and even the way cdata in treated by ie and ff varies. So
> that seemed like the water was muddy enough already trying to add
> another meaning to that would confuse the issue even more.
>
> Unless you meant a totally different start and end marker - not CDATA
> itself but similar meaning - just "treat this bit as literal until you
> hit the end-code". That would work fine. Kind of like the effect
> xinclude parse="text" has without requiring an additional file.
>
>
>
> From: spar...@googlegroups.com<mailto:spar...@googlegroups.com>
> [mailto:spar...@googlegroups.com<mailto:spar...@googlegroups.com>]
> On Behalf Of Curtis Mitchell
> Sent: Tuesday, June 22, 2010 12:30 PM
>

> To: spar...@googlegroups.com<mailto:spar...@googlegroups.com>

> Subject: Re: SparkView and JQuery-tmpl
>
> Yeah, it seems like you should be able to escape the jquery-tmpl
> delimiters since they're parsed after the spark code has been processed.
>
> Sent from my mobile
>
> ________________________________

> From: James Hughes <kou...@gmail.com<mailto:kou...@gmail.com>>
> Sender: spar...@googlegroups.com<mailto:spar...@googlegroups.com>

> Date: Tue, 22 Jun 2010 20:27:05 +0100

> To: <spar...@googlegroups.com<mailto:spar...@googlegroups.com>>
> ReplyTo: spar...@googlegroups.com<mailto:spar...@googlegroups.com>

> spar...@googlegroups.com<mailto:spar...@googlegroups.com>.

> To unsubscribe from this group, send email to

> spark-dev+...@googlegroups.com<mailto:spark-dev%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/spark-dev?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Spark View Engine Dev" group.
> To post to this group, send email to

> spar...@googlegroups.com<mailto:spar...@googlegroups.com>.

> To unsubscribe from this group, send email to

> spark-dev+...@googlegroups.com<mailto:spark-dev%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/spark-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Spark View Engine Dev" group.
> To post to this group, send email to

> spar...@googlegroups.com<mailto:spar...@googlegroups.com>.

> To unsubscribe from this group, send email to

> spark-dev+...@googlegroups.com<mailto:spark-dev%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/spark-dev?hl=en.
> --
> You received this message because you are subscribed to the Google
> Groups "Spark View Engine Dev" group.
> To post to this group, send email to

> spar...@googlegroups.com<mailto:spar...@googlegroups.com>.

> To unsubscribe from this group, send email to

> spark-dev+...@googlegroups.com<mailto:spark-dev%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/spark-dev?hl=en.
> --
> You received this message because you are subscribed to the Google
> Groups "Spark View Engine Dev" group.
> To post to this group, send email to

> spar...@googlegroups.com<mailto:spar...@googlegroups.com>.

> To unsubscribe from this group, send email to

> spark-dev+...@googlegroups.com<mailto:spark-dev%2Bunsu...@googlegroups.com>.

[Rob G]

Hehe, KRAPS - I like it :-)

I'm happy with the missing "href" implying that text between the tags gets parsed verbatim. With one caveat though, it's not as intuitive as having its own tag and from a discoverability perspective, it'll come across as a hidden gem - one that might be missed more often than not, which could lead to higher support costs and/or frustration on the users' part.

Thoughts anyone?

[Rob G]

I was thinking of <text> but seems like it's far too likely to result in another conflict somewhere down the line. Also, the name doesn't express its true intent as clearly.

2010/6/23 Asbjørn Ulsberg <asbj...@gmail.com>

[Louis DeJardin]

<text> sounds pretty good, something like <code>…</code> might be a nice additional alias for multiline code block <% … %>, though that clearly has a conflict.

 

Maybe not use the element, but follow along the leading x of the <xinclude/> element name, with <xtext> and <xcode>? You could say they’re a related set of elements because they share some degree of pre-processing or parse-time effect?

 

<xtext>

#header {foo:bar;}

</xtext>

 

<xcode>

func<string,string> etc = …;

foreach(var x in y) {

  Output.Write(etc(x));

}

</xcode>

[Rob G]

OK - I may need some clarification here as I could be missing something subtle: when you talk about <xinclude>, I understand that to be a reference to the W3 XInclude specification, but the *actual* tag syntax used in the Spark file is <include> or <foo:include> if you use a namespace. My current understanding is that by actually typing <xinclude> would not parse in Spark - but I could be wrong...

With that said above, when you say <xcode> or <xtext>, do you mean that exactly? In that case I don't see conflicts arising, but it is still a little inconsistent although I'm happy that it's terse.

[Matt Ellis]

How about just escaping the $ in the ${}? Something like $${}? So every time you use ${whatever} it's a spark command, but if you use $${whatever} it would get rendered as a single ${whatever}. 

This could also be extended to provide escaping for the non-encoded version !!{whatever}

In fact, a similar trick could be used for # and CSS. # is a spark command, ## gets rendered as a single #

Matt

[Asbjørn Ulsberg]

Very clever -- I like it! :)

-Asbjørn

[Rob G]

Sweet! This will also be fairly easy to provide intellisense support for :)

[Asbjørn Ulsberg]

Instead of hackishly prefixing all elements with a random character, I'm
definitively more in favor of using a proper XML namespace with a proper
XML prefix. As an XML infoset, all elements that belongs to Spark should
(implicitly) exist within a Spark-specific namespace.

A default namespace prefix of 'spark' could be registered as well so
whenever you find yourself in conflict with an element belong to another
language, you can just add the prefix to the Spark element;

<spark:include ... />

-Asbjørn

On Wed, 23 Jun 2010 11:00:15 +0200, Louis DeJardin
<lode...@microsoft.com> wrote:

> <text> sounds pretty good, something like <code>...</code> might be a
> nice additional alias for multiline code block <% ... %>, though that

> clearly has a conflict.
>
> Maybe not use the element, but follow along the leading x of the
> <xinclude/> element name, with <xtext> and <xcode>? You could say
> they're a related set of elements because they share some degree of
> pre-processing or parse-time effect?
>
> <xtext>
> #header {foo:bar;}
> </xtext>
>
> <xcode>

> func<string,string> etc = ...;

> foreach(var x in y) {
> Output.Write(etc(x));
> }
> </xcode>
>
>
>
> From: spar...@googlegroups.com [mailto:spar...@googlegroups.com] On
> Behalf Of Rob G
> Sent: Wednesday, June 23, 2010 12:45 AM
> To: spar...@googlegroups.com
> Subject: Re: SparkView and JQuery-tmpl
>
> I was thinking of <text> but seems like it's far too likely to result in
> another conflict somewhere down the line. Also, the name doesn't express
> its true intent as clearly.

> 2010/6/23 Asbjørn Ulsberg <asbj...@gmail.com<mailto:asbj...@gmail.com>>

> @Louis - I agree with @James' suggestion, and by that I mean a
> "CDATA-like" tag - perhaps we can add a <verbatim> tag to cover this -
> or has that pesky HTML5 taken that one too? ;-)
>
> If we agree on a tag, then I can add it part of the work I'm doing with
> the SparkSense plug-in since I'm knee deep in that code anyway - or
> someone else can do it they prefer. I know James Foster added the
> <markdown> tag so he has some experience in this area.
>
> If you don't like <verbatim>, then how about <asis> or <handsoff> or
> even <canttouchthis> :-) Just kidding, but I really do think this is
> going to be needed more often as jQuery-templ gains traction, and if we
> want Spark to get a bigger foot hold at the same time. I think it's the
> least friction for this conflict even though there may be some
> restrictions for those happy-go-lucky server-client-side-code-mixers out
> there *tut tut* :-).
>
> Thoughts?
>
> All the best,
> RobertTheGrey
> On Tue, Jun 22, 2010 at 9:30 PM, Louis DeJardin

> <lode...@microsoft.com<mailto:lode...@microsoft.com><mailto:lode...@microsoft.com<mailto:lode...@microsoft.com>>>

> wrote:
> @James, yeah, I specifically avoided basing something off the <![CDATA[
> syntax, though that was one of the first things that comes to mind... It
> seemed like htm, aspx, and xml editors each treat them a bit
> differently, and even the way cdata in treated by ie and ff varies. So
> that seemed like the water was muddy enough already trying to add
> another meaning to that would confuse the issue even more.
>
> Unless you meant a totally different start and end marker - not CDATA
> itself but similar meaning - just "treat this bit as literal until you
> hit the end-code". That would work fine. Kind of like the effect
> xinclude parse="text" has without requiring an additional file.
>
>
> From:
> spar...@googlegroups.com<mailto:spar...@googlegroups.com><mailto:spar...@googlegroups.com<mailto:spar...@googlegroups.com>>
> [mailto:spar...@googlegroups.com<mailto:spar...@googlegroups.com><mailto:spar...@googlegroups.com<mailto:spar...@googlegroups.com>>]
> On Behalf Of Curtis Mitchell
>
> Sent: Tuesday, June 22, 2010 12:30 PM
> To:

> spar...@googlegroups.com<mailto:spar...@googlegroups.com><mailto:spar...@googlegroups.com<mailto:spar...@googlegroups.com>>

>
> Subject: Re: SparkView and JQuery-tmpl
>
> Yeah, it seems like you should be able to escape the jquery-tmpl
> delimiters since they're parsed after the spark code has been processed.
>
> Sent from my mobile
>
> ________________________________
> From: James Hughes

> <kou...@gmail.com<mailto:kou...@gmail.com><mailto:kou...@gmail.com<mailto:kou...@gmail.com>>>
> Sender:
> spar...@googlegroups.com<mailto:spar...@googlegroups.com><mailto:spar...@googlegroups.com<mailto:spar...@googlegroups.com>>

>
> Date: Tue, 22 Jun 2010 20:27:05 +0100
> To:

> <spar...@googlegroups.com<mailto:spar...@googlegroups.com><mailto:spar...@googlegroups.com<mailto:spar...@googlegroups.com>>>
> ReplyTo:
> spar...@googlegroups.com<mailto:spar...@googlegroups.com><mailto:spar...@googlegroups.com<mailto:spar...@googlegroups.com>>

>
> Subject: Re: SparkView and JQuery-tmpl
>
> Would it not be possible (in future) to have a CDATA style area within a
> Spark file? Basically an area that just spits back plain text? I mean
> if you are trying to mix serverside stuff with this sort of client stuff
> you are really asking fro trouble anyway. It is possible to
> override/hack the jquery tempalte engine to look for different
> delimiters which might be an easier option?
>
> James
> On Tue, Jun 22, 2010 at 8:20 PM, Louis DeJardin

> <lode...@microsoft.com<mailto:lode...@microsoft.com><mailto:lode...@microsoft.com<mailto:lode...@microsoft.com>>>

> spar...@googlegroups.com<mailto:spar...@googlegroups.com><mailto:spar...@googlegroups.com<mailto:spar...@googlegroups.com>>.

> To unsubscribe from this group, send email to

> spark-dev+...@googlegroups.com<mailto:spark-dev%2Bunsu...@googlegroups.com><mailto:spark-dev%2Bunsu...@googlegroups.com<mailto:spark-dev%252Buns...@googlegroups.com>>.

>
> For more options, visit this group at
> http://groups.google.com/group/spark-dev?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Spark View Engine Dev" group.
> To post to this group, send email to

> spar...@googlegroups.com<mailto:spar...@googlegroups.com><mailto:spar...@googlegroups.com<mailto:spar...@googlegroups.com>>.

> To unsubscribe from this group, send email to

> spark-dev+...@googlegroups.com<mailto:spark-dev%2Bunsu...@googlegroups.com><mailto:spark-dev%2Bunsu...@googlegroups.com<mailto:spark-dev%252Buns...@googlegroups.com>>.

>
> For more options, visit this group at
> http://groups.google.com/group/spark-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Spark View Engine Dev" group.
> To post to this group, send email to

> spar...@googlegroups.com<mailto:spar...@googlegroups.com><mailto:spar...@googlegroups.com<mailto:spar...@googlegroups.com>>.

> To unsubscribe from this group, send email to

> spark-dev+...@googlegroups.com<mailto:spark-dev%2Bunsu...@googlegroups.com><mailto:spark-dev%2Bunsu...@googlegroups.com<mailto:spark-dev%252Buns...@googlegroups.com>>.

>
> For more options, visit this group at
> http://groups.google.com/group/spark-dev?hl=en.
> --
> You received this message because you are subscribed to the Google
> Groups "Spark View Engine Dev" group.
> To post to this group, send email to

> spar...@googlegroups.com<mailto:spar...@googlegroups.com><mailto:spar...@googlegroups.com<mailto:spar...@googlegroups.com>>.

> To unsubscribe from this group, send email to

> spark-dev+...@googlegroups.com<mailto:spark-dev%2Bunsu...@googlegroups.com><mailto:spark-dev%2Bunsu...@googlegroups.com<mailto:spark-dev%252Buns...@googlegroups.com>>.

>
> For more options, visit this group at
> http://groups.google.com/group/spark-dev?hl=en.
> --
> You received this message because you are subscribed to the Google
> Groups "Spark View Engine Dev" group.
> To post to this group, send email to

> spar...@googlegroups.com<mailto:spar...@googlegroups.com><mailto:spar...@googlegroups.com<mailto:spar...@googlegroups.com>>.

> To unsubscribe from this group, send email to

> spark-dev+...@googlegroups.com<mailto:spark-dev%2Bunsu...@googlegroups.com><mailto:spark-dev%2Bunsu...@googlegroups.com<mailto:spark-dev%252Buns...@googlegroups.com>>.

[John Gietzen]

I am not sure that this is a Good Idea for the '#' symbol, since the CSS issue is already easily remedied by setting the default to '# '.

[Matthew Ellis]

I'd suggest both, to be honest. I think '# ' is a rather nifty fix, if a little context specific and somewhat unintuitive. But it's handy, and if it's already been implemented, then it can't be removed. And there's a nice symmetry in all character sequences that are special to spark being escaped in the same way, by simply doubling the first char.

[Louis DeJardin]

==== reply out-of-band to observation that <xinclude> is actually <include>

 

Ah!! That’s exactly right. I confused the name of the spec with the name of the element, which is <include>, and doesn’t require a namespace by default.

 

So there’s no “x” pattern at all - but a multi-line armored code and text element of some name might be nice to have. However if syntax escaping works you could say, as a feature, that’s orthogonal to the problem this thread is about.

 

 

==== reply to thread

 

Yeah - only conflict with ## is for putting cs #pragma in .spark files - but that can always be done with a space like “# #pragma” to no problem there.

 

$${x} to output literal text “${x}” - not html encoded of course

!!{x} to output literal text “!{x}” - same

## to output literal text “#”

 

Hmmm… In the parser for those things there are some non-trivial rules that understand the structure of the text inside ${x} - for example it needs to match internal { and } pairs in order to close on the correct ending }.

 

So, that said, you can get the same effect with:

 

$${ to output literal text “${”

!!{ to output literal text “!{”

## to output literal text “#”

 

Would it also make sense to have

<!!-- to output literal text “<!--”

 

<!!-- html comment with code evaluation intact, like ${DateTime.UtcNow} -->

 

Otherwise you need to use the escape as string trick, like

!{“<!--“} html comment with code evaluation intact, like ${DateTime.UtcNow} -->

[Matthew Ellis]

So what you're suggesting is that instead of changing the parser to recognise this:

${{...blah...${Model.Count}...blah...}

as a complete element, with content "...blah...${Model.Count}...blah..." that then needed further parsing in order to render:

${...blah...10...blah...}

Instead, Spark would just recognise ${{ as a token and simply render ${ as a literal and then continue to parse and render the rest of the input. So, would a lone, unmatched closing brace ("}") cause an issue for the parser, or would it simply render it?

And I'm not sure what you're suggesting with <!-- and <!!--. I love the idea of extending this to include the html comment. But I also remember being very surprised when <!-- ... --> rendered the content verbatim - I was expecting it to be parsed and handled correctly.

It feels slightly counter-intuitive that a html comment would be treated as a Spark comment, with the content rendered verbatim, and if I want to have stuff evaluated within my html comment, I need to use a special <!!-- syntax. It feels the wrong way round. All other html elements have their content rendered by Spark, apart from the comment, and we're suggesting this doubling syntax for content to be rendered verbatim. However, suddenly starting to render <!-- as normal Spark content would be a breaking change. Not sure what's best here.

(In fact, server-side comments are a bit awkward in Spark - I need to drop into a C# code block and use C# comments to add a server-side comment...)

Matt

[tylerl]

Hm. I't simple, but I think it's problematic.

Say for example I want to output the string "$43.21", if I say "$$
{price}" then instead it will output a literal "${price}", which isn't
at all what I wanted; and the failure is non-intuitive, so you'll get
a rash of posts to the list from dozens of people who can't get their
shopping carts to work anymore. The only way to make the price display
correctly would be "${ "$" + price.ToString() }", which--let's face
it--is a disaster.

Furthermore, I don't know of any clear way to output the string
"$42.21" with that change in place.

Instead, it would be preferable to have a simple "literal escape"
sequence which simply outputs a string literal. For example, using
@{ } as the "literal" sequence:

@{XYZ} would output "XYZ"
@{${var}} would output ${var} -- though not for the reason you think.
@{ ${var1} ${var2} } would render "${var1} XXX }" where "XXX" is the
contents of var2, since the first "}" would terminate the literal-
output sequence.

If, instead, we match on "{# ... #}" or something like that (i.e.
multi-character markers), then we dramatically lower this collision
rate. It's important that the end marker of the "literal escape"
sequence not be confused anything it would likely be escaping. So for
example: "{# ${var1} ${var2} #}" would be easy for the parser to
interpret, and would clearly output "${var1} ${var2}".

-Tyler

[Asbjørn Ulsberg]

I quite like {#...#}. I can't come up with any use cases that will break
it. :)

It would be nice if {#...#} could (whenever introducing a breaking change
is possible) replace <!-- --> as the default Spark comment mechanism as
well.

-Asbjørn

[mogadanez]

>Of course that doesn't work if you want to mix server-side code in with the jquery-tmpl stuff. It's not ideal, but to >reduce friction you could create a partial to represent the jq ${} characters?
>_t.spark
>${"${"}<render/>${"}"}

why need such big partial?
I can only render $ in it -

_t.spark:
${"$"}

<script id="sometmpl" type="text/html">

<li><t/>{$i}) <a href="<t/>{url}"><t/>{name}</a> (<t/
>{cityJoin})</li>
</script>

[Igor Loginov (aka ilog2000)]

I might be wrong, but $$ escaping brings the problem how to get
literal end. No?

For me the minimalistic way is to have only one escape sequence ##
which means "Don't process ${} in this line"...