Syntax for HTML Island in Script

[markdrew]

What I would like to see are a couple of things… not just single line examples. But big files of code that would be improved by adding this.

And the point of it. Rather than we can because reasons. But what we are aiming to solve.

I was thinking about this on the way and (pardon the half-baked thought) if there was a point to this it would be for specific parsers (not executers) for various… well parsers. What I mean is have things such as:

var html = html {

 <h1>#Title#</h1>
}

and then you can do other types of parsing:

var out = markdown {
# #Title#
The thing about the thing
}

or even

var sql = sql {
 SELECT * FROM Users Where Name = 'Bobby drop tables'
}

or

var js = ecmascript {

console.log("#output#") ;
}

With the ability to register a new parser if required.

This is for the engine to parse the code inside it… so I guess you could create a meta parser which would be:

var out = cfml{
<cfif mustWriteBadCodeToMakeCFMLLookBad>
CFML Rocks! No, really. IT does! Stop pulling that face. I am being serious. 
</cfif>
}

Anyway, just a half formed thought but yeah,. I could see some really fugly code in the coming years \o/

[ddspringle]

@micstriit

<cfscript>
for(…) {
</cfscript>
<h1>#name#</h1>
<cfscript>
}
</cfscript>

sadly is not that easy. in that case we would have 2 complete indepedent script blocks. the only thing i can think of, is that an evaluator detect this situation and makes some magic.
In my opinion that would be the best solution by far.

This raises the issue of how would this work in a cfscript CFC, where we cannot delineate what is script from what is not script.

@micstriit

So we need to have a clear end that is not used in most cases by accident inside the code island, so } not really is an option.

Fair point. That takes any combination of (), [] and {} off the table for sure, I can’t think of anyone that would want to escape any of those on a regular basis.That leaves only the three backticks out of the proposed options, which would be problematic for anyone wishing to parse markup inside a tag island. The only other options I can think of are:

~~~ <h1>#somevar#</h1> ~~~

or

^^^ <h1>#somevar#</h1> ^^^

Those combinations seem unlikely in most use cases I think?

[isapir]

Agreed.

The reason I proposed the three backticks is that it’s common in MarkDown and in all of the “chat” apps out there (e.g. Slack).

Also, while ~~~ and ^^^ are unlikely, those characters are still used more commonly than the backticks, usually for “text decoration”.

[ddspringle]

@21Solutions

Also, while ~~~ and ^^^ are unlikely, those characters are still used more commonly than the backticks, usually for “text decoration”.

Yeah, hadn’t thought about that. Also a fair point. Well, that leaves backticks unless we can come up with anything better.

I like the latest idea from @markdrew as well, it solves for some of the problem of using {} by setting expectations for what is allowed inside each parser type, of which } is less likely to occur inside plain HTML. ecmascript{} still suffers the same problem with }, however, and writing all the different parser’s would be more work.

[isapir]

@ddspringle

I like the latest idea from @markdrew as well, it solves for some of the problem of using {} by setting expectations for what is allowed inside each parser type, of which } is less likely to occur inside plain HTML.

