We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement
Coming out of #1126 , it's clear that how Greenwood handles various aspects of its templating, primarily for HTML, is a little too naive / brittle.
For example, Greenwood uses placeholders for injecting content into an HTML template
<html> <body> <content-outlet><content-outlet> </body> </html>
Would get handled like this in the CLI
body = body.replace(/\<content-outlet>(.*)<\/content-outlet>/s, processedMarkdown.contents);
This issue is that $1 is used for matching when used in conjunction with the String .replace function.
$1
.replace
So we have to keep doing things like
body = body.replace(/\<content-outlet>(.*)<\/content-outlet>/s, processedMarkdown.contents.replace(/\$/g, '$$$'));
This should also help us ensure that these are handled the same, just in case
<p>Hello World</p> <P>Hello World</P>
So rather than keep suffering through these issues...
replace
<script>
<style>
<link>
Since we are already using an HTML parser, I see it supports methods like set_content which could a much more practical way to approach this problem.
set_content
So basically any usage of .replace, for HTML at minimum, would be a candidate for refactoring.
The text was updated successfully, but these errors were encountered:
thescientist13
No branches or pull requests
Type of Change
Enhancement
Summary
Coming out of #1126 , it's clear that how Greenwood handles various aspects of its templating, primarily for HTML, is a little too naive / brittle.
For example, Greenwood uses placeholders for injecting content into an HTML template
Would get handled like this in the CLI
This issue is that
$1
is used for matching when used in conjunction with the String.replace
function.So we have to keep doing things like
This should also help us ensure that these are handled the same, just in case
Details
So rather than keep suffering through these issues...
$1
#1126replace
with inline JavaScript #657<script>
/<style>
/<link>
tags #1241Since we are already using an HTML parser, I see it supports methods like
set_content
which could a much more practical way to approach this problem.So basically any usage of
.replace
, for HTML at minimum, would be a candidate for refactoring.The text was updated successfully, but these errors were encountered: