Loading ...
Sorry, an error occurred while loading the content.

144Re: [caplet] Fwd: [Caja] secure string interpolation in javascript

Expand Messages
  • Mike Samuel
    Jan 30, 2008
      On 30/01/2008, Freeman, Tim <tim.freeman@...> wrote:
      >
      >
      >
      >
      >
      >
      >
      > Seems like a good idea.
      >
      > As a user, I'd rather see the SQL problem solved right by having a parser that's more sophisticated than a finite state machine than to not have it solved right.

      Fair enough. It's tough to implement sophisticated and efficient
      parsers in javascript, but I'm sure that it's worthwhile in some
      contexts.

      Perhaps if StringInterpolation.interpolate instead of taking a
      contextScanner and an escaper published events like ('Literal, "foo")
      or ('Substitution bar) to an interpolationEventSink then the current
      contextScanner&escaper could be built on top of it, or an
      implementation could route those events to an AST builder instead.


      > In the paper, every result from Template is immediately passed to open. Did I miss one? If not, then why make people write both? I'd expect to have "openedTemplate(...blah...)" as an abbreviation for "open(Template(...blah...))", although maybe a name shorter than "openedTemplate" should be selected.

      You didn't miss anything. This is an implementation detail leaking
      out through the API.

      The `Template` part converts the "Hello $name_of_planet!" to "new
      StringInterpolation(['Hello ', name_of_planet, '!'])" and the `open`
      part is really `eval` in disguise which parses the string and invokes
      the constructor. Thus, two function calls are needed for this macro
      expansion to work in javascript.


      > -----
      > Tim Freeman
      > Email: tim.freeman@...
      > Desk in Palo Alto: (650) 857-2581
      > Home: (408) 774-1298
      > Cell: (408) 348-7536
    • Show all 6 messages in this topic