We can do a combination of backticks with a cfml comment, e.g. (I’m using single quotes in the example for readability, or else discourse will mess up my format, but do a mentalReplace(snippet, “'”, “`”):

'''<!--- sql !---> SELECT * FROM some_table; '''

'''<!--- javascript !---> console.log("Hello from JavaScript!"); '''

`‘’'<!— html !—>

Some HTML markup.

'''`

'''<h1>Default, processed at <em>#now()#</em>.</h1>'''

This is similar to Github’s way of specifying a language:

Creating and highlighting code blocks - GitHub Docs

The idea here is to make it easier for syntax hilighters to parse the snippet properly, but there is also a possibility to use it in the Lucee parser, and that way differentiate between cfml and non-cfml.

[markdrew]

@21Solutions

The reason I proposed the three backticks is that it’s common in MarkDown and in all of the “chat” apps out there (e.g. Slack).

Why not a singe back-tick? In ES6 those define template literals. And no one uses back-ticks in their code (or it would be highly unlikely)

But still, if you have the idea of a back-tick to define a template literal you then need to say what you can parse inside it. The point I am getting at is I would hate to see this:

<cfscript>
cfml = `

10000's of lines of CFML

`
echo(cfml);
</cfscript>

[isapir]

@markdrew

Why not a singe back-tick? In ES6 those define template literals. And no one uses back-ticks in their code (or it would be highly unlikely)

Exactly because ES6 uses it. If we use a single backtick for the “tag island” (I think that “Literal Island”, or even “Template Literal” as in ES6 is a better term), then you will not be able to place ES6 template literals inside the island.

[joe.gooch]

Or emulate PHP/ASP type constructs:

sql{?
    SELECT *
    FROM some_table;
?}

javascript{?
    console.log("Hello from JavaScript!");
?}

html{?
<h1>Some <em>HTML</em> markup.</h1>?}

{?<h1>Default, processed at <em>#now()#</em>.</h1>?}

{? block ?} keeps things separate from “normal” braces.

[isapir]

But then we have to define the “known” syntaxes, like sql, javascript, html, etc. in our parser.

Using my suggestion above you can put in the comment whatever you want, and future syntaxes will not require changes to the Lucee code. Only the editor parsers will have to know how to hilight them.

[ddspringle]

@21Solutions

We can do a combination of backticks with a cfml comment

A more elaborate example using your notation to consider:

// example of sql use
sql = ```<!--- sql !--->
	SELECT colOne, colTwo
	FROM someTable
	WHERE colThree = :colThree
	AND colFour = :colFour
```

// example getting a query
qGetQuery = queryExecute( sql, { colThree = 'foo', colFour = 'bar' } );

// checking for records
if( qGetQuery.recordCount ) {
	// outputting html wrapper header
	```<!--- html !--->
	<div>
		<select name="someName" id="some-id">
			<option value="someValue">someLabel</option>
	```

	// looping through records
	for( record in qGetQuery ) {
		// outputting option
		```<!--- html !--->
			<option value="#record.colOne#">#record.colTwo#>
		```
	}

	// outputting html wrapper footer
	```<!--- html !--->
		</select>
	</div>
	<div id="other-id"></div>
	```

    // outputting javascript
	```<!--- javascript !--->
	$( function() {
		$('#some-id').on( 'change', function() {
			$('#other-id')
               .html( '<h1>You selected option: ' + $(this).val() + '</h1>' );
		});	
	});
	```
}

[isapir]

Nice!

Since <!--- html !---> will be default, and the language hints are optional anyway, just showing this in a more concise way:

for( record in qGetQuery ) {
	```<option value="#record.colOne#">#record.colTwo#</option>```
}

Also, as mentioned above, the ES6 Template Literals can now be used safely:

```<!--- javascript !--->
    $(function() {
        $('#some-id').on('change', function() {
            var value = $(this).val();
            $('#other-id').html(`<h1>Selected option: ${value}</h1>`);
        });
    });
```

[dajester2013]

I would rather see HEREDOC support:

var html = <<<EOD
  <div>
    Hi world!
  </div>
EOD;

[isapir]

@dajester2013

I would rather see HEREDOC support

The code in the “HTML Island” should be parsed at compile time, and not interpreted at runtime.

Having dynamically-set terminators will require major modifications to the parser and can have a major impact on performance.

[modius]

@ddspringle

No “5 Tagger” worth his salt is itself an oxymoron. I have never met one. You’re either an experienced developer who understands how to use the language to solve real world problems, or you’re a 5 tagger. EDIT: I count junior developers among those I consider experienced, just to be clear here.

That said, why wouldn’t a 5 tagger, having learned this capability exists, not immediately find a use case for putting tags into script?

My reference to “5-taggers” was meant to be tongue in cheek.

The notion that there’s an army of developers capable of dissecting a script based CFC, and yet determined enough to inject their “5 tags” due to a wilful ignorance of the code they just pulled apart is nonsense. 5-tagger mythology and other hyperboles is not helpful in this discussion.

@ddspringle

Correct, and as the adults in the room it is our job to help decide if giving the children scissors and letting them run with them is also appropriate.

Adults have made a perfectly reasonable argument for the use of this feature by adults. It’s not intended for children and so “protecting children from harm” doesn’t really factor into the decision making process.

So analogies aside…

• real life developers have proposed a feature they would find useful
• community members have volunteered to contribute the feature as a pull request
• allowing for the full parsing of all tags is easier to create and maintain than a partial parsing

Again, I suggest this boils down to:

• finding a suitable syntax
• having a pull request submitted
• LAS accepting ongoing responsibility for the documentation and maintenance of the change

I’m not sure I’ve heard any arguments beyond personal preferences put forward for why this should not be added to the language, especially since we already appear to have options such as render() in place.

[ddspringle]

Sigh.

@modius

My reference to “5-taggers” was meant to be tongue in cheek.

The notion that there’s an army of developers capable of dissecting a script based CFC, and yet determined enough to inject their “5 tags” due to a wilful ignorance of the code they just pulled apart is nonsense. 5-tagger mythology and other hyperboles is not helpful in this discussion.

Lol. I understood the implication of your “quotes”, no need to explain social norms to me. I chose to ignore it because it was irrelevant, but since you want to keep bringing it up… I “got your drift”.

You’ve never worked in DC, I take it? Perhaps you’ve never been in any large city with an above average population of these so called “5 taggers” that you think is pure myth and hyperbole?

CFML is embedded in our (US) government, there probably isn’t a single agency that doesn’t have one or more applications written in CFML. It is Adobe’s largest market, by far. Lucee has a smaller but useful following there as well. Our government contractors are infamous for pouring warm bodies with minimal pre-qualifications for minimal pay into positions which allow that caliber of developer to touch, if not build, utter monstrosities.

Why do you think developers in other languages have a general disdain for ColdFusion? It is precisely because of all the ugly as [insert favorite explicative here] spaghetti code they’ve had to migrate organizations away from that was left behind by these “mythical creatures”.

@modius

Adults have made a perfectly reasonable argument for the use of this feature by adults. It’s not intended for children and so “protecting children from harm” doesn’t really factor into the decision making process.

The people you see here in the forums, on Slack, at user groups and at conferences are a very small subset of a very large group of people. You have to consider this in your decision making. Just because you, and a hand full of others, have voiced support for this feature does not mean it should automatically get a pass.

My arguments are both warranted and reasonable. If a hand full of people get this feature because [reasons] then I predict it will ultimately be yet another nail in the CFML coffin.

I’m really beginning to wonder why I’m even wasting my time having to explain how nuanced this change really is and why it is important to have discussions about the ramifications of broad sweeping changes to the way a language works, but here I am. Defending sanity.

@modius

real life developers have proposed a feature they would find useful

Real life developers do this all the time in every language. It is only after careful consideration that changes to the way a language works are even considered, usually in an effort to move the language forward, not backwards as ‘real life develoeprs’ here have proposed.

@modius

community members have volunteered to contribute the feature as a pull request

And I thanked him for his contribution and we discussed the ramifications of the change and agreed that full parsing was not preferential.

@modius

allowing for the full parsing of all tags is easier to create and maintain than a partial parsing

Yeah… sometimes language designers have difficult choices to make. Sometimes those decisions mean more labor is required to bring the feature in line with what that language ought to allow. Sometimes that makes it more difficult to maintain that code over the long haul than it would be to simply ignore the problems. It sucks, but you can either put forth the best product you can, or you can throw a bunch of band-aids on and let 'er rip.

I’m sorry you think they ought to just let 'er rip, but I do not. It is butchering the language to solve problems that should be solved in different ways. Fix the problems, specifically, if you want to build a decent language - don’t throw this band-aid solution at the problems is all I’m suggesting.

@modius

I’m not sure I’ve heard any arguments beyond personal preferences put forward for why this should not be added to the language, especially since we already appear to have options such as render() in place.

Yes, it would be my personal preference that CFML tags not be allowed inside cfscript to solve unrelated problems and create a giant FUBAR way of developing that will be stuck with Lucee forever. A broad sweeping change that takes the language backwards because a handful of people think its nifty.

EDIT: render() was an attempt to solve a different problem and has a different implementation. It shouldn’t have been added either as far as I’m concerned, but now we’re stuck with it and it also doesn’t pose the potential for abuse that this particular change would allow.

Make no mistake, this is a change that has consequences. Just because you fail to see those consequences manifest in your experience does not mean those consequences do not exist, and it doesn’t mean that my concerns are mythical or hyperbolic. Your assertions that my concerns should be dismissed amuse me, frankly.

All that said, at the end of the day I have zero control over what LAS does or does not do with their version of the language. I’m just forewarning those who refuse to see the danger that the danger exists and should be considered before making such a sweeping change to how the language can be built. I’m suggesting that solving the individual problems that people have suggested this magic bullet would solve is the better approach to those problems.

[justincarter]

@ddspringle

You’ve never worked in DC, I take it? Perhaps you’ve never been in any large city with an above average population of these so called “5 taggers” that you think is pure myth and hyperbole?

CFML is embedded in our (US) government, there probably isn’t a single agency that doesn’t have one or more applications written in CFML. It is Adobe’s largest market, by far. Lucee has a smaller but useful following there as well. Our government contractors are infamous for pouring warm bodies with minimal pre-qualifications for minimal pay into positions which allow that caliber of developer to touch, if not build, utter monstrosities.

You can write “bad” or non idiomatic code in almost every language. I think developers need to be educated, rather than protected with permanent training wheels.

@ddspringle

Why do you think developers in other languages have a general disdain for ColdFusion?

From my experience: their opinions were formed many, many years ago (mostly pre-Java re-write and pre-Railo/Lucee) or when the language didn’t even have components, and/or they don’t see the value in the Adobe licensing costs. The “eww, it’s tags” reaction is a by-product of those times and the history of the product, and doesn’t represent the modern reality of the language, nor other languages or frameworks, some of which have embraced tag style constructs.

@ddspringle

Yes, it would be my personal preference that CFML tags not be allowed inside cfscript to solve unrelated problems and create a giant FUBAR way of developing that will be stuck with Lucee forever. A broad sweeping change that takes the language backwards because a handful of people think its nifty.

I think the resultant problems are a little overstated here, but we can agree to disagree. Developers aren’t out to create bad code on purpose. The code will not be any “worse” than that is already possible in a tag based component, and not all tag based components are inherently wrong or bad. At the end of the day, most lines in a tag or script based component are directly comparable and no better or worse that each other, except to those who are allergic to angle brackets

[ddspringle]

I was going to write a witty retort… but I have already given ample reasons for why we shouldn’t be taking the language backwards. We can agree to disagree, but I will not keep repeating myself.

[modius]

@ddspringle

Make no mistake, this is a change that has consequences. Just because you fail to see those consequences manifest in your experience does not mean those consequences do not exist, and it doesn’t mean that my concerns are mythical or hyperbolic. Your assertions that my concerns should be dismissed amuse me, frankly.

My reference to hyperbole is not a reference to people using only 5-tags or woefully inexperienced developers.

I just don’t believe that “warm bodies with minimal pre-qualifications for minimal pay [in] positions which allow that caliber of developer to touch, if not build, utter monstrosities” are “capable of dissecting a script based CFC, and yet [be] determined enough to inject their “5 tags” due to a wilful ignorance of the code they just pulled apart”.

If these “5-taggers” never learn anything new, how are they going to learn about tag islands? If their projects are already utter monstrosities, what difference would it make?

I am for tag islands with full parsing if it improves the lives of some experienced developers.

If I understand you correctly, you are against the enhancement because you believe inexperienced developers will use it unwisely.

[ddspringle]

Round N+1

@modius

I just don’t believe that […]

And what, exactly, do you base this belief on? That is the point of that particular argument… you don’t ‘believe’ this is a real problem, despite someone with over two decades of experience working with that caliber of developer telling you that it is.

@modius

If these “5-taggers” never learn anything new, how are they going to learn about tag islands?

“Necessity is the mother of all fuck-ups”. I never said they didn’t try to solve problems - they wouldn’t have a job if they didn’t. This will eventually lead that caliber of developer to discover the capability and, as I’ve already illustrated once before, implement it to solve a problem.

@modius

If their projects are already utter monstrosities, what difference would it make?

Sigh. Perception. We’ve discussed this, you and I, and you summarily ignore everything I’ve had to say on the subject. You want more adoption of Lucee/CFML in the long run? Then this is the wrong direction for the language to take. The difference is that developers of other languages, the ones who ultimately get called in to clean up the mess, will have their perceptions of this ‘modern language’ tainted by the ability to put CFML tags inside cfscript. I can’t believe I have to make this point, again.

@modius

I am for tag islands with full parsing if it improves the lives of some experienced developers.

Yes, you’ve made it quite clear that you are one of the few developers who are willing and eager to take the language backwards to help a few of your friends continue to write crappy code. You have made it clear that the correct approach of solving the individual issues that plague or prevent some developers from fully adopting cfscript does not interest you, and that your concern for knock-on effects of implementing this into the language do not concern you whatsoever, because [reasons].

In short, you’ve made it perfectly clear that you don’t really care what the long time users and supporters of the platform and the language have to say…This little community of ours will continue to shrink as a result.

@modius

If I understand you correctly, you are against the enhancement because you believe inexperienced developers will use it unwisely.

This is one part of my argument, though with less of the cotton candy rewording of my concerns you’ve decided upon, but it is the one you’ve chosen to focus all of your energy on. My concerns are many and more nuanced than just ‘but muh 5 taggers will abuse it’, and I have elaborated on all of them in this thread.

I have made my concerns clear, and a handful of you - LAS members and TAG members, no less (which itself is very telling) - have come up with excuse after excuse for why those concerns shall fall upon deaf ears. I’m not arguing with you anymore henceforth.

If Lucee wants to shoot CFML in the foot… I can’t stop it. It is, frankly, up to Igal now what the end result will be. I can only hope that logic prevails above the incessant crying of the few who support moving backwards with the language.

[isapir]

@ddspringle

“Necessity is the mother of all fuck-ups”

Correction:

“Necessity is the mother of all inventions”.

“Assumption is the mother of all fuck-ups”:

Assumption is the mother of all fuckups