First, let me say that Spark looks very cool. Very nice work.
There's been a bunch of discussion in the blogosphere lately about XSS
and encoding output, with the the general consensus being "always HTML
encode your output". Yet no view engines seem to do this. Have you
considered making Spark encode output by default (with a way to
escape, of course)? Or at least giving an expression syntax that
encodes by default (e.g #{expr}, ^{expr}, or whatever).
I know about ${H(expr)}, but that still requires that I remember to
include the call to H. I want the brain-dead, always-do-it, I-don't-
have-to-think-about-it option. I'm more than willing to submit a patch
if that would be helpful.
You're right it'd be impossible to add that directly to ${expr} without
making it impossible to send ${Html.ActionLink(...)}. I'd hesitate to change
the default behavior of ${expr} because it would be a breaking change. We
already had ?{cond} added when there was a compelling reason, so I could see
this if there was a consensus.
The #{expr} could collide with #statement if it was on the start of a line,
so I don't think that'll fly.
If anything I think I'd lean towards <p>Product +{product.Name}</p>... It
looks a little bit like you meant to add/append the value to the literal
html, so implicit encoding would make sense, but even more importantly the
[shift] "+{" sequence looks to be keyboard friendly.
On Tue, Dec 16, 2008 at 2:51 PM, Kevin Dente <kevinde...@gmail.com> wrote:
> First, let me say that Spark looks very cool. Very nice work.
> There's been a bunch of discussion in the blogosphere lately about XSS
> and encoding output, with the the general consensus being "always HTML
> encode your output". Yet no view engines seem to do this. Have you
> considered making Spark encode output by default (with a way to
> escape, of course)? Or at least giving an expression syntax that
> encodes by default (e.g #{expr}, ^{expr}, or whatever).
> I know about ${H(expr)}, but that still requires that I remember to
> include the call to H. I want the brain-dead, always-do-it, I-don't-
> have-to-think-about-it option. I'm more than willing to submit a patch
> if that would be helpful.
Hmm, I'm kind of partial to ^{product.Name} myself, for some reason.
But I'm cool either way. You're right that +{} is flows pretty well on
the keyboard.
On Dec 16, 1:14 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> You're right it'd be impossible to add that directly to ${expr} without
> making it impossible to send ${Html.ActionLink(...)}. I'd hesitate to change
> the default behavior of ${expr} because it would be a breaking change. We
> already had ?{cond} added when there was a compelling reason, so I could see
> this if there was a consensus.
> The #{expr} could collide with #statement if it was on the start of a line,
> so I don't think that'll fly.
> Ah, I think & is out... Collides with &entity;...
> If anything I think I'd lean towards <p>Product +{product.Name}</p>... It
> looks a little bit like you meant to add/append the value to the literal
> html, so implicit encoding would make sense, but even more importantly the
> [shift] "+{" sequence looks to be keyboard friendly.
> On Tue, Dec 16, 2008 at 2:51 PM, Kevin Dente <kevinde...@gmail.com> wrote:
> > First, let me say that Spark looks very cool. Very nice work.
> > There's been a bunch of discussion in the blogosphere lately about XSS
> > and encoding output, with the the general consensus being "always HTML
> > encode your output". Yet no view engines seem to do this. Have you
> > considered making Spark encode output by default (with a way to
> > escape, of course)? Or at least giving an expression syntax that
> > encodes by default (e.g #{expr}, ^{expr}, or whatever).
> > I know about ${H(expr)}, but that still requires that I remember to
> > include the call to H. I want the brain-dead, always-do-it, I-don't-
> > have-to-think-about-it option. I'm more than willing to submit a patch
> > if that would be helpful.
On Tue, Dec 16, 2008 at 10:21 PM, Kevin Dente <kevinde...@gmail.com> wrote:
> Hmm, I'm kind of partial to ^{product.Name} myself, for some reason.
> But I'm cool either way. You're right that +{} is flows pretty well on
> the keyboard.
> On Dec 16, 1:14 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> > You're right it'd be impossible to add that directly to ${expr} without
> > making it impossible to send ${Html.ActionLink(...)}. I'd hesitate to
> change
> > the default behavior of ${expr} because it would be a breaking change. We
> > already had ?{cond} added when there was a compelling reason, so I could
> see
> > this if there was a consensus.
> > The #{expr} could collide with #statement if it was on the start of a
> line,
> > so I don't think that'll fly.
> > Ah, I think & is out... Collides with &entity;...
> > If anything I think I'd lean towards <p>Product +{product.Name}</p>... It
> > looks a little bit like you meant to add/append the value to the literal
> > html, so implicit encoding would make sense, but even more importantly
> the
> > [shift] "+{" sequence looks to be keyboard friendly.
> > On Tue, Dec 16, 2008 at 2:51 PM, Kevin Dente <kevinde...@gmail.com>
> wrote:
> > > First, let me say that Spark looks very cool. Very nice work.
> > > There's been a bunch of discussion in the blogosphere lately about XSS
> > > and encoding output, with the the general consensus being "always HTML
> > > encode your output". Yet no view engines seem to do this. Have you
> > > considered making Spark encode output by default (with a way to
> > > escape, of course)? Or at least giving an expression syntax that
> > > encodes by default (e.g #{expr}, ^{expr}, or whatever).
> > > I know about ${H(expr)}, but that still requires that I remember to
> > > include the call to H. I want the brain-dead, always-do-it, I-don't-
> > > have-to-think-about-it option. I'm more than willing to submit a patch
> > > if that would be helpful.
On Wed, Dec 17, 2008 at 5:24 AM, Chad Lee <chadl...@gmail.com> wrote:
> What's wrong with the current way?
> ${H(myVar)}
> I don't see much value in adding a shortcut to this already short method
> call.
> On Tue, Dec 16, 2008 at 10:21 PM, Kevin Dente <kevinde...@gmail.com> wrote:
>> Hmm, I'm kind of partial to ^{product.Name} myself, for some reason.
>> But I'm cool either way. You're right that +{} is flows pretty well on
>> the keyboard.
>> On Dec 16, 1:14 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
>> > You're right it'd be impossible to add that directly to ${expr} without
>> > making it impossible to send ${Html.ActionLink(...)}. I'd hesitate to
>> > change
>> > the default behavior of ${expr} because it would be a breaking change.
>> > We
>> > already had ?{cond} added when there was a compelling reason, so I could
>> > see
>> > this if there was a consensus.
>> > The #{expr} could collide with #statement if it was on the start of a
>> > line,
>> > so I don't think that'll fly.
>> > Ah, I think & is out... Collides with &entity;...
>> > If anything I think I'd lean towards <p>Product +{product.Name}</p>...
>> > It
>> > looks a little bit like you meant to add/append the value to the literal
>> > html, so implicit encoding would make sense, but even more importantly
>> > the
>> > [shift] "+{" sequence looks to be keyboard friendly.
>> > On Tue, Dec 16, 2008 at 2:51 PM, Kevin Dente <kevinde...@gmail.com>
>> > wrote:
>> > > First, let me say that Spark looks very cool. Very nice work.
>> > > There's been a bunch of discussion in the blogosphere lately about XSS
>> > > and encoding output, with the the general consensus being "always HTML
>> > > encode your output". Yet no view engines seem to do this. Have you
>> > > considered making Spark encode output by default (with a way to
>> > > escape, of course)? Or at least giving an expression syntax that
>> > > encodes by default (e.g #{expr}, ^{expr}, or whatever).
>> > > I know about ${H(expr)}, but that still requires that I remember to
>> > > include the call to H. I want the brain-dead, always-do-it, I-don't-
>> > > have-to-think-about-it option. I'm more than willing to submit a patch
>> > > if that would be helpful.
Nothing wrong with ${H(expr)} at all, and I wouldn't suggest the way
that works would change at all. It is an interesting point though that
if you should html encode anything that doesn't explicitly contain
html, it does mean you have to opt-in to that behavior every time you
surface a value.
Saves three whole keystrokes per field too. :)
Say! Along those lines (where a lot of this is personal preference)
what if it was configurable where different prefixes could have
defined wrapping code?
@ or ^ for H(...) would be one example, but another useful one could
be mapping some character like * to Html.ActionLink(...). So you could
use syntax *{"click here", "index", "products"} as a shortcut to all
of the overloads of that particular helper? Never have to type
Html.ActionLink again.
On 12/17/08, Torkel Ödegaard <torkel.odega...@gmail.com> wrote:
> On Wed, Dec 17, 2008 at 5:24 AM, Chad Lee <chadl...@gmail.com> wrote:
>> What's wrong with the current way?
>> ${H(myVar)}
>> I don't see much value in adding a shortcut to this already short method
>> call.
>> On Tue, Dec 16, 2008 at 10:21 PM, Kevin Dente <kevinde...@gmail.com>
>> wrote:
>>> Hmm, I'm kind of partial to ^{product.Name} myself, for some reason.
>>> But I'm cool either way. You're right that +{} is flows pretty well on
>>> the keyboard.
>>> On Dec 16, 1:14 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
>>> > You're right it'd be impossible to add that directly to ${expr} without
>>> > making it impossible to send ${Html.ActionLink(...)}. I'd hesitate to
>>> > change
>>> > the default behavior of ${expr} because it would be a breaking change.
>>> > We
>>> > already had ?{cond} added when there was a compelling reason, so I
>>> > could
>>> > see
>>> > this if there was a consensus.
>>> > The #{expr} could collide with #statement if it was on the start of a
>>> > line,
>>> > so I don't think that'll fly.
>>> > Ah, I think & is out... Collides with &entity;...
>>> > If anything I think I'd lean towards <p>Product +{product.Name}</p>...
>>> > It
>>> > looks a little bit like you meant to add/append the value to the
>>> > literal
>>> > html, so implicit encoding would make sense, but even more importantly
>>> > the
>>> > [shift] "+{" sequence looks to be keyboard friendly.
>>> > On Tue, Dec 16, 2008 at 2:51 PM, Kevin Dente <kevinde...@gmail.com>
>>> > wrote:
>>> > > First, let me say that Spark looks very cool. Very nice work.
>>> > > There's been a bunch of discussion in the blogosphere lately about
>>> > > XSS
>>> > > and encoding output, with the the general consensus being "always
>>> > > HTML
>>> > > encode your output". Yet no view engines seem to do this. Have you
>>> > > considered making Spark encode output by default (with a way to
>>> > > escape, of course)? Or at least giving an expression syntax that
>>> > > encodes by default (e.g #{expr}, ^{expr}, or whatever).
>>> > > I know about ${H(expr)}, but that still requires that I remember to
>>> > > include the call to H. I want the brain-dead, always-do-it, I-don't-
>>> > > have-to-think-about-it option. I'm more than willing to submit a
>>> > > patch
>>> > > if that would be helpful.
Interesting idea. How would you envision the configurable prefixes
being defined? In a config file? One concern would be portabillity of
Spark pages across applications, if they each use their own prefix
conventions.
On Dec 17, 1:09 am, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> Nothing wrong with ${H(expr)} at all, and I wouldn't suggest the way
> that works would change at all. It is an interesting point though that
> if you should html encode anything that doesn't explicitly contain
> html, it does mean you have to opt-in to that behavior every time you
> surface a value.
> Saves three whole keystrokes per field too. :)
> Say! Along those lines (where a lot of this is personal preference)
> what if it was configurable where different prefixes could have
> defined wrapping code?
> @ or ^ for H(...) would be one example, but another useful one could
> be mapping some character like * to Html.ActionLink(...). So you could
> use syntax *{"click here", "index", "products"} as a shortcut to all
> of the overloads of that particular helper? Never have to type
> Html.ActionLink again.
> On 12/17/08, Torkel Ödegaard <torkel.odega...@gmail.com> wrote:
> > I kind of liked @{ }, but +{ } is also good.
> > On Wed, Dec 17, 2008 at 5:24 AM, Chad Lee <chadl...@gmail.com> wrote:
> >> What's wrong with the current way?
> >> ${H(myVar)}
> >> I don't see much value in adding a shortcut to this already short method
> >> call.
> >> On Tue, Dec 16, 2008 at 10:21 PM, Kevin Dente <kevinde...@gmail.com>
> >> wrote:
> >>> Hmm, I'm kind of partial to ^{product.Name} myself, for some reason.
> >>> But I'm cool either way. You're right that +{} is flows pretty well on
> >>> the keyboard.
> >>> On Dec 16, 1:14 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> >>> > You're right it'd be impossible to add that directly to ${expr} without
> >>> > making it impossible to send ${Html.ActionLink(...)}. I'd hesitate to
> >>> > change
> >>> > the default behavior of ${expr} because it would be a breaking change.
> >>> > We
> >>> > already had ?{cond} added when there was a compelling reason, so I
> >>> > could
> >>> > see
> >>> > this if there was a consensus.
> >>> > The #{expr} could collide with #statement if it was on the start of a
> >>> > line,
> >>> > so I don't think that'll fly.
> >>> > Ah, I think & is out... Collides with &entity;...
> >>> > If anything I think I'd lean towards <p>Product +{product.Name}</p>...
> >>> > It
> >>> > looks a little bit like you meant to add/append the value to the
> >>> > literal
> >>> > html, so implicit encoding would make sense, but even more importantly
> >>> > the
> >>> > [shift] "+{" sequence looks to be keyboard friendly.
> >>> > On Tue, Dec 16, 2008 at 2:51 PM, Kevin Dente <kevinde...@gmail.com>
> >>> > wrote:
> >>> > > First, let me say that Spark looks very cool. Very nice work.
> >>> > > There's been a bunch of discussion in the blogosphere lately about
> >>> > > XSS
> >>> > > and encoding output, with the the general consensus being "always
> >>> > > HTML
> >>> > > encode your output". Yet no view engines seem to do this. Have you
> >>> > > considered making Spark encode output by default (with a way to
> >>> > > escape, of course)? Or at least giving an expression syntax that
> >>> > > encodes by default (e.g #{expr}, ^{expr}, or whatever).
> >>> > > I know about ${H(expr)}, but that still requires that I remember to
> >>> > > include the call to H. I want the brain-dead, always-do-it, I-don't-
> >>> > > have-to-think-about-it option. I'm more than willing to submit a
> >>> > > patch
> >>> > > if that would be helpful.
I agree with Kevin that making something like that configurable would hurt
the portability of the code. Not to mention the difficulty in having to
figure out the different syntax that someone is using when moving to a new
code base.
Granted, it probably won't be a problem 90% of the time given that most
people won't change the defaults, but given that, why even make it an
option?
Again, I think it is too much risk for not much value. I'm fine with
${H()}.
On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente <kevinde...@gmail.com> wrote:
> Interesting idea. How would you envision the configurable prefixes
> being defined? In a config file? One concern would be portabillity of
> Spark pages across applications, if they each use their own prefix
> conventions.
> On Dec 17, 1:09 am, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> > Nothing wrong with ${H(expr)} at all, and I wouldn't suggest the way
> > that works would change at all. It is an interesting point though that
> > if you should html encode anything that doesn't explicitly contain
> > html, it does mean you have to opt-in to that behavior every time you
> > surface a value.
> > Saves three whole keystrokes per field too. :)
> > Say! Along those lines (where a lot of this is personal preference)
> > what if it was configurable where different prefixes could have
> > defined wrapping code?
> > @ or ^ for H(...) would be one example, but another useful one could
> > be mapping some character like * to Html.ActionLink(...). So you could
> > use syntax *{"click here", "index", "products"} as a shortcut to all
> > of the overloads of that particular helper? Never have to type
> > Html.ActionLink again.
> > On 12/17/08, Torkel Ödegaard <torkel.odega...@gmail.com> wrote:
> > > I kind of liked @{ }, but +{ } is also good.
> > > On Wed, Dec 17, 2008 at 5:24 AM, Chad Lee <chadl...@gmail.com> wrote:
> > >> What's wrong with the current way?
> > >> ${H(myVar)}
> > >> I don't see much value in adding a shortcut to this already short
> method
> > >> call.
> > >> On Tue, Dec 16, 2008 at 10:21 PM, Kevin Dente <kevinde...@gmail.com>
> > >> wrote:
> > >>> Hmm, I'm kind of partial to ^{product.Name} myself, for some reason.
> > >>> But I'm cool either way. You're right that +{} is flows pretty well
> on
> > >>> the keyboard.
> > >>> On Dec 16, 1:14 pm, "Louis DeJardin" <louis.dejar...@gmail.com>
> wrote:
> > >>> > You're right it'd be impossible to add that directly to ${expr}
> without
> > >>> > making it impossible to send ${Html.ActionLink(...)}. I'd hesitate
> to
> > >>> > change
> > >>> > the default behavior of ${expr} because it would be a breaking
> change.
> > >>> > We
> > >>> > already had ?{cond} added when there was a compelling reason, so I
> > >>> > could
> > >>> > see
> > >>> > this if there was a consensus.
> > >>> > The #{expr} could collide with #statement if it was on the start of
> a
> > >>> > line,
> > >>> > so I don't think that'll fly.
> > >>> > Ah, I think & is out... Collides with &entity;...
> > >>> > If anything I think I'd lean towards <p>Product
> +{product.Name}</p>...
> > >>> > It
> > >>> > looks a little bit like you meant to add/append the value to the
> > >>> > literal
> > >>> > html, so implicit encoding would make sense, but even more
> importantly
> > >>> > the
> > >>> > [shift] "+{" sequence looks to be keyboard friendly.
> > >>> > On Tue, Dec 16, 2008 at 2:51 PM, Kevin Dente <kevinde...@gmail.com
> > >>> > wrote:
> > >>> > > First, let me say that Spark looks very cool. Very nice work.
> > >>> > > There's been a bunch of discussion in the blogosphere lately
> about
> > >>> > > XSS
> > >>> > > and encoding output, with the the general consensus being "always
> > >>> > > HTML
> > >>> > > encode your output". Yet no view engines seem to do this. Have
> you
> > >>> > > considered making Spark encode output by default (with a way to
> > >>> > > escape, of course)? Or at least giving an expression syntax that
> > >>> > > encodes by default (e.g #{expr}, ^{expr}, or whatever).
> > >>> > > I know about ${H(expr)}, but that still requires that I remember
> to
> > >>> > > include the call to H. I want the brain-dead, always-do-it,
> I-don't-
> > >>> > > have-to-think-about-it option. I'm more than willing to submit a
> > >>> > > patch
> > >>> > > if that would be helpful.
Probably would need to be in <spark> config or ISparkSettings for the
settings to be available before the parse occurs. Which is a shame - I
really like how putting <use namespace> and <use assembly> in
_global.spark reduces dependency on web.config.
Don't other things like partials and macros also affect the
portability? If I have <rounded>stuff</rounded> that won't work
without _rounded.spark.
I agree config is suboptimal, and it does head down a configuration
over convention path, but who can say what helpers are most useful.
That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both
supported - it's not that there's anything right or wrong about the
alternatives and supporting both doesn't negatively impact either one.
I'd lean more towards making it configurable than adding universal
meaning to a number of different syntax.
On the other hand it would be pretty easy to turn your spark files
into a mass of unreadable shortcuts. Okay - how about moving away from
the idea of using punctuation, and instead use small expansion marks
that start with $...
To encourage portability and convention you could provide a small set
of compatible defaults for monorail and asp.net mvc, like the ones
above. Configuration only needed to extend or modify defaults, if you
never use them they won't affect anything, and still reads like ${}
visually and hopefully more intuitive than punctuation.
(Not trying to pitch the idea of course, just talking it through.)
I wonder if you would apply the same idea to <%= %>?
> I agree with Kevin that making something like that configurable would hurt
> the portability of the code. Not to mention the difficulty in having to
> figure out the different syntax that someone is using when moving to a new
> code base.
> Granted, it probably won't be a problem 90% of the time given that most
> people won't change the defaults, but given that, why even make it an
> option?
> Again, I think it is too much risk for not much value. I'm fine with
> ${H()}.
> On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente <kevinde...@gmail.com> wrote:
> > Interesting idea. How would you envision the configurable prefixes
> > being defined? In a config file? One concern would be portabillity of
> > Spark pages across applications, if they each use their own prefix
> > conventions.
> > On Dec 17, 1:09 am, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> > > Nothing wrong with ${H(expr)} at all, and I wouldn't suggest the way
> > > that works would change at all. It is an interesting point though that
> > > if you should html encode anything that doesn't explicitly contain
> > > html, it does mean you have to opt-in to that behavior every time you
> > > surface a value.
> > > Saves three whole keystrokes per field too. :)
> > > Say! Along those lines (where a lot of this is personal preference)
> > > what if it was configurable where different prefixes could have
> > > defined wrapping code?
> > > @ or ^ for H(...) would be one example, but another useful one could
> > > be mapping some character like * to Html.ActionLink(...). So you could
> > > use syntax *{"click here", "index", "products"} as a shortcut to all
> > > of the overloads of that particular helper? Never have to type
> > > Html.ActionLink again.
> > > On 12/17/08, Torkel Ödegaard <torkel.odega...@gmail.com> wrote:
> > > > I kind of liked @{ }, but +{ } is also good.
> > > > On Wed, Dec 17, 2008 at 5:24 AM, Chad Lee <chadl...@gmail.com> wrote:
> > > >> What's wrong with the current way?
> > > >> ${H(myVar)}
> > > >> I don't see much value in adding a shortcut to this already short
> > method
> > > >> call.
> > > >> On Tue, Dec 16, 2008 at 10:21 PM, Kevin Dente <kevinde...@gmail.com>
> > > >> wrote:
> > > >>> Hmm, I'm kind of partial to ^{product.Name} myself, for some reason.
> > > >>> But I'm cool either way. You're right that +{} is flows pretty well
> > on
> > > >>> the keyboard.
> > > >>> On Dec 16, 1:14 pm, "Louis DeJardin" <louis.dejar...@gmail.com>
> > wrote:
> > > >>> > You're right it'd be impossible to add that directly to ${expr}
> > without
> > > >>> > making it impossible to send ${Html.ActionLink(...)}. I'd hesitate
> > to
> > > >>> > change
> > > >>> > the default behavior of ${expr} because it would be a breaking
> > change.
> > > >>> > We
> > > >>> > already had ?{cond} added when there was a compelling reason, so I
> > > >>> > could
> > > >>> > see
> > > >>> > this if there was a consensus.
> > > >>> > The #{expr} could collide with #statement if it was on the start of
> > a
> > > >>> > line,
> > > >>> > so I don't think that'll fly.
> > > >>> > Ah, I think & is out... Collides with &entity;...
> > > >>> > If anything I think I'd lean towards <p>Product
> > +{product.Name}</p>...
> > > >>> > It
> > > >>> > looks a little bit like you meant to add/append the value to the
> > > >>> > literal
> > > >>> > html, so implicit encoding would make sense, but even more
> > importantly
> > > >>> > the
> > > >>> > [shift] "+{" sequence looks to be keyboard friendly.
> > > >>> > On Tue, Dec 16, 2008 at 2:51 PM, Kevin Dente <kevinde...@gmail.com
> > > >>> > wrote:
> > > >>> > > First, let me say that Spark looks very cool. Very nice work.
> > > >>> > > There's been a bunch of discussion in the blogosphere lately
> > about
> > > >>> > > XSS
> > > >>> > > and encoding output, with the the general consensus being "always
> > > >>> > > HTML
> > > >>> > > encode your output". Yet no view engines seem to do this. Have
> > you
> > > >>> > > considered making Spark encode output by default (with a way to
> > > >>> > > escape, of course)? Or at least giving an expression syntax that
> > > >>> > > encodes by default (e.g #{expr}, ^{expr}, or whatever).
> > > >>> > > I know about ${H(expr)}, but that still requires that I remember
> > to
> > > >>> > > include the call to H. I want the brain-dead, always-do-it,
> > I-don't-
> > > >>> > > have-to-think-about-it option. I'm more than willing to submit a
> > > >>> > > patch
> > > >>> > > if that would be helpful.
> I agree config is suboptimal, and it does head down a configuration
> over convention path, but who can say what helpers are most useful.
You can! :) I'd rather see methods like this hard-coded than defined in
configuration.
This thread started out with trying to find a way to get the default ${}
syntax to be html encoded so you wouldn't have to think about it - your
output would just automatically be encoded.
What we are talking about now is just providing user-defined shortcuts for
already-short method calls. Again, I don't see the value. I think it would
take more development time than it is worth.
That is just my 2 cents.
On Wed, Dec 17, 2008 at 2:09 PM, Louis DeJardin <Louis.DeJar...@gmail.com>wrote:
> Probably would need to be in <spark> config or ISparkSettings for the
> settings to be available before the parse occurs. Which is a shame - I
> really like how putting <use namespace> and <use assembly> in
> _global.spark reduces dependency on web.config.
> Don't other things like partials and macros also affect the
> portability? If I have <rounded>stuff</rounded> that won't work
> without _rounded.spark.
> I agree config is suboptimal, and it does head down a configuration
> over convention path, but who can say what helpers are most useful.
> That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both
> supported - it's not that there's anything right or wrong about the
> alternatives and supporting both doesn't negatively impact either one.
> I'd lean more towards making it configurable than adding universal
> meaning to a number of different syntax.
> On the other hand it would be pretty easy to turn your spark files
> into a mass of unreadable shortcuts. Okay - how about moving away from
> the idea of using punctuation, and instead use small expansion marks
> that start with $...
> To encourage portability and convention you could provide a small set
> of compatible defaults for monorail and asp.net mvc, like the ones
> above. Configuration only needed to extend or modify defaults, if you
> never use them they won't affect anything, and still reads like ${}
> visually and hopefully more intuitive than punctuation.
> (Not trying to pitch the idea of course, just talking it through.)
> I wonder if you would apply the same idea to <%= %>?
> On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
> > I agree with Kevin that making something like that configurable would
> hurt
> > the portability of the code. Not to mention the difficulty in having to
> > figure out the different syntax that someone is using when moving to a
> new
> > code base.
> > Granted, it probably won't be a problem 90% of the time given that most
> > people won't change the defaults, but given that, why even make it an
> > option?
> > Again, I think it is too much risk for not much value. I'm fine with
> > ${H()}.
> > On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente <kevinde...@gmail.com>
> wrote:
> > > Interesting idea. How would you envision the configurable prefixes
> > > being defined? In a config file? One concern would be portabillity of
> > > Spark pages across applications, if they each use their own prefix
> > > conventions.
> > > On Dec 17, 1:09 am, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> > > > Nothing wrong with ${H(expr)} at all, and I wouldn't suggest the way
> > > > that works would change at all. It is an interesting point though
> that
> > > > if you should html encode anything that doesn't explicitly contain
> > > > html, it does mean you have to opt-in to that behavior every time you
> > > > surface a value.
> > > > Saves three whole keystrokes per field too. :)
> > > > Say! Along those lines (where a lot of this is personal preference)
> > > > what if it was configurable where different prefixes could have
> > > > defined wrapping code?
> > > > @ or ^ for H(...) would be one example, but another useful one could
> > > > be mapping some character like * to Html.ActionLink(...). So you
> could
> > > > use syntax *{"click here", "index", "products"} as a shortcut to all
> > > > of the overloads of that particular helper? Never have to type
> > > > Html.ActionLink again.
> > > > On 12/17/08, Torkel Ödegaard <torkel.odega...@gmail.com> wrote:
> > > > > I kind of liked @{ }, but +{ } is also good.
> > > > > On Wed, Dec 17, 2008 at 5:24 AM, Chad Lee <chadl...@gmail.com>
> wrote:
> > > > >> What's wrong with the current way?
> > > > >> ${H(myVar)}
> > > > >> I don't see much value in adding a shortcut to this already short
> > > method
> > > > >> call.
> > > > >> On Tue, Dec 16, 2008 at 10:21 PM, Kevin Dente <
> kevinde...@gmail.com>
> > > > >> wrote:
> > > > >>> Hmm, I'm kind of partial to ^{product.Name} myself, for some
> reason.
> > > > >>> But I'm cool either way. You're right that +{} is flows pretty
> well
> > > on
> > > > >>> the keyboard.
> > > > >>> On Dec 16, 1:14 pm, "Louis DeJardin" <louis.dejar...@gmail.com>
> > > wrote:
> > > > >>> > You're right it'd be impossible to add that directly to ${expr}
> > > without
> > > > >>> > making it impossible to send ${Html.ActionLink(...)}. I'd
> hesitate
> > > to
> > > > >>> > change
> > > > >>> > the default behavior of ${expr} because it would be a breaking
> > > change.
> > > > >>> > We
> > > > >>> > already had ?{cond} added when there was a compelling reason,
> so I
> > > > >>> > could
> > > > >>> > see
> > > > >>> > this if there was a consensus.
> > > > >>> > The #{expr} could collide with #statement if it was on the
> start of
> > > a
> > > > >>> > line,
> > > > >>> > so I don't think that'll fly.
> > > > >>> > Ah, I think & is out... Collides with &entity;...
> > > > >>> > If anything I think I'd lean towards <p>Product
> > > +{product.Name}</p>...
> > > > >>> > It
> > > > >>> > looks a little bit like you meant to add/append the value to
> the
> > > > >>> > literal
> > > > >>> > html, so implicit encoding would make sense, but even more
> > > importantly
> > > > >>> > the
> > > > >>> > [shift] "+{" sequence looks to be keyboard friendly.
> > > > >>> > On Tue, Dec 16, 2008 at 2:51 PM, Kevin Dente <
> kevinde...@gmail.com
> > > > >>> > wrote:
> > > > >>> > > First, let me say that Spark looks very cool. Very nice work.
> > > > >>> > > There's been a bunch of discussion in the blogosphere lately
> > > about
> > > > >>> > > XSS
> > > > >>> > > and encoding output, with the the general consensus being
> "always
> > > > >>> > > HTML
> > > > >>> > > encode your output". Yet no view engines seem to do this.
> Have
> > > you
> > > > >>> > > considered making Spark encode output by default (with a way
> to
> > > > >>> > > escape, of course)? Or at least giving an expression syntax
> that
> > > > >>> > > encodes by default (e.g #{expr}, ^{expr}, or whatever).
> > > > >>> > > I know about ${H(expr)}, but that still requires that I
> remember
> > > to
> > > > >>> > > include the call to H. I want the brain-dead, always-do-it,
> > > I-don't-
> > > > >>> > > have-to-think-about-it option. I'm more than willing to
> submit a
> > > > >>> > > patch
> > > > >>> > > if that would be helpful.
This *feels* very similar to the macro concept that's already there
(granted, I'm very new to Spark, so maybe I'm off-base here). Would it
make sense to extend the existing capability to support this kind of
macro expansion?
On Dec 17, 12:09 pm, Louis DeJardin <Louis.DeJar...@gmail.com> wrote:
> Probably would need to be in <spark> config or ISparkSettings for the
> settings to be available before the parse occurs. Which is a shame - I
> really like how putting <use namespace> and <use assembly> in
> _global.spark reduces dependency on web.config.
> Don't other things like partials and macros also affect the
> portability? If I have <rounded>stuff</rounded> that won't work
> without _rounded.spark.
> I agree config is suboptimal, and it does head down a configuration
> over convention path, but who can say what helpers are most useful.
> That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both
> supported - it's not that there's anything right or wrong about the
> alternatives and supporting both doesn't negatively impact either one.
> I'd lean more towards making it configurable than adding universal
> meaning to a number of different syntax.
> On the other hand it would be pretty easy to turn your spark files
> into a mass of unreadable shortcuts. Okay - how about moving away from
> the idea of using punctuation, and instead use small expansion marks
> that start with $...
> To encourage portability and convention you could provide a small set
> of compatible defaults for monorail and asp.net mvc, like the ones
> above. Configuration only needed to extend or modify defaults, if you
> never use them they won't affect anything, and still reads like ${}
> visually and hopefully more intuitive than punctuation.
> (Not trying to pitch the idea of course, just talking it through.)
> I wonder if you would apply the same idea to <%= %>?
> On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
> > I agree with Kevin that making something like that configurable would hurt
> > the portability of the code. Not to mention the difficulty in having to
> > figure out the different syntax that someone is using when moving to a new
> > code base.
> > Granted, it probably won't be a problem 90% of the time given that most
> > people won't change the defaults, but given that, why even make it an
> > option?
> > Again, I think it is too much risk for not much value. I'm fine with
> > ${H()}.
> > On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente <kevinde...@gmail.com> wrote:
> > > Interesting idea. How would you envision the configurable prefixes
> > > being defined? In a config file? One concern would be portabillity of
> > > Spark pages across applications, if they each use their own prefix
> > > conventions.
> > > On Dec 17, 1:09 am, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> > > > Nothing wrong with ${H(expr)} at all, and I wouldn't suggest the way
> > > > that works would change at all. It is an interesting point though that
> > > > if you should html encode anything that doesn't explicitly contain
> > > > html, it does mean you have to opt-in to that behavior every time you
> > > > surface a value.
> > > > Saves three whole keystrokes per field too. :)
> > > > Say! Along those lines (where a lot of this is personal preference)
> > > > what if it was configurable where different prefixes could have
> > > > defined wrapping code?
> > > > @ or ^ for H(...) would be one example, but another useful one could
> > > > be mapping some character like * to Html.ActionLink(...). So you could
> > > > use syntax *{"click here", "index", "products"} as a shortcut to all
> > > > of the overloads of that particular helper? Never have to type
> > > > Html.ActionLink again.
> > > > On 12/17/08, Torkel Ödegaard <torkel.odega...@gmail.com> wrote:
> > > > > I kind of liked @{ }, but +{ } is also good.
> > > > > On Wed, Dec 17, 2008 at 5:24 AM, Chad Lee <chadl...@gmail.com> wrote:
> > > > >> What's wrong with the current way?
> > > > >> ${H(myVar)}
> > > > >> I don't see much value in adding a shortcut to this already short
> > > method
> > > > >> call.
> > > > >> On Tue, Dec 16, 2008 at 10:21 PM, Kevin Dente <kevinde...@gmail.com>
> > > > >> wrote:
> > > > >>> Hmm, I'm kind of partial to ^{product.Name} myself, for some reason.
> > > > >>> But I'm cool either way. You're right that +{} is flows pretty well
> > > on
> > > > >>> the keyboard.
> > > > >>> On Dec 16, 1:14 pm, "Louis DeJardin" <louis.dejar...@gmail.com>
> > > wrote:
> > > > >>> > You're right it'd be impossible to add that directly to ${expr}
> > > without
> > > > >>> > making it impossible to send ${Html.ActionLink(...)}. I'd hesitate
> > > to
> > > > >>> > change
> > > > >>> > the default behavior of ${expr} because it would be a breaking
> > > change.
> > > > >>> > We
> > > > >>> > already had ?{cond} added when there was a compelling reason, so I
> > > > >>> > could
> > > > >>> > see
> > > > >>> > this if there was a consensus.
> > > > >>> > The #{expr} could collide with #statement if it was on the start of
> > > a
> > > > >>> > line,
> > > > >>> > so I don't think that'll fly.
> > > > >>> > Ah, I think & is out... Collides with &entity;...
> > > > >>> > If anything I think I'd lean towards <p>Product
> > > +{product.Name}</p>...
> > > > >>> > It
> > > > >>> > looks a little bit like you meant to add/append the value to the
> > > > >>> > literal
> > > > >>> > html, so implicit encoding would make sense, but even more
> > > importantly
> > > > >>> > the
> > > > >>> > [shift] "+{" sequence looks to be keyboard friendly.
> > > > >>> > On Tue, Dec 16, 2008 at 2:51 PM, Kevin Dente <kevinde...@gmail.com
> > > > >>> > wrote:
> > > > >>> > > First, let me say that Spark looks very cool. Very nice work.
> > > > >>> > > There's been a bunch of discussion in the blogosphere lately
> > > about
> > > > >>> > > XSS
> > > > >>> > > and encoding output, with the the general consensus being "always
> > > > >>> > > HTML
> > > > >>> > > encode your output". Yet no view engines seem to do this. Have
> > > you
> > > > >>> > > considered making Spark encode output by default (with a way to
> > > > >>> > > escape, of course)? Or at least giving an expression syntax that
> > > > >>> > > encodes by default (e.g #{expr}, ^{expr}, or whatever).
> > > > >>> > > I know about ${H(expr)}, but that still requires that I remember
> > > to
> > > > >>> > > include the call to H. I want the brain-dead, always-do-it,
> > > I-don't-
> > > > >>> > > have-to-think-about-it option. I'm more than willing to submit a
> > > > >>> > > patch
> > > > >>> > > if that would be helpful.
Well the macro is more about a way to create helper-like functions
with the spark dialect. Helps keep html concatination out of cs.
But it is true if you add a base page class to a project you can add
any functions like H() there - so that would probably be a better way
to add ${L(...)}
So only thing you'd save are the parens.
On 12/17/08, Kevin Dente <kevinde...@gmail.com> wrote:
> This *feels* very similar to the macro concept that's already there
> (granted, I'm very new to Spark, so maybe I'm off-base here). Would it
> make sense to extend the existing capability to support this kind of
> macro expansion?
> On Dec 17, 12:09 pm, Louis DeJardin <Louis.DeJar...@gmail.com> wrote:
>> Probably would need to be in <spark> config or ISparkSettings for the
>> settings to be available before the parse occurs. Which is a shame - I
>> really like how putting <use namespace> and <use assembly> in
>> _global.spark reduces dependency on web.config.
>> Don't other things like partials and macros also affect the
>> portability? If I have <rounded>stuff</rounded> that won't work
>> without _rounded.spark.
>> I agree config is suboptimal, and it does head down a configuration
>> over convention path, but who can say what helpers are most useful.
>> That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both
>> supported - it's not that there's anything right or wrong about the
>> alternatives and supporting both doesn't negatively impact either one.
>> I'd lean more towards making it configurable than adding universal
>> meaning to a number of different syntax.
>> On the other hand it would be pretty easy to turn your spark files
>> into a mass of unreadable shortcuts. Okay - how about moving away from
>> the idea of using punctuation, and instead use small expansion marks
>> that start with $...
>> To encourage portability and convention you could provide a small set
>> of compatible defaults for monorail and asp.net mvc, like the ones
>> above. Configuration only needed to extend or modify defaults, if you
>> never use them they won't affect anything, and still reads like ${}
>> visually and hopefully more intuitive than punctuation.
>> (Not trying to pitch the idea of course, just talking it through.)
>> I wonder if you would apply the same idea to <%= %>?
>> On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
>> > I agree with Kevin that making something like that configurable would
>> > hurt
>> > the portability of the code. Not to mention the difficulty in having to
>> > figure out the different syntax that someone is using when moving to a
>> > new
>> > code base.
>> > Granted, it probably won't be a problem 90% of the time given that most
>> > people won't change the defaults, but given that, why even make it an
>> > option?
>> > Again, I think it is too much risk for not much value. I'm fine with
>> > ${H()}.
>> > On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente <kevinde...@gmail.com>
>> > wrote:
>> > > Interesting idea. How would you envision the configurable prefixes
>> > > being defined? In a config file? One concern would be portabillity of
>> > > Spark pages across applications, if they each use their own prefix
>> > > conventions.
>> > > On Dec 17, 1:09 am, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
>> > > > Nothing wrong with ${H(expr)} at all, and I wouldn't suggest the way
>> > > > that works would change at all. It is an interesting point though
>> > > > that
>> > > > if you should html encode anything that doesn't explicitly contain
>> > > > html, it does mean you have to opt-in to that behavior every time
>> > > > you
>> > > > surface a value.
>> > > > Saves three whole keystrokes per field too. :)
>> > > > Say! Along those lines (where a lot of this is personal preference)
>> > > > what if it was configurable where different prefixes could have
>> > > > defined wrapping code?
>> > > > @ or ^ for H(...) would be one example, but another useful one could
>> > > > be mapping some character like * to Html.ActionLink(...). So you
>> > > > could
>> > > > use syntax *{"click here", "index", "products"} as a shortcut to all
>> > > > of the overloads of that particular helper? Never have to type
>> > > > Html.ActionLink again.
>> > > > On 12/17/08, Torkel Ödegaard <torkel.odega...@gmail.com> wrote:
>> > > > > I kind of liked @{ }, but +{ } is also good.
>> > > > > On Wed, Dec 17, 2008 at 5:24 AM, Chad Lee <chadl...@gmail.com>
>> > > > > wrote:
>> > > > >> What's wrong with the current way?
>> > > > >> ${H(myVar)}
>> > > > >> I don't see much value in adding a shortcut to this already short
>> > > method
>> > > > >> call.
>> > > > >> On Tue, Dec 16, 2008 at 10:21 PM, Kevin Dente
>> > > > >> <kevinde...@gmail.com>
>> > > > >> wrote:
>> > > > >>> Hmm, I'm kind of partial to ^{product.Name} myself, for some
>> > > > >>> reason.
>> > > > >>> But I'm cool either way. You're right that +{} is flows pretty
>> > > > >>> well
>> > > on
>> > > > >>> the keyboard.
>> > > > >>> On Dec 16, 1:14 pm, "Louis DeJardin" <louis.dejar...@gmail.com>
>> > > wrote:
>> > > > >>> > You're right it'd be impossible to add that directly to
>> > > > >>> > ${expr}
>> > > without
>> > > > >>> > making it impossible to send ${Html.ActionLink(...)}. I'd
>> > > > >>> > hesitate
>> > > to
>> > > > >>> > change
>> > > > >>> > the default behavior of ${expr} because it would be a breaking
>> > > change.
>> > > > >>> > We
>> > > > >>> > already had ?{cond} added when there was a compelling reason,
>> > > > >>> > so I
>> > > > >>> > could
>> > > > >>> > see
>> > > > >>> > this if there was a consensus.
>> > > > >>> > The #{expr} could collide with #statement if it was on the
>> > > > >>> > start of
>> > > a
>> > > > >>> > line,
>> > > > >>> > so I don't think that'll fly.
>> > > > >>> > Ah, I think & is out... Collides with &entity;...
>> > > > >>> > If anything I think I'd lean towards <p>Product
>> > > +{product.Name}</p>...
>> > > > >>> > It
>> > > > >>> > looks a little bit like you meant to add/append the value to
>> > > > >>> > the
>> > > > >>> > literal
>> > > > >>> > html, so implicit encoding would make sense, but even more
>> > > importantly
>> > > > >>> > the
>> > > > >>> > [shift] "+{" sequence looks to be keyboard friendly.
>> > > > >>> > On Tue, Dec 16, 2008 at 2:51 PM, Kevin Dente
>> > > > >>> > <kevinde...@gmail.com
>> > > > >>> > wrote:
>> > > > >>> > > First, let me say that Spark looks very cool. Very nice
>> > > > >>> > > work.
>> > > > >>> > > There's been a bunch of discussion in the blogosphere lately
>> > > about
>> > > > >>> > > XSS
>> > > > >>> > > and encoding output, with the the general consensus being
>> > > > >>> > > "always
>> > > > >>> > > HTML
>> > > > >>> > > encode your output". Yet no view engines seem to do this.
>> > > > >>> > > Have
>> > > you
>> > > > >>> > > considered making Spark encode output by default (with a way
>> > > > >>> > > to
>> > > > >>> > > escape, of course)? Or at least giving an expression syntax
>> > > > >>> > > that
>> > > > >>> > > encodes by default (e.g #{expr}, ^{expr}, or whatever).
>> > > > >>> > > I know about ${H(expr)}, but that still requires that I
>> > > > >>> > > remember
>> > > to
>> > > > >>> > > include the call to H. I want the brain-dead, always-do-it,
>> > > I-don't-
>> > > > >>> > > have-to-think-about-it option. I'm more than willing to
>> > > > >>> > > submit a
>> > > > >>> > > patch
>> > > > >>> > > if that would be helpful.
I'm not sure if any in particular really stand out to me. I might lean
towards $${expr} since I'm already used to seeing ${expr}. There's
also precedent to using two-character $ syntax with $!{expr} to
silence null exceptions.
On Dec 17, 9:54 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> Well the macro is more about a way to create helper-like functions
> with the spark dialect. Helps keep html concatination out of cs.
> But it is true if you add a base page class to a project you can add
> any functions like H() there - so that would probably be a better way
> to add ${L(...)}
> So only thing you'd save are the parens.
> On 12/17/08, Kevin Dente <kevinde...@gmail.com> wrote:
> > This *feels* very similar to the macro concept that's already there
> > (granted, I'm very new to Spark, so maybe I'm off-base here). Would it
> > make sense to extend the existing capability to support this kind of
> > macro expansion?
> > On Dec 17, 12:09 pm, Louis DeJardin <Louis.DeJar...@gmail.com> wrote:
> >> Probably would need to be in <spark> config or ISparkSettings for the
> >> settings to be available before the parse occurs. Which is a shame - I
> >> really like how putting <use namespace> and <use assembly> in
> >> _global.spark reduces dependency on web.config.
> >> Don't other things like partials and macros also affect the
> >> portability? If I have <rounded>stuff</rounded> that won't work
> >> without _rounded.spark.
> >> I agree config is suboptimal, and it does head down a configuration
> >> over convention path, but who can say what helpers are most useful.
> >> That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both
> >> supported - it's not that there's anything right or wrong about the
> >> alternatives and supporting both doesn't negatively impact either one.
> >> I'd lean more towards making it configurable than adding universal
> >> meaning to a number of different syntax.
> >> On the other hand it would be pretty easy to turn your spark files
> >> into a mass of unreadable shortcuts. Okay - how about moving away from
> >> the idea of using punctuation, and instead use small expansion marks
> >> that start with $...
> >> To encourage portability and convention you could provide a small set
> >> of compatible defaults for monorail and asp.net mvc, like the ones
> >> above. Configuration only needed to extend or modify defaults, if you
> >> never use them they won't affect anything, and still reads like ${}
> >> visually and hopefully more intuitive than punctuation.
> >> (Not trying to pitch the idea of course, just talking it through.)
> >> I wonder if you would apply the same idea to <%= %>?
> >> On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
> >> > I agree with Kevin that making something like that configurable would
> >> > hurt
> >> > the portability of the code. Not to mention the difficulty in having to
> >> > figure out the different syntax that someone is using when moving to a
> >> > new
> >> > code base.
> >> > Granted, it probably won't be a problem 90% of the time given that most
> >> > people won't change the defaults, but given that, why even make it an
> >> > option?
> >> > Again, I think it is too much risk for not much value. I'm fine with
> >> > ${H()}.
> >> > On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente <kevinde...@gmail.com>
> >> > wrote:
> >> > > Interesting idea. How would you envision the configurable prefixes
> >> > > being defined? In a config file? One concern would be portabillity of
> >> > > Spark pages across applications, if they each use their own prefix
> >> > > conventions.
> >> > > On Dec 17, 1:09 am, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> >> > > > Nothing wrong with ${H(expr)} at all, and I wouldn't suggest the way
> >> > > > that works would change at all. It is an interesting point though
> >> > > > that
> >> > > > if you should html encode anything that doesn't explicitly contain
> >> > > > html, it does mean you have to opt-in to that behavior every time
> >> > > > you
> >> > > > surface a value.
> >> > > > Saves three whole keystrokes per field too. :)
> >> > > > Say! Along those lines (where a lot of this is personal preference)
> >> > > > what if it was configurable where different prefixes could have
> >> > > > defined wrapping code?
> >> > > > @ or ^ for H(...) would be one example, but another useful one could
> >> > > > be mapping some character like * to Html.ActionLink(...). So you
> >> > > > could
> >> > > > use syntax *{"click here", "index", "products"} as a shortcut to all
> >> > > > of the overloads of that particular helper? Never have to type
> >> > > > Html.ActionLink again.
> >> > > > > I kind of liked @{ }, but +{ } is also good.
> >> > > > > On Wed, Dec 17, 2008 at 5:24 AM, Chad Lee <chadl...@gmail.com>
> >> > > > > wrote:
> >> > > > >> What's wrong with the current way?
> >> > > > >> ${H(myVar)}
> >> > > > >> I don't see much value in adding a shortcut to this already short
> >> > > method
> >> > > > >> call.
> >> > > > >> On Tue, Dec 16, 2008 at 10:21 PM, Kevin Dente
> >> > > > >> <kevinde...@gmail.com>
> >> > > > >> wrote:
> >> > > > >>> Hmm, I'm kind of partial to ^{product.Name} myself, for some
> >> > > > >>> reason.
> >> > > > >>> But I'm cool either way. You're right that +{} is flows pretty
> >> > > > >>> well
> >> > > on
> >> > > > >>> the keyboard.
> >> > > > >>> On Dec 16, 1:14 pm, "Louis DeJardin" <louis.dejar...@gmail.com>
> >> > > wrote:
> >> > > > >>> > You're right it'd be impossible to add that directly to
> >> > > > >>> > ${expr}
> >> > > without
> >> > > > >>> > making it impossible to send ${Html.ActionLink(...)}. I'd
> >> > > > >>> > hesitate
> >> > > to
> >> > > > >>> > change
> >> > > > >>> > the default behavior of ${expr} because it would be a breaking
> >> > > change.
> >> > > > >>> > We
> >> > > > >>> > already had ?{cond} added when there was a compelling reason,
> >> > > > >>> > so I
> >> > > > >>> > could
> >> > > > >>> > see
> >> > > > >>> > this if there was a consensus.
> >> > > > >>> > The #{expr} could collide with #statement if it was on the
> >> > > > >>> > start of
> >> > > a
> >> > > > >>> > line,
> >> > > > >>> > so I don't think that'll fly.
> >> > > > >>> > Ah, I think & is out... Collides with &entity;...
> >> > > > >>> > If anything I think I'd lean towards <p>Product
> >> > > +{product.Name}</p>...
> >> > > > >>> > It
> >> > > > >>> > looks a little bit like you meant to add/append the value to
> >> > > > >>> > the
> >> > > > >>> > literal
> >> > > > >>> > html, so implicit encoding would make sense, but even more
> >> > > importantly
> >> > > > >>> > the
> >> > > > >>> > [shift] "+{" sequence looks to be keyboard friendly.
> >> > > > >>> > On Tue, Dec 16, 2008 at 2:51 PM, Kevin Dente
> >> > > > >>> > <kevinde...@gmail.com
> >> > > > >>> > wrote:
> >> > > > >>> > > First, let me say that Spark looks very cool. Very nice
> >> > > > >>> > > work.
> >> > > > >>> > > There's been a bunch of discussion in the blogosphere lately
> >> > > about
> >> > > > >>> > > XSS
> >> > > > >>> > > and encoding output, with the the general consensus being
> >> > > > >>> > > "always
> >> > > > >>> > > HTML
> >> > > > >>> > > encode your output". Yet no view engines seem to do this.
> >> > > > >>> > > Have
> >> > > you
> >> > > > >>> > > considered making Spark encode output by default (with a way
> >> > > > >>> > > to
> >> > > > >>> > > escape, of course)? Or at least giving an expression syntax
> >> > > > >>> > > that
> >> > > > >>> > > encodes by default (e.g #{expr}, ^{expr}, or whatever).
> >> > > > >>> > > I know about ${H(expr)}, but that still requires that I
> >> > > > >>> > > remember
> >> > > to
> >> > > > >>> > > include the call to H. I want the brain-dead, always-do-it,
> >> > > I-don't-
> >> > > > >>> > > have-to-think-about-it option. I'm more than willing to
> >> > > > >>> > > submit a
> >> > > > >>> > > patch
> >> > > > >>> > > if that would be helpful.
> I'm not sure if any in particular really stand out to me. I might lean
> towards $${expr} since I'm already used to seeing ${expr}. There's
> also precedent to using two-character $ syntax with $!{expr} to
> silence null exceptions.
> On Dec 17, 9:54 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> > Well the macro is more about a way to create helper-like functions
> > with the spark dialect. Helps keep html concatination out of cs.
> > But it is true if you add a base page class to a project you can add
> > any functions like H() there - so that would probably be a better way
> > to add ${L(...)}
> > So only thing you'd save are the parens.
> > On 12/17/08, Kevin Dente <kevinde...@gmail.com> wrote:
> > > This *feels* very similar to the macro concept that's already there
> > > (granted, I'm very new to Spark, so maybe I'm off-base here). Would it
> > > make sense to extend the existing capability to support this kind of
> > > macro expansion?
> > > On Dec 17, 12:09 pm, Louis DeJardin <Louis.DeJar...@gmail.com> wrote:
> > >> Probably would need to be in <spark> config or ISparkSettings for the
> > >> settings to be available before the parse occurs. Which is a shame - I
> > >> really like how putting <use namespace> and <use assembly> in
> > >> _global.spark reduces dependency on web.config.
> > >> Don't other things like partials and macros also affect the
> > >> portability? If I have <rounded>stuff</rounded> that won't work
> > >> without _rounded.spark.
> > >> I agree config is suboptimal, and it does head down a configuration
> > >> over convention path, but who can say what helpers are most useful.
> > >> That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both
> > >> supported - it's not that there's anything right or wrong about the
> > >> alternatives and supporting both doesn't negatively impact either one.
> > >> I'd lean more towards making it configurable than adding universal
> > >> meaning to a number of different syntax.
> > >> On the other hand it would be pretty easy to turn your spark files
> > >> into a mass of unreadable shortcuts. Okay - how about moving away from
> > >> the idea of using punctuation, and instead use small expansion marks
> > >> that start with $...
> > >> To encourage portability and convention you could provide a small set
> > >> of compatible defaults for monorail and asp.net mvc, like the ones
> > >> above. Configuration only needed to extend or modify defaults, if you
> > >> never use them they won't affect anything, and still reads like ${}
> > >> visually and hopefully more intuitive than punctuation.
> > >> (Not trying to pitch the idea of course, just talking it through.)
> > >> I wonder if you would apply the same idea to <%= %>?
> > >> On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
> > >> > I agree with Kevin that making something like that configurable would
> > >> > hurt
> > >> > the portability of the code. Not to mention the difficulty in having to
> > >> > figure out the different syntax that someone is using when moving to a
> > >> > new
> > >> > code base.
> > >> > Granted, it probably won't be a problem 90% of the time given that most
> > >> > people won't change the defaults, but given that, why even make it an
> > >> > option?
> > >> > Again, I think it is too much risk for not much value. I'm fine with
> > >> > ${H()}.
> > >> > On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente <kevinde...@gmail.com>
> > >> > wrote:
> > >> > > Interesting idea. How would you envision the configurable prefixes
> > >> > > being defined? In a config file? One concern would be portabillity of
> > >> > > Spark pages across applications, if they each use their own prefix
> > >> > > conventions.
> > >> > > On Dec 17, 1:09 am, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> > >> > > > Nothing wrong with ${H(expr)} at all, and I wouldn't suggest the way
> > >> > > > that works would change at all. It is an interesting point though
> > >> > > > that
> > >> > > > if you should html encode anything that doesn't explicitly contain
> > >> > > > html, it does mean you have to opt-in to that behavior every time
> > >> > > > you
> > >> > > > surface a value.
> > >> > > > Saves three whole keystrokes per field too. :)
> > >> > > > Say! Along those lines (where a lot of this is personal preference)
> > >> > > > what if it was configurable where different prefixes could have
> > >> > > > defined wrapping code?
> > >> > > > @ or ^ for H(...) would be one example, but another useful one could
> > >> > > > be mapping some character like * to Html.ActionLink(...). So you
> > >> > > > could
> > >> > > > use syntax *{"click here", "index", "products"} as a shortcut to all
> > >> > > > of the overloads of that particular helper? Never have to type
> > >> > > > Html.ActionLink again.
> > >> > > > > I kind of liked @{ }, but +{ } is also good.
> > >> > > > > On Wed, Dec 17, 2008 at 5:24 AM, Chad Lee <chadl...@gmail.com>
> > >> > > > > wrote:
> > >> > > > >> What's wrong with the current way?
> > >> > > > >> ${H(myVar)}
> > >> > > > >> I don't see much value in adding a shortcut to this already short
> > >> > > method
> > >> > > > >> call.
> > >> > > > >> On Tue, Dec 16, 2008 at 10:21 PM, Kevin Dente
> > >> > > > >> <kevinde...@gmail.com>
> > >> > > > >> wrote:
> > >> > > > >>> Hmm, I'm kind of partial to ^{product.Name} myself, for some
> > >> > > > >>> reason.
> > >> > > > >>> But I'm cool either way. You're right that +{} is flows pretty
> > >> > > > >>> well
> > >> > > on
> > >> > > > >>> the keyboard.
> > >> > > > >>> On Dec 16, 1:14 pm, "Louis DeJardin" <louis.dejar...@gmail.com>
> > >> > > wrote:
> > >> > > > >>> > You're right it'd be impossible to add that directly to
> > >> > > > >>> > ${expr}
> > >> > > without
> > >> > > > >>> > making it impossible to send ${Html.ActionLink(...)}. I'd
> > >> > > > >>> > hesitate
> > >> > > to
> > >> > > > >>> > change
> > >> > > > >>> > the default behavior of ${expr} because it would be a breaking
> > >> > > change.
> > >> > > > >>> > We
> > >> > > > >>> > already had ?{cond} added when there was a compelling reason,
> > >> > > > >>> > so I
> > >> > > > >>> > could
> > >> > > > >>> > see
> > >> > > > >>> > this if there was a consensus.
> > >> > > > >>> > The #{expr} could collide with #statement if it was on the
> > >> > > > >>> > start of
> > >> > > a
> > >> > > > >>> > line,
> > >> > > > >>> > so I don't think that'll fly.
> > I'm not sure if any in particular really stand out to me. I might lean
> > towards $${expr} since I'm already used to seeing ${expr}. There's
> > also precedent to using two-character $ syntax with $!{expr} to
> > silence null exceptions.
> > On Dec 17, 9:54 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> > > Well the macro is more about a way to create helper-like functions
> > > with the spark dialect. Helps keep html concatination out of cs.
> > > But it is true if you add a base page class to a project you can add
> > > any functions like H() there - so that would probably be a better way
> > > to add ${L(...)}
> > > So only thing you'd save are the parens.
> > > On 12/17/08, Kevin Dente <kevinde...@gmail.com> wrote:
> > > > This *feels* very similar to the macro concept that's already there
> > > > (granted, I'm very new to Spark, so maybe I'm off-base here). Would
> it
> > > > make sense to extend the existing capability to support this kind of
> > > > macro expansion?
> > > > On Dec 17, 12:09 pm, Louis DeJardin <Louis.DeJar...@gmail.com>
> wrote:
> > > >> Probably would need to be in <spark> config or ISparkSettings for
> the
> > > >> settings to be available before the parse occurs. Which is a shame -
> I
> > > >> really like how putting <use namespace> and <use assembly> in
> > > >> _global.spark reduces dependency on web.config.
> > > >> Don't other things like partials and macros also affect the
> > > >> portability? If I have <rounded>stuff</rounded> that won't work
> > > >> without _rounded.spark.
> > > >> I agree config is suboptimal, and it does head down a configuration
> > > >> over convention path, but who can say what helpers are most useful.
> > > >> That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both
> > > >> supported - it's not that there's anything right or wrong about the
> > > >> alternatives and supporting both doesn't negatively impact either
> one.
> > > >> I'd lean more towards making it configurable than adding universal
> > > >> meaning to a number of different syntax.
> > > >> On the other hand it would be pretty easy to turn your spark files
> > > >> into a mass of unreadable shortcuts. Okay - how about moving away
> from
> > > >> the idea of using punctuation, and instead use small expansion marks
> > > >> that start with $...
> > > >> To encourage portability and convention you could provide a small
> set
> > > >> of compatible defaults for monorail and asp.net mvc, like the ones
> > > >> above. Configuration only needed to extend or modify defaults, if
> you
> > > >> never use them they won't affect anything, and still reads like ${}
> > > >> visually and hopefully more intuitive than punctuation.
> > > >> (Not trying to pitch the idea of course, just talking it through.)
> > > >> I wonder if you would apply the same idea to <%= %>?
> > > >> On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
> > > >> > I agree with Kevin that making something like that configurable
> would
> > > >> > hurt
> > > >> > the portability of the code. Not to mention the difficulty in
> having to
> > > >> > figure out the different syntax that someone is using when moving
> to a
> > > >> > new
> > > >> > code base.
> > > >> > Granted, it probably won't be a problem 90% of the time given that
> most
> > > >> > people won't change the defaults, but given that, why even make it
> an
> > > >> > option?
> > > >> > Again, I think it is too much risk for not much value. I'm fine
> with
> > > >> > ${H()}.
> > > >> > On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente <
> kevinde...@gmail.com>
> > > >> > wrote:
> > > >> > > Interesting idea. How would you envision the configurable
> prefixes
> > > >> > > being defined? In a config file? One concern would be
> portabillity of
> > > >> > > Spark pages across applications, if they each use their own
> prefix
> > > >> > > conventions.
> > > >> > > On Dec 17, 1:09 am, "Louis DeJardin" <louis.dejar...@gmail.com>
> wrote:
> > > >> > > > Nothing wrong with ${H(expr)} at all, and I wouldn't suggest
> the way
> > > >> > > > that works would change at all. It is an interesting point
> though
> > > >> > > > that
> > > >> > > > if you should html encode anything that doesn't explicitly
> contain
> > > >> > > > html, it does mean you have to opt-in to that behavior every
> time
> > > >> > > > you
> > > >> > > > surface a value.
> > > >> > > > Saves three whole keystrokes per field too. :)
> > > >> > > > Say! Along those lines (where a lot of this is personal
> preference)
> > > >> > > > what if it was configurable where different prefixes could
> have
> > > >> > > > defined wrapping code?
> > > >> > > > @ or ^ for H(...) would be one example, but another useful one
> could
> > > >> > > > be mapping some character like * to Html.ActionLink(...). So
> you
> > > >> > > > could
> > > >> > > > use syntax *{"click here", "index", "products"} as a shortcut
> to all
> > > >> > > > of the overloads of that particular helper? Never have to type
> > > >> > > > Html.ActionLink again.
> > > >> > > > >>> > Ah, I think & is out... Collides with &entity;...
> > > >> > > > >>> > If anything I think I'd lean towards <p>Product
> > > >> > > +{product.Name}</p>...
> > > >> > > > >>> > It
> > > >> > > > >>> > looks a little bit like you meant to add/append the
> value to
> > > >> > > > >>> > the
>> > I'm not sure if any in particular really stand out to me. I might lean >> > towards $${expr} since I'm already used to seeing ${expr}. There's >> > also precedent to using two-character $ syntax with $!{expr} to >> > silence null exceptions.
>> > On Dec 17, 9:54 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
>> > > Well the macro is more about a way to create helper-like functions >> > > with the spark dialect. Helps keep html concatination out of cs.
>> > > But it is true if you add a base page class to a project you can add >> > > any functions like H() there - so that would probably be a better way >> > > to add ${L(...)}
>> > > So only thing you'd save are the parens.
>> > > On 12/17/08, Kevin Dente <kevinde...@gmail.com> wrote:
>> > > > This *feels* very similar to the macro concept that's already there >> > > > (granted, I'm very new to Spark, so maybe I'm off-base here). Would >> it >> > > > make sense to extend the existing capability to support this kind of >> > > > macro expansion?
>> > > > On Dec 17, 12:09 pm, Louis DeJardin <Louis.DeJar...@gmail.com> >> wrote: >> > > >> Probably would need to be in <spark> config or ISparkSettings for >> the >> > > >> settings to be available before the parse occurs. Which is a shame >> - I >> > > >> really like how putting <use namespace> and <use assembly> in >> > > >> _global.spark reduces dependency on web.config.
>> > > >> Don't other things like partials and macros also affect the >> > > >> portability? If I have <rounded>stuff</rounded> that won't work >> > > >> without _rounded.spark.
>> > > >> I agree config is suboptimal, and it does head down a configuration >> > > >> over convention path, but who can say what helpers are most useful. >> > > >> That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both >> > > >> supported - it's not that there's anything right or wrong about the >> > > >> alternatives and supporting both doesn't negatively impact either >> one.
>> > > >> I'd lean more towards making it configurable than adding universal >> > > >> meaning to a number of different syntax.
>> > > >> On the other hand it would be pretty easy to turn your spark files >> > > >> into a mass of unreadable shortcuts. Okay - how about moving away >> from >> > > >> the idea of using punctuation, and instead use small expansion >> marks >> > > >> that start with $...
>> > > >> To encourage portability and convention you could provide a small >> set >> > > >> of compatible defaults for monorail and asp.net mvc, like the ones >> > > >> above. Configuration only needed to extend or modify defaults, if >> you >> > > >> never use them they won't affect anything, and still reads like ${} >> > > >> visually and hopefully more intuitive than punctuation.
>> > > >> (Not trying to pitch the idea of course, just talking it through.)
>> > > >> I wonder if you would apply the same idea to <%= %>?
>> > > >> On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
>> > > >> > I agree with Kevin that making something like that configurable >> would >> > > >> > hurt >> > > >> > the portability of the code. Not to mention the difficulty in >> having to >> > > >> > figure out the different syntax that someone is using when moving >> to a >> > > >> > new >> > > >> > code base.
>> > > >> > Granted, it probably won't be a problem 90% of the time given >> that most >> > > >> > people won't change the defaults, but given that, why even make >> it an >> > > >> > option?
>> > > >> > Again, I think it is too much risk for not much value. I'm fine >> with >> > > >> > ${H()}.
>> > > >> > On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente < >> kevinde...@gmail.com> >> > > >> > wrote:
>> > > >> > > Interesting idea. How would you envision the configurable >> prefixes >> > > >> > > being defined? In a config file? One concern would be >> portabillity of >> > > >> > > Spark pages across applications, if they each use their own >> prefix >> > > >> > > conventions.
>> > > >> > > On Dec 17, 1:09 am, "Louis DeJardin" <louis.dejar...@gmail.com> >> wrote: >> > > >> > > > Nothing wrong with ${H(expr)} at all, and I wouldn't suggest >> the way >> > > >> > > > that works would change at all. It is an interesting point >> though >> > > >> > > > that >> > > >> > > > if you should html encode anything that doesn't explicitly >> contain >> > > >> > > > html, it does mean you have to opt-in to that behavior every >> time >> > > >> > > > you >> > > >> > > > surface a value.
>> > > >> > > > Saves three whole keystrokes per field too. :)
>> > > >> > > > Say! Along those lines (where a lot of this is personal >> preference) >> > > >> > > > what if it was configurable where different prefixes could >> have >> > > >> > > > defined wrapping code?
>> > > >> > > > @ or ^ for H(...) would be one example, but another useful >> one could >> > > >> > > > be mapping some character like * to Html.ActionLink(...). So >> you >> > > >> > > > could >> > > >> > > > use syntax *{"click here", "index", "products"} as a shortcut >> to all >> > > >> > > > of the overloads of that particular helper? Never have to >> type >> > > >> > > > Html.ActionLink again.
That would be nice but unfortunately it couldn't be defined inside of
the spark files because the information would need to be used by the
first stage parser. The breakdown of the files text happens before the
macros are known.
On Dec 18, 12:23 pm, "Артём Тихомиров" <ar...@tikhomirovs.ru> wrote:
> On Thu, Dec 18, 2008 at 9:20 PM, Артём Тихомиров <ar...@tikhomirovs.ru>wrote:
> > I think that signs as alias for macro functions would be much more
> > convinient. It would be the way to save a handful of annoyance. For example:
> >> > I'm not sure if any in particular really stand out to me. I might lean
> >> > towards $${expr} since I'm already used to seeing ${expr}. There's
> >> > also precedent to using two-character $ syntax with $!{expr} to
> >> > silence null exceptions.
> >> > On Dec 17, 9:54 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> >> > > Well the macro is more about a way to create helper-like functions
> >> > > with the spark dialect. Helps keep html concatination out of cs.
> >> > > But it is true if you add a base page class to a project you can add
> >> > > any functions like H() there - so that would probably be a better way
> >> > > to add ${L(...)}
> >> > > So only thing you'd save are the parens.
> >> > > On 12/17/08, Kevin Dente <kevinde...@gmail.com> wrote:
> >> > > > This *feels* very similar to the macro concept that's already there
> >> > > > (granted, I'm very new to Spark, so maybe I'm off-base here). Would
> >> it
> >> > > > make sense to extend the existing capability to support this kind of
> >> > > > macro expansion?
> >> > > > On Dec 17, 12:09 pm, Louis DeJardin <Louis.DeJar...@gmail.com>
> >> wrote:
> >> > > >> Probably would need to be in <spark> config or ISparkSettings for
> >> the
> >> > > >> settings to be available before the parse occurs. Which is a shame
> >> - I
> >> > > >> really like how putting <use namespace> and <use assembly> in
> >> > > >> _global.spark reduces dependency on web.config.
> >> > > >> Don't other things like partials and macros also affect the
> >> > > >> portability? If I have <rounded>stuff</rounded> that won't work
> >> > > >> without _rounded.spark.
> >> > > >> I agree config is suboptimal, and it does head down a configuration
> >> > > >> over convention path, but who can say what helpers are most useful.
> >> > > >> That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both
> >> > > >> supported - it's not that there's anything right or wrong about the
> >> > > >> alternatives and supporting both doesn't negatively impact either
> >> one.
> >> > > >> I'd lean more towards making it configurable than adding universal
> >> > > >> meaning to a number of different syntax.
> >> > > >> On the other hand it would be pretty easy to turn your spark files
> >> > > >> into a mass of unreadable shortcuts. Okay - how about moving away
> >> from
> >> > > >> the idea of using punctuation, and instead use small expansion
> >> marks
> >> > > >> that start with $...
> >> > > >> To encourage portability and convention you could provide a small
> >> set
> >> > > >> of compatible defaults for monorail and asp.net mvc, like the ones
> >> > > >> above. Configuration only needed to extend or modify defaults, if
> >> you
> >> > > >> never use them they won't affect anything, and still reads like ${}
> >> > > >> visually and hopefully more intuitive than punctuation.
> >> > > >> (Not trying to pitch the idea of course, just talking it through.)
> >> > > >> I wonder if you would apply the same idea to <%= %>?
> >> > > >> On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
> >> > > >> > I agree with Kevin that making something like that configurable
> >> would
> >> > > >> > hurt
> >> > > >> > the portability of the code. Not to mention the difficulty in
> >> having to
> >> > > >> > figure out the different syntax that someone is using when moving
> >> to a
> >> > > >> > new
> >> > > >> > code base.
> >> > > >> > Granted, it probably won't be a problem 90% of the time given
> >> that most
> >> > > >> > people won't change the defaults, but given that, why even make
> >> it an
> >> > > >> > option?
> >> > > >> > Again, I think it is too much risk for not much value. I'm fine
> >> with
> >> > > >> > ${H()}.
> >> > > >> > On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente <
> >> kevinde...@gmail.com>
> >> > > >> > wrote:
> >> > > >> > > Interesting idea. How would you envision the configurable
> >> prefixes
> >> > > >> > > being defined? In a config file? One concern would be
> >> portabillity of
> >> > > >> > > Spark pages across applications, if they each use their own
> >> prefix
> >> > > >> > > conventions.
> >> > > >> > > On Dec 17, 1:09 am, "Louis DeJardin" <louis.dejar...@gmail.com>
> >> wrote:
> >> > > >> > > > Nothing wrong with ${H(expr)} at all, and I wouldn't suggest
> >> the way
> >> > > >> > > > that works would change at all. It is an interesting point
> >> though
> >> > > >> > > > that
> >> > > >> > > > if you should html encode anything that doesn't explicitly
> >> contain
> >> > > >> > > > html, it does mean you have to opt-in to that behavior every
> >> time
> >> > > >> > > > you
> >> > > >> > > > surface a value.
> >> > > >> > > > Saves three whole keystrokes per field too. :)
> >> > > >> > > > Say! Along those lines (where a lot of this is personal
> >> preference)
> >> > > >> > > > what if it was configurable where different prefixes could
> >> have
> >> > > >> > > > defined wrapping code?
> >> > > >> > > > @ or ^ for H(...) would be one example, but another useful
> >> one could
> >> > > >> > > > be mapping some character like * to Html.ActionLink(...). So
> >> you
> >> > > >> > > > could
> >> > > >> > > > use syntax *{"click here", "index", "products"} as a shortcut
> >> to all
> >> > > >> > > > of the overloads of that particular helper? Never have to
> >> type
> >> > > >> > > > Html.ActionLink again.
I'm probably alone on this one, but I think I'd prefer something
completely *different* than ${} - $${} is similar enough that I could
see accidentally using ${} and not noticing. Of course, you have an
existing framework to fit this into, so if using a 2-character
expression fits the model better, I can understand that.
On Dec 17, 8:56 pm, Louis DeJardin <Louis.DeJar...@gmail.com> wrote:
> I'm not sure if any in particular really stand out to me. I might lean
> towards $${expr} since I'm already used to seeing ${expr}. There's
> also precedent to using two-character $ syntax with $!{expr} to
> silence null exceptions.
> On Dec 17, 9:54 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> > Well the macro is more about a way to create helper-like functions
> > with the spark dialect. Helps keep html concatination out of cs.
> > But it is true if you add a base page class to a project you can add
> > any functions like H() there - so that would probably be a better way
> > to add ${L(...)}
> > So only thing you'd save are the parens.
> > On 12/17/08, Kevin Dente <kevinde...@gmail.com> wrote:
> > > This *feels* very similar to the macro concept that's already there
> > > (granted, I'm very new to Spark, so maybe I'm off-base here). Would it
> > > make sense to extend the existing capability to support this kind of
> > > macro expansion?
> > > On Dec 17, 12:09 pm, Louis DeJardin <Louis.DeJar...@gmail.com> wrote:
> > >> Probably would need to be in <spark> config or ISparkSettings for the
> > >> settings to be available before the parse occurs. Which is a shame - I
> > >> really like how putting <use namespace> and <use assembly> in
> > >> _global.spark reduces dependency on web.config.
> > >> Don't other things like partials and macros also affect the
> > >> portability? If I have <rounded>stuff</rounded> that won't work
> > >> without _rounded.spark.
> > >> I agree config is suboptimal, and it does head down a configuration
> > >> over convention path, but who can say what helpers are most useful.
> > >> That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both
> > >> supported - it's not that there's anything right or wrong about the
> > >> alternatives and supporting both doesn't negatively impact either one.
> > >> I'd lean more towards making it configurable than adding universal
> > >> meaning to a number of different syntax.
> > >> On the other hand it would be pretty easy to turn your spark files
> > >> into a mass of unreadable shortcuts. Okay - how about moving away from
> > >> the idea of using punctuation, and instead use small expansion marks
> > >> that start with $...
> > >> To encourage portability and convention you could provide a small set
> > >> of compatible defaults for monorail and asp.net mvc, like the ones
> > >> above. Configuration only needed to extend or modify defaults, if you
> > >> never use them they won't affect anything, and still reads like ${}
> > >> visually and hopefully more intuitive than punctuation.
> > >> (Not trying to pitch the idea of course, just talking it through.)
> > >> I wonder if you would apply the same idea to <%= %>?
> > >> On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
> > >> > I agree with Kevin that making something like that configurable would
> > >> > hurt
> > >> > the portability of the code. Not to mention the difficulty in having to
> > >> > figure out the different syntax that someone is using when moving to a
> > >> > new
> > >> > code base.
> > >> > Granted, it probably won't be a problem 90% of the time given that most
> > >> > people won't change the defaults, but given that, why even make it an
> > >> > option?
> > >> > Again, I think it is too much risk for not much value. I'm fine with
> > >> > ${H()}.
> > >> > On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente <kevinde...@gmail.com>
> > >> > wrote:
> > >> > > Interesting idea. How would you envision the configurable prefixes
> > >> > > being defined? In a config file? One concern would be portabillity of
> > >> > > Spark pages across applications, if they each use their own prefix
> > >> > > conventions.
> > >> > > On Dec 17, 1:09 am, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> > >> > > > Nothing wrong with ${H(expr)} at all, and I wouldn't suggest the way
> > >> > > > that works would change at all. It is an interesting point though
> > >> > > > that
> > >> > > > if you should html encode anything that doesn't explicitly contain
> > >> > > > html, it does mean you have to opt-in to that behavior every time
> > >> > > > you
> > >> > > > surface a value.
> > >> > > > Saves three whole keystrokes per field too. :)
> > >> > > > Say! Along those lines (where a lot of this is personal preference)
> > >> > > > what if it was configurable where different prefixes could have
> > >> > > > defined wrapping code?
> > >> > > > @ or ^ for H(...) would be one example, but another useful one could
> > >> > > > be mapping some character like * to Html.ActionLink(...). So you
> > >> > > > could
> > >> > > > use syntax *{"click here", "index", "products"} as a shortcut to all
> > >> > > > of the overloads of that particular helper? Never have to type
> > >> > > > Html.ActionLink again.
> > >> > > > > I kind of liked @{ }, but +{ } is also good.
> > >> > > > > On Wed, Dec 17, 2008 at 5:24 AM, Chad Lee <chadl...@gmail.com>
> > >> > > > > wrote:
> > >> > > > >> What's wrong with the current way?
> > >> > > > >> ${H(myVar)}
> > >> > > > >> I don't see much value in adding a shortcut to this already short
> > >> > > method
> > >> > > > >> call.
> > >> > > > >> On Tue, Dec 16, 2008 at 10:21 PM, Kevin Dente
> > >> > > > >> <kevinde...@gmail.com>
> > >> > > > >> wrote:
> > >> > > > >>> Hmm, I'm kind of partial to ^{product.Name} myself, for some
> > >> > > > >>> reason.
> > >> > > > >>> But I'm cool either way. You're right that +{} is flows pretty
> > >> > > > >>> well
> > >> > > on
> > >> > > > >>> the keyboard.
> > >> > > > >>> On Dec 16, 1:14 pm, "Louis DeJardin" <louis.dejar...@gmail.com>
> > >> > > wrote:
> > >> > > > >>> > You're right it'd be impossible to add that directly to
> > >> > > > >>> > ${expr}
> > >> > > without
> > >> > > > >>> > making it impossible to send ${Html.ActionLink(...)}. I'd
> > >> > > > >>> > hesitate
> > >> > > to
> > >> > > > >>> > change
> > >> > > > >>> > the default behavior of ${expr} because it would be a breaking
> > >> > > change.
> > >> > > > >>> > We
> > >> > > > >>> > already had ?{cond} added when there was a compelling reason,
> > >> > > > >>> > so I
> > >> > > > >>> > could
> > >> > > > >>> > see
> > >> > > > >>> > this if there was a consensus.
> > >> > > > >>> > The #{expr} could collide with #statement if it was on the
> > >> > > > >>> > start of
> > >> > > a
> > >> > > > >>> > line,
> > >> > > > >>> > so I don't think that'll fly.
Personally, I like the idea of being able to define customised mark-
aliases. On top of that, to fit in with convention over
configuration, why not ship Spark with sensible-default ones already
defined? There would then be little need to customise them, but the
option would exist for special needs.
Here, I would be in favour of the breaking change of making ${} HTML-
encode by default. I read Rob Conery's blog post on the perfect storm
botnet, and was frankly aghast. Averting that possibility by default
is, to me, worth the pain of any breaking change.
The effect of the break could be mitigated by defining and release-
noting those sensible-defaults so developers know to use (for example)
$Uf{Url.For(blah)} to replace ${Url.For(blah)}, and so forth.
As an aside, I looked at the Brail docs to see how it handles this,
because I remember reading it way back and seeing something similar.
http://www.symbiotic-development.com/monorail/html/single/index.html#... is the relevant passage. It allows output methods to be defined much
like has been described here for ${H("foo")}.
> I'm probably alone on this one, but I think I'd prefer something
> completely *different* than ${} - $${} is similar enough that I could
> see accidentally using ${} and not noticing. Of course, you have an
> existing framework to fit this into, so if using a 2-character
> expression fits the model better, I can understand that.
> On Dec 17, 8:56 pm, Louis DeJardin <Louis.DeJar...@gmail.com> wrote:
> > Which brings us all the way back to the original suggestion! :)
> > How does double-dollar to htmlencode strike you?
> > I'm not sure if any in particular really stand out to me. I might lean
> > towards $${expr} since I'm already used to seeing ${expr}. There's
> > also precedent to using two-character $ syntax with $!{expr} to
> > silence null exceptions.
> > On Dec 17, 9:54 pm, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> > > Well the macro is more about a way to create helper-like functions
> > > with the spark dialect. Helps keep html concatination out of cs.
> > > But it is true if you add a base page class to a project you can add
> > > any functions like H() there - so that would probably be a better way
> > > to add ${L(...)}
> > > So only thing you'd save are the parens.
> > > On 12/17/08, Kevin Dente <kevinde...@gmail.com> wrote:
> > > > This *feels* very similar to the macro concept that's already there
> > > > (granted, I'm very new to Spark, so maybe I'm off-base here). Would it
> > > > make sense to extend the existing capability to support this kind of
> > > > macro expansion?
> > > > On Dec 17, 12:09 pm, Louis DeJardin <Louis.DeJar...@gmail.com> wrote:
> > > >> Probably would need to be in <spark> config or ISparkSettings for the
> > > >> settings to be available before the parse occurs. Which is a shame - I
> > > >> really like how putting <use namespace> and <use assembly> in
> > > >> _global.spark reduces dependency on web.config.
> > > >> Don't other things like partials and macros also affect the
> > > >> portability? If I have <rounded>stuff</rounded> that won't work
> > > >> without _rounded.spark.
> > > >> I agree config is suboptimal, and it does head down a configuration
> > > >> over convention path, but who can say what helpers are most useful.
> > > >> That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both
> > > >> supported - it's not that there's anything right or wrong about the
> > > >> alternatives and supporting both doesn't negatively impact either one.
> > > >> I'd lean more towards making it configurable than adding universal
> > > >> meaning to a number of different syntax.
> > > >> On the other hand it would be pretty easy to turn your spark files
> > > >> into a mass of unreadable shortcuts. Okay - how about moving away from
> > > >> the idea of using punctuation, and instead use small expansion marks
> > > >> that start with $...
> > > >> To encourage portability and convention you could provide a small set
> > > >> of compatible defaults for monorail and asp.net mvc, like the ones
> > > >> above. Configuration only needed to extend or modify defaults, if you
> > > >> never use them they won't affect anything, and still reads like ${}
> > > >> visually and hopefully more intuitive than punctuation.
> > > >> (Not trying to pitch the idea of course, just talking it through.)
> > > >> I wonder if you would apply the same idea to <%= %>?
> > > >> On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
> > > >> > I agree with Kevin that making something like that configurable would
> > > >> > hurt
> > > >> > the portability of the code. Not to mention the difficulty in having to
> > > >> > figure out the different syntax that someone is using when moving to a
> > > >> > new
> > > >> > code base.
> > > >> > Granted, it probably won't be a problem 90% of the time given that most
> > > >> > people won't change the defaults, but given that, why even make it an
> > > >> > option?
> > > >> > Again, I think it is too much risk for not much value. I'm fine with
> > > >> > ${H()}.
> > > >> > On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente <kevinde...@gmail.com>
> > > >> > wrote:
> > > >> > > Interesting idea. How would you envision the configurable prefixes
> > > >> > > being defined? In a config file? One concern would be portabillity of
> > > >> > > Spark pages across applications, if they each use their own prefix
> > > >> > > conventions.
> > > >> > > On Dec 17, 1:09 am, "Louis DeJardin" <louis.dejar...@gmail.com> wrote:
> > > >> > > > Nothing wrong with ${H(expr)} at all, and I wouldn't suggest the way
> > > >> > > > that works would change at all. It is an interesting point though
> > > >> > > > that
> > > >> > > > if you should html encode anything that doesn't explicitly contain
> > > >> > > > html, it does mean you have to opt-in to that behavior every time
> > > >> > > > you
> > > >> > > > surface a value.
> > > >> > > > Saves three whole keystrokes per field too. :)
> > > >> > > > Say! Along those lines (where a lot of this is personal preference)
> > > >> > > > what if it was configurable where different prefixes could have
> > > >> > > > defined wrapping code?
> > > >> > > > @ or ^ for H(...) would be one example, but another useful one could
> > > >> > > > be mapping some character like * to Html.ActionLink(...). So you
> > > >> > > > could
> > > >> > > > use syntax *{"click here", "index", "products"} as a shortcut to all
> > > >> > > > of the overloads of that particular helper? Never have to type
> > > >> > > > Html.ActionLink again.
As I understood, parsing and codegen is separated in time. You could parse fixed (on language level) amount of escape symbols as "macro alias X". And then, on codegen stage you could resolve X or throw exception if it could not be resolved.
On Thu, Dec 18, 2008 at 11:37 PM, Louis DeJardin <Louis.DeJar...@gmail.com>wrote:
> That would be nice but unfortunately it couldn't be defined inside of > the spark files because the information would need to be used by the > first stage parser. The breakdown of the files text happens before the > macros are known.
> On Dec 18, 12:23 pm, "Артём Тихомиров" <ar...@tikhomirovs.ru> wrote: > > Even for existing functions such as H it would be simple to create > > macro-wrappers:
> > On Thu, Dec 18, 2008 at 9:20 PM, Артём Тихомиров <ar...@tikhomirovs.ru > >wrote:
> > > I think that signs as alias for macro functions would be much more > > > convinient. It would be the way to save a handful of annoyance. For > example:
> > > You could parse such constructions as generic "alias constructions" and > > > resolve em in codegen time (sorry if I misunderstood Spark internals).
> > > On Thu, Dec 18, 2008 at 10:37 AM, subnus <sub...@gmail.com> wrote:
> > >> I think that the double-dollar way is the way to go
> > >> On Dec 18, 5:56 am, Louis DeJardin <Louis.DeJar...@gmail.com> wrote: > > >> > Which brings us all the way back to the original suggestion! :)
> > >> > How does double-dollar to htmlencode strike you?
> > >> > I'm not sure if any in particular really stand out to me. I might > lean > > >> > towards $${expr} since I'm already used to seeing ${expr}. There's > > >> > also precedent to using two-character $ syntax with $!{expr} to > > >> > silence null exceptions.
> > >> > On Dec 17, 9:54 pm, "Louis DeJardin" <louis.dejar...@gmail.com> > wrote:
> > >> > > Well the macro is more about a way to create helper-like functions > > >> > > with the spark dialect. Helps keep html concatination out of cs.
> > >> > > But it is true if you add a base page class to a project you can > add > > >> > > any functions like H() there - so that would probably be a better > way > > >> > > to add ${L(...)}
> > >> > > So only thing you'd save are the parens.
> > >> > > On 12/17/08, Kevin Dente <kevinde...@gmail.com> wrote:
> > >> > > > This *feels* very similar to the macro concept that's already > there > > >> > > > (granted, I'm very new to Spark, so maybe I'm off-base here). > Would > > >> it > > >> > > > make sense to extend the existing capability to support this > kind of > > >> > > > macro expansion?
> > >> > > > On Dec 17, 12:09 pm, Louis DeJardin <Louis.DeJar...@gmail.com> > > >> wrote: > > >> > > >> Probably would need to be in <spark> config or ISparkSettings > for > > >> the > > >> > > >> settings to be available before the parse occurs. Which is a > shame > > >> - I > > >> > > >> really like how putting <use namespace> and <use assembly> in > > >> > > >> _global.spark reduces dependency on web.config.
> > >> > > >> Don't other things like partials and macros also affect the > > >> > > >> portability? If I have <rounded>stuff</rounded> that won't work > > >> > > >> without _rounded.spark.
> > >> > > >> I agree config is suboptimal, and it does head down a > configuration > > >> > > >> over convention path, but who can say what helpers are most > useful. > > >> > > >> That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both > > >> > > >> supported - it's not that there's anything right or wrong about > the > > >> > > >> alternatives and supporting both doesn't negatively impact > either > > >> one.
> > >> > > >> I'd lean more towards making it configurable than adding > universal > > >> > > >> meaning to a number of different syntax.
> > >> > > >> On the other hand it would be pretty easy to turn your spark > files > > >> > > >> into a mass of unreadable shortcuts. Okay - how about moving > away > > >> from > > >> > > >> the idea of using punctuation, and instead use small expansion > > >> marks > > >> > > >> that start with $...
> > >> > > >> To encourage portability and convention you could provide a > small > > >> set > > >> > > >> of compatible defaults for monorail and asp.net mvc, like the > ones > > >> > > >> above. Configuration only needed to extend or modify defaults, > if > > >> you > > >> > > >> never use them they won't affect anything, and still reads like > ${} > > >> > > >> visually and hopefully more intuitive than punctuation.
> > >> > > >> (Not trying to pitch the idea of course, just talking it > through.)
> > >> > > >> I wonder if you would apply the same idea to <%= %>?
> > >> > > >> On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
> > >> > > >> > I agree with Kevin that making something like that > configurable > > >> would > > >> > > >> > hurt > > >> > > >> > the portability of the code. Not to mention the difficulty > in > > >> having to > > >> > > >> > figure out the different syntax that someone is using when > moving > > >> to a > > >> > > >> > new > > >> > > >> > code base.
> > >> > > >> > Granted, it probably won't be a problem 90% of the time given > > >> that most > > >> > > >> > people won't change the defaults, but given that, why even > make > > >> it an > > >> > > >> > option?
> > >> > > >> > Again, I think it is too much risk for not much value. I'm > fine > > >> with > > >> > > >> > ${H()}.
> > >> > > >> > On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente < > > >> kevinde...@gmail.com> > > >> > > >> > wrote:
> > >> > > >> > > Interesting idea. How would you envision the configurable > > >> prefixes > > >> > > >> > > being defined? In a config file? One concern would be > > >> portabillity of > > >> > > >> > > Spark pages across applications, if they each use their own > > >> prefix > > >> > > >> > > conventions.
> > >> > > >> > > On Dec 17, 1:09 am, "Louis DeJardin" < > louis.dejar...@gmail.com> > > >> wrote: > > >> > > >> > > > Nothing wrong with ${H(expr)} at all, and I wouldn't > suggest > > >> the way > > >> > > >> > > > that works would change at all. It is an interesting > point > > >> though > > >> > > >> > > > that > > >> > > >> > > > if you should html encode anything that doesn't > explicitly > > >> contain > > >> > > >> > > > html, it does mean you have to opt-in to that behavior > every > > >> time > > >> > > >> > > > you > > >> > > >> > > > surface a value.
> > >> > > >> > > > Saves three whole keystrokes per field too. :)
> > >> > > >> > > > Say! Along those lines (where a lot of this is personal > > >> preference) > > >> > > >> > > > what if it was configurable where different prefixes > could > > >> have > > >> > > >> > > > defined wrapping code?
> > >> > > >> > > > @ or ^ for H(...) would be one example, but another > useful > > >> one could > > >> > > >> > > > be mapping some character like * to Html.ActionLink(...). > So > > >> you > > >> > > >> > > > could > > >> > > >> > > > use syntax *{"click here", "index", "products"} as a > shortcut > > >> to all > > >> > > >> > > > of the overloads of that particular helper? Never have to > > >> type > > >> > > >> > > > Html.ActionLink again.
Well, if there would be a breaking change I'd say the sooner the better. It'd probably be a good idea to provide a config switch to disable html.encode for transition or personal preference. So looking at it from the other direction how about !{ } or $${ } for unencoded output?
${expr} Output.Write(H(expr));
!{expr} or $${expr} Output.Write(expr);
!{expr} might work well... Draws your attention to the fact you're opting into writing out raw (!) html. Also fits with the punctuation-ness of ?{cond}. Not sure if $${} would be needed. Any thoughts?
Like Артём mentioned you could make the assumption any $X{foo} would turn into Output.Write(X.foo); and let the compiler throw errors if X didn't mean anything.
That said, to me $Html{ActionLink("foo", "bar")} is less readable than !{Html.ActionLink("foo", "bar")} and not any shorter. If there was anything along those lines I'd probably still prefer something configurable like $H{ActionLink("foo", "bar")} or $Link{"foo", "bar"}.
On Sun, Dec 21, 2008 at 8:13 AM, Артём Тихомиров <ar...@tikhomirovs.ru>wrote:
> As I understood, parsing and codegen is separated in time. You could parse > fixed (on language level) amount of escape symbols as "macro alias X". And > then, on codegen stage you could resolve X or throw exception if it could > not be resolved.
> On Thu, Dec 18, 2008 at 11:37 PM, Louis DeJardin <Louis.DeJar...@gmail.com > > wrote:
>> That would be nice but unfortunately it couldn't be defined inside of >> the spark files because the information would need to be used by the >> first stage parser. The breakdown of the files text happens before the >> macros are known.
>> On Dec 18, 12:23 pm, "Артём Тихомиров" <ar...@tikhomirovs.ru> wrote: >> > Even for existing functions such as H it would be simple to create >> > macro-wrappers:
>> > On Thu, Dec 18, 2008 at 9:20 PM, Артём Тихомиров <ar...@tikhomirovs.ru >> >wrote:
>> > > I think that signs as alias for macro functions would be much more >> > > convinient. It would be the way to save a handful of annoyance. For >> example:
>> > > You could parse such constructions as generic "alias constructions" >> and >> > > resolve em in codegen time (sorry if I misunderstood Spark internals).
>> > > On Thu, Dec 18, 2008 at 10:37 AM, subnus <sub...@gmail.com> wrote:
>> > >> I think that the double-dollar way is the way to go
>> > >> On Dec 18, 5:56 am, Louis DeJardin <Louis.DeJar...@gmail.com> wrote: >> > >> > Which brings us all the way back to the original suggestion! :)
>> > >> > How does double-dollar to htmlencode strike you?
>> > >> > I'm not sure if any in particular really stand out to me. I might >> lean >> > >> > towards $${expr} since I'm already used to seeing ${expr}. There's >> > >> > also precedent to using two-character $ syntax with $!{expr} to >> > >> > silence null exceptions.
>> > >> > On Dec 17, 9:54 pm, "Louis DeJardin" <louis.dejar...@gmail.com> >> wrote:
>> > >> > > Well the macro is more about a way to create helper-like >> functions >> > >> > > with the spark dialect. Helps keep html concatination out of cs.
>> > >> > > But it is true if you add a base page class to a project you can >> add >> > >> > > any functions like H() there - so that would probably be a better >> way >> > >> > > to add ${L(...)}
>> > >> > > So only thing you'd save are the parens.
>> > >> > > On 12/17/08, Kevin Dente <kevinde...@gmail.com> wrote:
>> > >> > > > This *feels* very similar to the macro concept that's already >> there >> > >> > > > (granted, I'm very new to Spark, so maybe I'm off-base here). >> Would >> > >> it >> > >> > > > make sense to extend the existing capability to support this >> kind of >> > >> > > > macro expansion?
>> > >> > > > On Dec 17, 12:09 pm, Louis DeJardin <Louis.DeJar...@gmail.com> >> > >> wrote: >> > >> > > >> Probably would need to be in <spark> config or ISparkSettings >> for >> > >> the >> > >> > > >> settings to be available before the parse occurs. Which is a >> shame >> > >> - I >> > >> > > >> really like how putting <use namespace> and <use assembly> in >> > >> > > >> _global.spark reduces dependency on web.config.
>> > >> > > >> Don't other things like partials and macros also affect the >> > >> > > >> portability? If I have <rounded>stuff</rounded> that won't >> work >> > >> > > >> without _rounded.spark.
>> > >> > > >> I agree config is suboptimal, and it does head down a >> configuration >> > >> > > >> over convention path, but who can say what helpers are most >> useful. >> > >> > > >> That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both >> > >> > > >> supported - it's not that there's anything right or wrong >> about the >> > >> > > >> alternatives and supporting both doesn't negatively impact >> either >> > >> one.
>> > >> > > >> I'd lean more towards making it configurable than adding >> universal >> > >> > > >> meaning to a number of different syntax.
>> > >> > > >> On the other hand it would be pretty easy to turn your spark >> files >> > >> > > >> into a mass of unreadable shortcuts. Okay - how about moving >> away >> > >> from >> > >> > > >> the idea of using punctuation, and instead use small expansion >> > >> marks >> > >> > > >> that start with $...
>> > >> > > >> To encourage portability and convention you could provide a >> small >> > >> set >> > >> > > >> of compatible defaults for monorail and asp.net mvc, like the >> ones >> > >> > > >> above. Configuration only needed to extend or modify defaults, >> if >> > >> you >> > >> > > >> never use them they won't affect anything, and still reads >> like ${} >> > >> > > >> visually and hopefully more intuitive than punctuation.
>> > >> > > >> (Not trying to pitch the idea of course, just talking it >> through.)
>> > >> > > >> I wonder if you would apply the same idea to <%= %>?
>> > >> > > >> On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
>> > >> > > >> > I agree with Kevin that making something like that >> configurable >> > >> would >> > >> > > >> > hurt >> > >> > > >> > the portability of the code. Not to mention the difficulty >> in >> > >> having to >> > >> > > >> > figure out the different syntax that someone is using when >> moving >> > >> to a >> > >> > > >> > new >> > >> > > >> > code base.
>> > >> > > >> > Granted, it probably won't be a problem 90% of the time >> given >> > >> that most >> > >> > > >> > people won't change the defaults, but given that, why even >> make >> > >> it an >> > >> > > >> > option?
>> > >> > > >> > Again, I think it is too much risk for not much value. I'm >> fine >> > >> with >> > >> > > >> > ${H()}.
>> > >> > > >> > On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente < >> > >> kevinde...@gmail.com> >> > >> > > >> > wrote:
>> > >> > > >> > > Interesting idea. How would you envision the configurable >> > >> prefixes >> > >> > > >> > > being defined? In a config file? One concern would be >> > >> portabillity of >> > >> > > >> > > Spark pages across applications, if they each use their >> own >> > >> prefix >> > >> > > >> > > conventions.
>> > >> > > >> > > On Dec 17, 1:09 am, "Louis DeJardin" < >> louis.dejar...@gmail.com> >> > >> wrote: >> > >> > > >> > > > Nothing wrong with ${H(expr)} at all, and I wouldn't >> suggest >> > >> the way >> > >> > > >> > > > that works would change at all. It is an interesting >> point >> > >> though >> > >> > > >> > > > that >> > >> > > >> > > > if you should html encode anything that doesn't >> explicitly >> > >> contain >> > >> > > >> > > > html, it does mean you have to opt-in to that behavior >> every >> > >> time >> > >> > > >> > > > you >> > >> > > >> > > > surface a value.
>> > >> > > >> > > > Saves three whole keystrokes per field too. :)
>> > >> > > >> > > > Say! Along those lines (where a lot of this is personal >> > >> preference) >> > >> > > >> > > > what if it was configurable where different prefixes >> could >> > >> have >> > >> > > >> > > > defined wrapping code?
>> > >> > > >> > > > @ or ^ for H(...) would be one example, but another >> useful >> > >> one could >> > >> > > >> > > > be mapping some character like * to >> Html.ActionLink(...). So >> > >> you >> > >> > > >> > > > could >> > >> > > >> > > > use syntax *{"click here", "index", "products"} as a >> shortcut >> > >> to all >> > >> > > >> > > > of the overloads
> Well, if there would be a breaking change I'd say the sooner the better. > It'd probably be a good idea to provide a config switch to disable > html.encode for transition or personal preference. So looking at it from the > other direction how about !{ } or $${ } for unencoded output?
> ${expr} > Output.Write(H(expr));
> !{expr} or $${expr} > Output.Write(expr);
> !{expr} might work well... Draws your attention to the fact you're opting > into writing out raw (!) html. Also fits with the punctuation-ness of > ?{cond}. Not sure if $${} would be needed. Any thoughts?
> Like Артём mentioned you could make the assumption any $X{foo} would turn > into Output.Write(X.foo); and let the compiler throw errors if X didn't mean > anything.
> That said, to me $Html{ActionLink("foo", "bar")} is less readable than > !{Html.ActionLink("foo", "bar")} and not any shorter. If there was anything > along those lines I'd probably still prefer something configurable like > $H{ActionLink("foo", "bar")} or $Link{"foo", "bar"}.
> On Sun, Dec 21, 2008 at 8:13 AM, Артём Тихомиров <ar...@tikhomirovs.ru>wrote:
>> As I understood, parsing and codegen is separated in time. You could parse >> fixed (on language level) amount of escape symbols as "macro alias X". And >> then, on codegen stage you could resolve X or throw exception if it could >> not be resolved.
>> On Thu, Dec 18, 2008 at 11:37 PM, Louis DeJardin < >> Louis.DeJar...@gmail.com> wrote:
>>> That would be nice but unfortunately it couldn't be defined inside of >>> the spark files because the information would need to be used by the >>> first stage parser. The breakdown of the files text happens before the >>> macros are known.
>>> On Dec 18, 12:23 pm, "Артём Тихомиров" <ar...@tikhomirovs.ru> wrote: >>> > Even for existing functions such as H it would be simple to create >>> > macro-wrappers:
>>> > On Thu, Dec 18, 2008 at 9:20 PM, Артём Тихомиров <ar...@tikhomirovs.ru >>> >wrote:
>>> > > I think that signs as alias for macro functions would be much more >>> > > convinient. It would be the way to save a handful of annoyance. For >>> example:
>>> > > You could parse such constructions as generic "alias constructions" >>> and >>> > > resolve em in codegen time (sorry if I misunderstood Spark >>> internals).
>>> > > On Thu, Dec 18, 2008 at 10:37 AM, subnus <sub...@gmail.com> wrote:
>>> > >> I think that the double-dollar way is the way to go
>>> > >> On Dec 18, 5:56 am, Louis DeJardin <Louis.DeJar...@gmail.com> >>> wrote: >>> > >> > Which brings us all the way back to the original suggestion! :)
>>> > >> > How does double-dollar to htmlencode strike you?
>>> > >> > I'm not sure if any in particular really stand out to me. I might >>> lean >>> > >> > towards $${expr} since I'm already used to seeing ${expr}. There's >>> > >> > also precedent to using two-character $ syntax with $!{expr} to >>> > >> > silence null exceptions.
>>> > >> > On Dec 17, 9:54 pm, "Louis DeJardin" <louis.dejar...@gmail.com> >>> wrote:
>>> > >> > > Well the macro is more about a way to create helper-like >>> functions >>> > >> > > with the spark dialect. Helps keep html concatination out of cs.
>>> > >> > > But it is true if you add a base page class to a project you can >>> add >>> > >> > > any functions like H() there - so that would probably be a >>> better way >>> > >> > > to add ${L(...)}
>>> > >> > > So only thing you'd save are the parens.
>>> > >> > > On 12/17/08, Kevin Dente <kevinde...@gmail.com> wrote:
>>> > >> > > > This *feels* very similar to the macro concept that's already >>> there >>> > >> > > > (granted, I'm very new to Spark, so maybe I'm off-base here). >>> Would >>> > >> it >>> > >> > > > make sense to extend the existing capability to support this >>> kind of >>> > >> > > > macro expansion?
>>> > >> > > > On Dec 17, 12:09 pm, Louis DeJardin <Louis.DeJar...@gmail.com
>>> > >> wrote: >>> > >> > > >> Probably would need to be in <spark> config or ISparkSettings >>> for >>> > >> the >>> > >> > > >> settings to be available before the parse occurs. Which is a >>> shame >>> > >> - I >>> > >> > > >> really like how putting <use namespace> and <use assembly> in >>> > >> > > >> _global.spark reduces dependency on web.config.
>>> > >> > > >> Don't other things like partials and macros also affect the >>> > >> > > >> portability? If I have <rounded>stuff</rounded> that won't >>> work >>> > >> > > >> without _rounded.spark.
>>> > >> > > >> I agree config is suboptimal, and it does head down a >>> configuration >>> > >> > > >> over convention path, but who can say what helpers are most >>> useful. >>> > >> > > >> That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are >>> both >>> > >> > > >> supported - it's not that there's anything right or wrong >>> about the >>> > >> > > >> alternatives and supporting both doesn't negatively impact >>> either >>> > >> one.
>>> > >> > > >> I'd lean more towards making it configurable than adding >>> universal >>> > >> > > >> meaning to a number of different syntax.
>>> > >> > > >> On the other hand it would be pretty easy to turn your spark >>> files >>> > >> > > >> into a mass of unreadable shortcuts. Okay - how about moving >>> away >>> > >> from >>> > >> > > >> the idea of using punctuation, and instead use small >>> expansion >>> > >> marks >>> > >> > > >> that start with $...
>>> > >> > > >> To encourage portability and convention you could provide a >>> small >>> > >> set >>> > >> > > >> of compatible defaults for monorail and asp.net mvc, like >>> the ones >>> > >> > > >> above. Configuration only needed to extend or modify >>> defaults, if >>> > >> you >>> > >> > > >> never use them they won't affect anything, and still reads >>> like ${} >>> > >> > > >> visually and hopefully more intuitive than punctuation.
>>> > >> > > >> (Not trying to pitch the idea of course, just talking it >>> through.)
>>> > >> > > >> I wonder if you would apply the same idea to <%= %>?
>>> > >> > > >> On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
>>> > >> > > >> > I agree with Kevin that making something like that >>> configurable >>> > >> would >>> > >> > > >> > hurt >>> > >> > > >> > the portability of the code. Not to mention the difficulty >>> in >>> > >> having to >>> > >> > > >> > figure out the different syntax that someone is using when >>> moving >>> > >> to a >>> > >> > > >> > new >>> > >> > > >> > code base.
>>> > >> > > >> > Granted, it probably won't be a problem 90% of the time >>> given >>> > >> that most >>> > >> > > >> > people won't change the defaults, but given that, why even >>> make >>> > >> it an >>> > >> > > >> > option?
>>> > >> > > >> > Again, I think it is too much risk for not much value. I'm >>> fine >>> > >> with >>> > >> > > >> > ${H()}.
>>> > >> > > >> > On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente < >>> > >> kevinde...@gmail.com> >>> > >> > > >> > wrote:
>>> > >> > > >> > > Interesting idea. How would you envision the configurable >>> > >> prefixes >>> > >> > > >> > > being defined? In a config file? One concern would be >>> > >> portabillity of >>> > >> > > >> > > Spark pages across applications, if they each use their >>> own >>> > >> prefix >>> > >> > > >> > > conventions.
>>> > >> > > >> > > On Dec 17, 1:09 am, "Louis DeJardin" < >>> louis.dejar...@gmail.com> >>> > >> wrote: >>> > >> > > >> > > > Nothing wrong with ${H(expr)} at all, and I wouldn't >>> suggest >>> > >> the way >>> > >> > > >> > > > that works would change at all. It is an interesting >>> point >>> > >> though >>> > >> > > >> > > > that >>> > >> > > >> > > > if you should html encode anything that doesn't >>> explicitly >>> > >> contain >>> > >> > > >> > > > html, it does mean you have to opt-in to that behavior >>> every >>> > >> time >>> > >> > > >> > > > you >>> > >> > > >> > > > surface a value.
>>> > >> > > >> > > > Saves three whole keystrokes per field
> Well, if there would be a breaking change I'd say the sooner the better.
> It'd probably be a good idea to provide a config switch to disable
> html.encode for transition or personal preference. So looking at it from the
> other direction how about !{ } or $${ } for unencoded output?
> ${expr}
> Output.Write(H(expr));
> !{expr} or $${expr}
> Output.Write(expr);
> !{expr} might work well... Draws your attention to the fact you're opting
> into writing out raw (!) html. Also fits with the punctuation-ness of
> ?{cond}. Not sure if $${} would be needed. Any thoughts?
> Like Артём mentioned you could make the assumption any $X{foo} would turn
> into Output.Write(X.foo); and let the compiler throw errors if X didn't mean
> anything.
> That said, to me $Html{ActionLink("foo", "bar")} is less readable than
> !{Html.ActionLink("foo", "bar")} and not any shorter. If there was anything
> along those lines I'd probably still prefer something configurable like
> $H{ActionLink("foo", "bar")} or $Link{"foo", "bar"}.
> On Sun, Dec 21, 2008 at 8:13 AM, Артём Тихомиров <ar...@tikhomirovs.ru>wrote:
> > As I understood, parsing and codegen is separated in time. You could parse
> > fixed (on language level) amount of escape symbols as "macro alias X". And
> > then, on codegen stage you could resolve X or throw exception if it could
> > not be resolved.
> > On Thu, Dec 18, 2008 at 11:37 PM, Louis DeJardin <Louis.DeJar...@gmail.com
> > > wrote:
> >> That would be nice but unfortunately it couldn't be defined inside of
> >> the spark files because the information would need to be used by the
> >> first stage parser. The breakdown of the files text happens before the
> >> macros are known.
> >> On Dec 18, 12:23 pm, "Артём Тихомиров" <ar...@tikhomirovs.ru> wrote:
> >> > Even for existing functions such as H it would be simple to create
> >> > macro-wrappers:
> >> > On Thu, Dec 18, 2008 at 9:20 PM, Артём Тихомиров <ar...@tikhomirovs.ru
> >> >wrote:
> >> > > I think that signs as alias for macro functions would be much more
> >> > > convinient. It would be the way to save a handful of annoyance. For
> >> example:
> >> > > You could parse such constructions as generic "alias constructions"
> >> and
> >> > > resolve em in codegen time (sorry if I misunderstood Spark internals).
> >> > > On Thu, Dec 18, 2008 at 10:37 AM, subnus <sub...@gmail.com> wrote:
> >> > >> I think that the double-dollar way is the way to go
> >> > >> On Dec 18, 5:56 am, Louis DeJardin <Louis.DeJar...@gmail.com> wrote:
> >> > >> > Which brings us all the way back to the original suggestion! :)
> >> > >> > How does double-dollar to htmlencode strike you?
> >> > >> > I'm not sure if any in particular really stand out to me. I might
> >> lean
> >> > >> > towards $${expr} since I'm already used to seeing ${expr}. There's
> >> > >> > also precedent to using two-character $ syntax with $!{expr} to
> >> > >> > silence null exceptions.
> >> > >> > On Dec 17, 9:54 pm, "Louis DeJardin" <louis.dejar...@gmail.com>
> >> wrote:
> >> > >> > > Well the macro is more about a way to create helper-like
> >> functions
> >> > >> > > with the spark dialect. Helps keep html concatination out of cs.
> >> > >> > > But it is true if you add a base page class to a project you can
> >> add
> >> > >> > > any functions like H() there - so that would probably be a better
> >> way
> >> > >> > > to add ${L(...)}
> >> > >> > > So only thing you'd save are the parens.
> >> > >> > > On 12/17/08, Kevin Dente <kevinde...@gmail.com> wrote:
> >> > >> > > > This *feels* very similar to the macro concept that's already
> >> there
> >> > >> > > > (granted, I'm very new to Spark, so maybe I'm off-base here).
> >> Would
> >> > >> it
> >> > >> > > > make sense to extend the existing capability to support this
> >> kind of
> >> > >> > > > macro expansion?
> >> > >> > > > On Dec 17, 12:09 pm, Louis DeJardin <Louis.DeJar...@gmail.com>
> >> > >> wrote:
> >> > >> > > >> Probably would need to be in <spark> config or ISparkSettings
> >> for
> >> > >> the
> >> > >> > > >> settings to be available before the parse occurs. Which is a
> >> shame
> >> > >> - I
> >> > >> > > >> really like how putting <use namespace> and <use assembly> in
> >> > >> > > >> _global.spark reduces dependency on web.config.
> >> > >> > > >> Don't other things like partials and macros also affect the
> >> > >> > > >> portability? If I have <rounded>stuff</rounded> that won't
> >> work
> >> > >> > > >> without _rounded.spark.
> >> > >> > > >> I agree config is suboptimal, and it does head down a
> >> configuration
> >> > >> > > >> over convention path, but who can say what helpers are most
> >> useful.
> >> > >> > > >> That's why ${expr} and <%=expr%>, #stmt and <%stmt%>, are both
> >> > >> > > >> supported - it's not that there's anything right or wrong
> >> about the
> >> > >> > > >> alternatives and supporting both doesn't negatively impact
> >> either
> >> > >> one.
> >> > >> > > >> I'd lean more towards making it configurable than adding
> >> universal
> >> > >> > > >> meaning to a number of different syntax.
> >> > >> > > >> On the other hand it would be pretty easy to turn your spark
> >> files
> >> > >> > > >> into a mass of unreadable shortcuts. Okay - how about moving
> >> away
> >> > >> from
> >> > >> > > >> the idea of using punctuation, and instead use small expansion
> >> > >> marks
> >> > >> > > >> that start with $...
> >> > >> > > >> To encourage portability and convention you could provide a
> >> small
> >> > >> set
> >> > >> > > >> of compatible defaults for monorail and asp.net mvc, like the
> >> ones
> >> > >> > > >> above. Configuration only needed to extend or modify defaults,
> >> if
> >> > >> you
> >> > >> > > >> never use them they won't affect anything, and still reads
> >> like ${}
> >> > >> > > >> visually and hopefully more intuitive than punctuation.
> >> > >> > > >> (Not trying to pitch the idea of course, just talking it
> >> through.)
> >> > >> > > >> I wonder if you would apply the same idea to <%= %>?
> >> > >> > > >> On Dec 17, 1:05 pm, "Chad Lee" <chadl...@gmail.com> wrote:
> >> > >> > > >> > I agree with Kevin that making something like that
> >> configurable
> >> > >> would
> >> > >> > > >> > hurt
> >> > >> > > >> > the portability of the code. Not to mention the difficulty
> >> in
> >> > >> having to
> >> > >> > > >> > figure out the different syntax that someone is using when
> >> moving
> >> > >> to a
> >> > >> > > >> > new
> >> > >> > > >> > code base.
> >> > >> > > >> > Granted, it probably won't be a problem 90% of the time
> >> given
> >> > >> that most
> >> > >> > > >> > people won't change the defaults, but given that, why even
> >> make
> >> > >> it an
> >> > >> > > >> > option?
> >> > >> > > >> > Again, I think it is too much risk for not much value. I'm
> >> fine
> >> > >> with
> >> > >> > > >> > ${H()}.
> >> > >> > > >> > On Wed, Dec 17, 2008 at 12:48 PM, Kevin Dente <
> >> > >> kevinde...@gmail.com>
> >> > >> > > >> > wrote:
> >> > >> > > >> > > Interesting idea. How would you envision the configurable
> >> > >> prefixes
> >> > >> > > >> > > being defined? In a config file? One concern would be
> >> > >> portabillity of
> >> > >> > > >> > > Spark pages across applications, if they each use their
> >> own
> >> > >> prefix
> >> > >> > > >> > > conventions.
> >> > >> > > >> > > On Dec 17, 1:09 am, "Louis DeJardin" <
> >> louis.dejar...@gmail.com>
> >> > >> wrote:
> >> > >> > > >> > > > Nothing wrong with ${H(expr)} at all, and I wouldn't
> >> suggest
> >> > >> the way
> >> > >> > > >> > > > that works would change at all. It is an interesting
> >> point
> >> > >> though
> >> > >> > > >> > > > that
> >> > >> > > >> > > > if you should html encode anything that doesn't
> >> explicitly
> >> > >> contain
> >> > >> > > >> > > > html, it does mean you have to opt-in to that behavior
> >> every
> >> > >> time
|
