Syntax for HTML Island in Script

language ideas
41

Personally as a framework / platform developer

I think the idea of being able to easily create tags / markup and XML without nasty concats is a nice feature.

I don’t think the tag island for the sake of calling cf tags is what we are talking about is it

you can already call cf tags from script that don’t exist in script and thats becoming less and less, be it slightly different notation on CF vs Lucee.

I think using some syntax being able to nicely have markup generated while being able to still have tags is helpful. without the nasty concat stuff we have to do presently.

Its great for people to say script shouldn’t have tags in but then they’re not framework builders

And in terms of features I’d be happy to see my member subs go towards this I think we’d use it

2 Likes
42

Or anything inside html() doesn’t need to be escaped as in my original code example. Now you have to define what markup engine you use. By default Lucees of course. \

html (

<h1>{{title}}</h1>
{{body}}

You ordered:
<ul>
{{each array}}
    <li>{{thing.name}}</li>
{{/each}}
</ul>
)
43

LIke I said, I’m all for an html{} function… something like:

html{
<div>
    <select>
        <option value="">Choose One</option>
}

for( option in options ) {
    html{
        <option value="#option.id#">#option.name#</option>
    }
}

html{
    </select>
</div>
}

No need for CFML tags at all. We can script the way we script now for flow control and output the parsed HTML the same way we would if we put it in a string.

2 Likes
44

This is exactly the proposal, just that you would use the standard #title# instead of your newly proposed mustache-style syntax of {{title}}

Again, this is exactly the proposal.

cfml tags will be processed “by default” as a side-effect because that parser is already built.

Whether it’s worth to spend the time on modifying the parser so that it will prevent cfml tag processing inside that island is open for debate.

45

This is what I would propose we don’t do, or say that a limited set of tags (logic flow) would work within the island.

46

This ‘side effect’ would have all the knock-on effects I’ve been arguing against from the outset. So, yes, in my opinion, it is worth the time to prevent a tag island from executing CFML tags.

1 Like
47

Can you do some use-cases? a feature like this would lead to more screwed up CFML than normal.

2 Likes
48

TBH, I also prefer not to have cfml tags there, as long as you can evaluate expressions like #title#. I rarely ever use cfml tags myself and for about 10 years now have been using cfscript wherever possible.

The title of this post would have been better written as “Syntax for HTML Tag Island in Script”.

The question is how much work it would take to modify the parser so that cfml tags in that island are disabled.

1 Like
49

what I WOULD love and use immediately is a way to simplify this:

component {
	function render(){
		savecontent variable="local.out"{
			include template="/viewfile.cfm";
		}
		return local.out;
	}
}

By doing:

component {
	function render(){
		return include template="/viewfile.cfm";
	}
}

or (if the one above is too cray cray)

component {
	function render(){
	 	include template="/viewfile.cfm" returnvar="local.out";
		return local.out;
	}
}

This would solve 90% of issues and keep the code nice and lean and separated into view vs logic.

50

What issues?

How does adding a function that calls include improve on simply using include inline? i.e.

include "/viewfile.cfm";

OT1: you do not need the template= attribute for include. all that does is add a variable named template. you do it as in my example above.

OT2: you do not need the local scope in return local.out; as long as it was saved initially with the local scope it’s enough. the local scope is the nearest scope inside a function so return out; is sufficient.

51

Of trying to parse CFML Tags in script.

I don’t want to output the body from a function, I want to return the items in an include. I could also do include("/viewfile.cfm")

The point being that I was immediately returning it. without having to wrap it in a savecontent{}

52

So you want something like

out = fileRead("/viewfile.cfm");

?

1 Like
53

Well, no, it would parse the contents so something like

out = include("/myviewfile.cfm");
54

So you have savecontent for that just as you’ve written in your example, but why do you wrap it inside a function instead of putting it inline?

savecontent variable="out" { include template="/viewfile.cfm"; }

Are you calling it many times?

