Syntax for HTML Island in Script

language ideas
61

Again, this resorts to strings.

Also, this has nothing to do with functions. Why add another function?

Please see my comments above. Especially https://lucee.daemonite.io/t/syntax-for-tag-island-in-script/2347/16

62

Haha forgot I even lobbied for this originally,

This was something openbd had

This answers my requirement I think

2 Likes
63

I guess there maybe some escaping headaches but this i think solves my use case

64

if we had something like html{} then we wouldn’t as it would be a code block

The same with above. the editor would now know that anything within html{} is a html statement and parsed as such

not if you use include :wink: but that is hardly a biggie? I think the benefit of being able to pass the return back out as a variable out-weighs the immediate output.

Meh. I think that is a straw man argument. There are so many other areas that you can attack first.

65

I owe you a beer/refreshment of choice/cookie at the soonest conference we meet.

1 Like
66

For real? That’s exactly the proposal here! How many times can I repeat that?

I will update the topic title so that there’s no more confusion.

67

I also updated the original post to reflect an option as html { ... }

68

Yes, for real, it’s a discussion on the approach not an attack on your ideas. Other ideas come in, not just yours, about parsing CFML so we have been discussing.

The first three ways you proposed did not seem very good. We have seem to settle on the fourth but you didn’t put fourth good cases, other people have and so have I in which we need to do this kind of thing.

That is the point of discussing things isn’t it? getting an idea, shaking it about ?

69

What has also come out of the discussion is that
a) there a loads of ways that this can be solved, not including render
b) we could improve include to immediately return a variable
c) we have to decide what html {} would actually parse. Otherwise it becomes cfml {} in tag

70

Yes, but in the original post I asked for other ideas. I gave 3 options that were discussed before the post, and I asked for other ideas. But that’s just for the syntax.

Then the whole concept was attacked, not a particular syntax.

If that is your proposed syntax then great, it was added above as option 4. But you kept saying something like the concept is bad but it’s fine with option 4. And I kept saying that option 4 is just a syntax that does exactly what the attacked concept was proposed to do.

71

We have to decide that option 4 is the accepted syntax before we state it as a fact.

72

I still stand that adding a bunch of CFML block inside a script block is a Bad Idea ™ because it will be abused and we cant take it back.

It is not an attack Igal, it is a discussion.

73

sigh

I hate arguments of the way I said something.

I meant to say

“We have to decide what the function/syntax WOULD allow you to parse”

That better?

74

It’s awesome!

Consistent with what I wrote 25 messages ago at https://lucee.daemonite.io/t/syntax-for-html-island-in-script/2347/48?u=21solutions

75

render seems to output, not return the rendering, although it does seem to return a string - but just a blank one?

without getting into the merits of the whole endevour, this works in lucee 4.5 today:

<cfscript>
	//requires `this.mappings["/ram"] = "ram://";` in Application.cfc
	function tagIsland (input) {
		var filename = createUUID() & ".cfm";
		fileWrite("ram://" & filename, input);
		savecontent variable="local.output" {
			include template="/ram/" & filename;
		}
		fileDelete("ram://" & filename);
		return local.output;
	}

	y = "foo";
	x = tagIsland('<cfdump var="#y#" />');
	dump(x);
	writeoutput(x);
</cfscript>

You could make something like this more user friendly through an extension right? You could allow another way to delimit a multi-line string like using backticks (which would help in other places that there are escaping issues today) and that would make this just a little bit easier.

76

Yeah

77

See https://lucee.daemonite.io/t/add-optional-flag-to-render-to-buffer-the-output-and-return-as-string/2362

78

Thought crimes aside :police_car:

  • some people say all tags are bad, this position can’t be changed
  • some people say tags are useful sometimes, this position is fair
  • some people say using tags inline in a CFC would provide some benefits, rather than being forced to use a tag based CFC only, and this position is also fair
  • CFML is characterised by both Script and Tags, and this is life

I believe this boils down to whether or not:

  • there is a section of the community that wants the feature – sounds like there is
  • we get a Pull Request to build this – sounds like @21Solutions would be willing, and;
  • LAS is happy to accept the additional overhead of keeping it tested, documented and supported over the longer term – sounds minimal based on the current discussion

Absolutely agree.

I don’t understand why we wouldn’t allow for all tag parsing; ie. HTML and CFML. Especially if the more functional implementation is simpler to build and maintain.

Point taken. A few things though:

  • this suggestion makes mixing tags and script less awkward not more awkward
  • it’s already possible to abuse CFML with abandon; denying users who want this feature is not going to prevent more abuse
  • no “5 Tagger” worth his salt is going to build a script based CFC just so they can break open a tag island to commit self-harm
  • we’re all adults; if someone wants to run with scissors :scissors: … :sob: let them run

UPDATE:

Forgot to note that @joe.gooch suggestion of a potential migration method is great. I’ve seen this done in the past by isolating tag code into includes and bringing them into a component, but in practice this completely conceals what is going on in the external file and so gradual optimisations into script become less likely.

2 Likes
79

Script Blocks only have parts of the code
@bdw429s sadly this

<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.

Find the end
things like
cftag {<br>}
or
cftag(<br>)

Is not possible, because the parser cannot handle it, this could would be impossible for the parser to handle correctly.

cftag {
<script language="javascript">
function test(msg) {
   alert(msg);
}
</script>
}

Parser will not have a clue which } to pick as the end.
Lucee has 3 parsers, expression, script and tag parser. When the tag parser comes to <cfscript> it does not understand the content of cfscript, for the tag parser the body of the tag simply is a string. only the script tag itself then knows to handle it’s body because of this. so in short you need to find the end without understand the body. Because a different parser handles the body. The same is the case for a tag island. This is how the parser are working.

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.

1 Like
80

I agree and that makes sense for the intended purpose (a HTML tag island) - the unintended consequences of allowing CFML inside script however far outweigh any proposed advantages that I’ve seen discussed here.

Why wouldn’t it? If you can’t write a CFML tag island inside of a cfscript, then you cannot abuse the language in ways which are currently not possible. Therefore ‘denying’ users this ability would absolutely prevent more abuse.

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?

Hey, this piece of cfscript code does almost what I want it to do, but I have no idea how to even modify it. Oh look, I can just use this tag island thingy to modify this function and it’ll do what I want.

Oh the glorious code that will be built if CFML tags are allowed inside of cfscript. I can see it now. ::shudder::

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. From where I sit, giving 5 taggers (the children in this analogy) scissors and telling them to run is a) bad language stewardship, b) shooting ourselves in the foot to spite our face and c) ignoring our responsibility to junior developers.