4 ms·

Not sure but this might indeed fail. Can you place an issue to github? Thanks! Maybe it's good to split HTML and JS with the last HTML tag.

curveship 12y ago
Confirmed. Just take the demo app and insert the line 'this is some text.' anywhere in it. It looks like it's particularly bad if you put it into a nested element: the compiler treats everything after the line (including html markup) as javascript.
curveship 12y ago
The compiler also fails if a multi-line comment doesn't end at the end of a line.  and more text It outputs an empty compiled file. My honest opinion is that you should consider rewriting the compiler in a classic tokenize-parse-compile style. Several projects (like mustache.js) have had to go through this evolution. Your current solution -- line-by-line with regexes and state flags -- will only get hairier and hairier.
- tipiirai 12y ago
  I'm aware of this. Just wanting to avoid going there at this point and hoping that a smaller regex- based thing can do it.
- gosukiwi 12y ago
  Well, maybe a line-by-line solution is good enough, I mean, it would only target a subset but the code will be readable. I still think though that any compiler which is intended for real apps should do the classic tokenize-parse-compile steps.
  - tipiirai 12y ago
    I'll start by improving the current implementation and see how far I can go with it without making it crazy. I'll start tokenizing after a concrete use case. Definitely keep this in mind. Thanks!
curveship 12y ago
Issues logged for this, the multi-line comment termination issue, and for treating any line that ends with')' or '}' as javascript.
evmar 12y ago
Idea: require a <script> tag around the JS in the template (but just for your parser's benefit, not as a tag you intend to embed literally in the rendered DOM -- you can remove it at parse time as necessary). This has the nice side benefit that it will make editors happy. (E.g. emacs recognizes <script> tags within HTML and does JS highlighting/indenting on their content.)
- roller 12y ago
  This seems like a great idea, even if it's just optional tags that get ignored. With <script> you suddenly have a valid html fragment that should work with any editor. I guess as is, a make could include a grep -v </?script> step.
- fineline 12y ago
  Agree, removing the need for any special editor support would be great, even if offered as a compiler option. Makes the detection of JS a non-issue too.
- tipiirai 12y ago
  I can clearly see the benefits here. I'm also resistant to it because of the added syntax. Deciding later :)
  - jbellsey 12y ago
    The idea of having integrated components (HTML+JS) is certainly interesting and forward-thinking. However, I hope it doesn't lead you to limit us to the integrated style, by making the Riot compiler a required build step. Personally, I greatly prefer the direct coding style, i.e., riot.tag(). Not only because of the editor issues mentioned here, but because I can include my own modules in my scripts. I.e., can I use require() inside a Riot-compiled module? Stuff starts getting very hoop-jumpy once you start creating your own compiler & syntax, and bringing too much "magic" to the table. One of the big appeals of Riot is how UN-magical it is!

curveship 12y ago

Confirmed. Just take the demo app and insert the line 'this is some text.' anywhere in it. It looks like it's particularly bad if you put it into a nested element: the compiler treats everything after the line (including html markup) as javascript.

curveship 12y ago

The compiler also fails if a multi-line comment doesn't end at the end of a line.  and more text It outputs an empty compiled file. My honest opinion is that you should consider rewriting the compiler in a classic tokenize-parse-compile style. Several projects (like mustache.js) have had to go through this evolution. Your current solution -- line-by-line with regexes and state flags -- will only get hairier and hairier.

tipiirai 12y ago
I'm aware of this. Just wanting to avoid going there at this point and hoping that a smaller regex- based thing can do it.
gosukiwi 12y ago
Well, maybe a line-by-line solution is good enough, I mean, it would only target a subset but the code will be readable. I still think though that any compiler which is intended for real apps should do the classic tokenize-parse-compile steps.
- tipiirai 12y ago
  I'll start by improving the current implementation and see how far I can go with it without making it crazy. I'll start tokenizing after a concrete use case. Definitely keep this in mind. Thanks!

curveship 12y ago

Issues logged for this, the multi-line comment termination issue, and for treating any line that ends with')' or '}' as javascript.

evmar 12y ago

Idea: require a <script> tag around the JS in the template (but just for your parser's benefit, not as a tag you intend to embed literally in the rendered DOM -- you can remove it at parse time as necessary). This has the nice side benefit that it will make editors happy. (E.g. emacs recognizes <script> tags within HTML and does JS highlighting/indenting on their content.)

roller 12y ago
This seems like a great idea, even if it's just optional tags that get ignored. With <script> you suddenly have a valid html fragment that should work with any editor. I guess as is, a make could include a grep -v </?script> step.
fineline 12y ago
Agree, removing the need for any special editor support would be great, even if offered as a compiler option. Makes the detection of JS a non-issue too.
tipiirai 12y ago
I can clearly see the benefits here. I'm also resistant to it because of the added syntax. Deciding later :)
- jbellsey 12y ago
  The idea of having integrated components (HTML+JS) is certainly interesting and forward-thinking. However, I hope it doesn't lead you to limit us to the integrated style, by making the Riot compiler a required build step. Personally, I greatly prefer the direct coding style, i.e., riot.tag(). Not only because of the editor issues mentioned here, but because I can include my own modules in my scripts. I.e., can I use require() inside a Riot-compiled module? Stuff starts getting very hoop-jumpy once you start creating your own compiler & syntax, and bringing too much "magic" to the table. One of the big appeals of Riot is how UN-magical it is!