Escape Sequences

[Jonathan Wood]

Yes, there are a couple of workarounds. For my purposes, I mostly just
wanted to make sure I understood what was happening. I think I know now.

Thanks. (And, yes, RegisterClientScriptBlock appears to be the best method
of creating on-the-fly client scripts where possible.)

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

The following code shows the ending </script> tag in a non-string color in
the editor, and the line produces the error "Newline in constant."

string jScript = "<script>document.forms[0].submit();</script>";

Is this a bug? When did "</" become a string escape sequence?

Most strange.

I don't know how the script is being written to the page but my
preference is to use the Page.ClientScript.RegisterClientScriptBlock
method.

regards
A.G.

 

[Liz]

Why would it be a compiler bug? The C# compiler has been passed this:

void Page_Load()
{
if (!Page.IsPostBack)
{
litYear.Text = DateTime.Now.Year.ToString();
string jScript = "<script>document.forms[0].submit();</script>

That piece of code has all the problems which are reported.

no, it was passed:

string jScript = "<script>document.forms[0].submit();</script>";

What makes you say that? That wouldn't explain the errors that were
produced, whereas my (corrected below) version does.

because that was the code the OP posted ... and it does produce the errors
originally reported when in it resides in an .ASPX file

I do have a correction, though: I believe it was actually passed:

void Page_Load()
{
if (!Page.IsPostBack)
{
litYear.Text = DateTime.Now.Year.ToString();
string jScript = "<script>document.forms[0].submit();

In other words, everything before the </script>.

I'm not clear what you mean, Jon ... that you "have a correction" ... what
you think the OP really meant to say? the code above has an unclosed quote
.... ??

That's *just* C# code - the only thing that has to work with it is the
C# compiler. Compare that with the ASP.NET situation: the ASP.NET
engine has to pick out bit of code within <script runat="server"> and
</script> tags, and pass those off to another compiler. It doesn't
understand the contents of the element.

right ... and doesn't really need to; the string assigned to the variable
jScript was intended to run on the client (although the implementation was
never fully spelled out in this thread)

So, without any direct knowledge of the language it's working with, how
should it find out which is a "real" </script> and which is one which
actually just happens to be part of the code?

again, it's not working with a language here; it's only working with a
string of characters comprising some Javascript code

This is always going to be a problem when embedding code from one
language within another - there has to be a way of detecting where the
embedded code ends. It looks like the ASP.NET engine just looks for the
first </script> after the opening tag, and passes everything between
the two to the appropriate language compiler.

which seems to make the ASP.NET engine a little dumber than it might be, no?

Compared with any other mechanism it would have to use to find the end
of the code block, I'm pretty comfortable with the decision that's been
made.

well, I don't know that I'm "uncomfortable" with any of this but I am
puzzled why it has any particular difficulty in simply recognizing a quoted
literal being assigned to a string var and ignoring it for purposes of
identifying the begin/end of the <script></script> block

 

[Jon Skeet [C# MVP]]

no, it was passed:

string jScript = "<script>document.forms[0].submit();</script>";

What makes you say that? That wouldn't explain the errors that were
produced, whereas my (corrected below) version does.

because that was the code the OP posted ... and it does produce the errors
originally reported when in it resides in an .ASPX file

That's what's in the file, certainly - but I don't believe that's
what's being passed from the ASP.NET engine to the C# compiler. There's
a big difference between the two.

I do have a correction, though: I believe it was actually passed:

void Page_Load()
{
if (!Page.IsPostBack)
{
litYear.Text = DateTime.Now.Year.ToString();
string jScript = "<script>document.forms[0].submit();

In other words, everything before the </script>.

I'm not clear what you mean, Jon ... that you "have a correction" ... what
you think the OP really meant to say? the code above has an unclosed quote
... ??

No - I was correcting my previous claim as to what I believe was being
passed to the compiler.

right ... and doesn't really need to; the string assigned to the variable
jScript was intended to run on the client (although the implementation was
never fully spelled out in this thread)

The ASP.NET engine would need to understand C# well enough to know that
"</script>" was part of a string literal, and *wasn't* meant to be the

again, it's not working with a language here; it's only working with a
string of characters comprising some Javascript code

No, it still needs to understand the language.

which seems to make the ASP.NET engine a little dumber than it might be, no?
it should have ignored the first </script> it encountered because it was
between quotation marks

But how is it meant to know what quotation marks mean? That would
involve knowing about the language it's passing to the compiler. In
particular, it would need to know the difference between:

string x = "\"";</script>

and

string x = @""";</script>
other stuff here
"


In the first case </script> is a tag, in the second it's part of a
string, but only due to how verbatim string literals and C# escape
sequences work - in other words, it depends on the language it will be
calling the compiler for.

well, I don't know that I'm "uncomfortable" with any of this but I am
puzzled why it has any particular difficulty in simply recognizing a quoted
literal being assigned to a string var and ignoring it for purposes of
identifying the begin/end of the <script></script> block

Because "quoted literal" depends on the language being used.

 

[Liz]

That's what's in the file, certainly - but I don't believe that's
what's being passed from the ASP.NET engine to the C# compiler. There's
a big difference between the two.

that may well be .. but the discussion here was "why?" ... no?

The ASP.NET engine would need to understand C# well enough to know that
"</script>" was part of a string literal, and *wasn't* meant to be the
closing tag of the <script runat="server">.

yes, of course ... I guess I think it should and you don't think it should?

No, it still needs to understand the language.

ok ... I guess I was thinking it wasn't unreasonable to expect the ASPX
processor to understand C#; it doesn't need to guess at the language;
there's a directive telling it what language is being employed

it seems a little odd to -- in effect -- tell a processor, "ok, all these
<script></script> blocks ... extract those things and hand 'em off to the C#
compiler wholesale" without putting enough smarts into that processor to
effectively figure out where the blocks begin and where they end

Because "quoted literal" depends on the language being used.

and it knows which language is being used ... and we're full circle ...

 

[Jon Skeet [C# MVP]]

that may well be .. but the discussion here was "why?" ... no?

Well, the first question (IMO) is "what" - it's hard to know why
something is behaving in a particular way until you know what that
behaviour is.

yes, of course ... I guess I think it should and you don't think it should?
Exactly.


ok ... I guess I was thinking it wasn't unreasonable to expect the ASPX
processor to understand C#; it doesn't need to guess at the language;
there's a directive telling it what language is being employed

It doesn't need to guess, but it would have to perform a fair amount of
parsing.

it seems a little odd to -- in effect -- tell a processor, "ok, all these
<script></script> blocks ... extract those things and hand 'em off to the C#
compiler wholesale" without putting enough smarts into that processor to
effectively figure out where the blocks begin and where they end

Why? That way the ASP.NET engine doesn't need any knowledge of the
language it's using, which makes life a lot simpler. Simpler generally
means more robust, within restrictions. There's a small restriction
here which allows *much* greater simplicity.

For instance, what should the ASP.NET compiler do with something like:

#if UNDEFINED_PREPROCESSOR_SYMBOL
</script>
#endif

Not only does need to cope with string escaping, it suddenly needs to
understand the preprocessor... then there's comments... and that's just
off the top of my head.

and it knows which language is being used ... and we're full circle ...

It knows which language is being used, but it doesn't currently need to
*understand* the language being used. There's a huge difference between
the two.

I personally think the ASP.NET engine is a lot simpler *without* having
to contain a VB.NET parser and a C# parser, don't you? Considering the
miniscule nature of this restriction, do you really think it's worth
making the ASP.NET engine so much more complicated, for so little gain?

 

[Liz]

Jon,

I personally think the ASP.NET engine is a lot simpler *without* having
to contain a VB.NET parser and a C# parser, don't you? Considering the
miniscule nature of this restriction, do you really think it's worth
making the ASP.NET engine so much more complicated, for so little gain?

well, I don't think I'm in a good position to evaluate how much complexity
would be required to get the ASP.NET engine to some hypothetical optimal
point X and whether the trade-offs are worth it ... but I accept your points
that (a) there is a value calculus that needs to be made, and (b) the code
constraint imposed by the example presented here doesn't amount to anything
significant; I only kick it around because it's a good opportunity to think
about how the (software) machine works and learn a couple of things in the
process

Liz