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