I am guessing that you’re writing out to the Response stream at some point? Why not write it directly with include?

TBH I’m not sure what you’re trying to do, but it will not solve any portion of the issues that this post is detailing. The main idea is that you wouldn’t need to have a separate file for a few lines of HTML markup.

55

So, wow, I now have 50 new emails in my inbox. Since this morning. Great.

Could we please stop the tag bashing? Scripters will always argue there’s no need for tags. Tagger will always argue there are. We’re not going to solve that problem today. I’ve used both. I continue to use both. I’m going to continue to use both. And I’d appreciate it if those on the list that have a preference one way or another enforce their own Best Practices in their own projects, not mine. Just like my coders need special permission to use Evaluate(), or SetVariable(), or any of the other generally considered bad things.

Performance is largely irrelevant at the level we’re talking here. Readability is a concern, but everyone’s “readable” means something different. Kev McCabe’s code looks tons different from Ben Nadel’s. AND THAT’S FINE. But please don’t say on one hand that it’s “Not just your opinion” and then say “XYZ is more readable”… Because you’re just contradicting yourself. It very well may be, in your opinion.

Back to the ACTUAL issue here:

I don’t see any merit to providing a tag island for “some” tags. How is the html() function any different from writeoutput, if writeoutput evaluates #var# expressions? I see no merit in that. It’s basically a function alias.

I DO see a merit in providing a tag island, which should run the SAME CFML tag parser as everywhere else. Whether it’s backticks, or braces, or what, I couldn’t really care less. However, I do know I’ve had specific real-world examples where I’ve had to escape from cfscript to do something tag based. I could go digging for examples, but the answer is it doesn’t matter. The language supports both conventions, and if it can be used that way, tag islands have merit. Period. A html() tag that doesn’t support cfif is pretty worthless IMHO.

The argument seems to be we shouldn’t do this because we’re trying to force other developers to write the way we think they should. If it makes you feel better, consider this a migration method that could be used by someone converting large, tag-based project to “better” cfscript based code.

2 Likes
56

Because inside a function inside a component scripted is usually where people are trying to put random tags which is generally where people will try to use them.

could be. 0-n times.

Because it would be at some point. Not immediately. Functions outputting stuff is super ugly as it stops them being pure functions and turns them in to functions with side-effects that make things a lot harder to debug.

or CFML markup. Mura does this all the time. You have to do the decision to write a CFC (contentRenderer) in Tags becasue later on your functions will have to output HTML, and it is super ugly since now I am forced to do it.

A good solution is the one I detailed above, which returns the rendered HTML and separates logic from view. I did say that a small feature would go a long way and it was a small aside that would fix a lot of the cases that I see inline CFML and Tag based CFCs having to be used.

57

If you only want HTML and the ability to output CFML variables, then what is so bad about just doing this:

function toHTML() {
    return '
            <option value="#encodeForHTMLAttribute(getID())#">
                #encodeForHTML(getName())#
            </option>
    ';
}

If you actually want CFML you can use Lucee 5’s render function (here’s a gist: TryCF.com
)

fruit = "Kiwi";
render('
    <cfswitch expression="#fruit#"> 
        <cfcase value="Apple">I like apples!</cfcase>
        <cfcase value="Orange,Citrus">I like oranges!</cfcase> 
        <cfcase value="Kiwi">I like kiwi!</cfcase>
        <cfdefaultcase>Fruit, what fruit?</cfdefaultcase> 
    </cfswitch>
');

Seams like the facilities already exist to do tags in script?

2 Likes
58

there is a render() function?? I couldn’t find it in Render() :: Lucee Documentation

59

yes, there is a render function. Checkout the trycf link I posted, the code works. It is listed on the What’s new in Lucee 5 page of the documentation: New and modified functions :: Lucee Documentation

1 Like
60

Thanks for that, I wasn’t doubting you BTW! I was just shocked I hadn’t heard of it. Thanks for the heads up!