Lucee 5 lucee dialect documentation is wrong compared to current behavior.

Description

The documentation says we can use .lucee as both component or include style cfml code, but that we need to type it with <: instead of <cf.

https://docs.lucee.org/guides/lucee-5/dialect-lucee.html

I don't know how to get <: to work in the current version, it appears to be broken. We can only type <cf tags, and <: doesn't work at all.

It is also very confusing that you disabled Lucee dialect by default shortly after releasing it and didn't add documentation for enabling it as an admin option. This is the only mention of how to enable it I found:
https://dev.lucee.org/t/how-to-enable-lucee-dialect/981

I also don't seem to be able to get the notSupported message to fire though even when I don't enable lucee dialect, so that would help if that was working. It seems like that feature is also broken.

I also ran a debugging session in the Java to understand what is going on more, but it seems like it has been disabled in areas of componentLoader.java by mistake or on purpose. For example, a .lucee file is a Page, and not a CIPage when given lucee syntax which results in some null values and it looks at the wrong pagesource in some places to determine the dialect, which may be wrong when you mix both languages. I think both the cfml compilation and the loader both have some bugs if it was to work like the documented way again.

I also get this error if I switch the syntax from between <cf and <: while the server is running. It appears to be able to make the Page, but then gets stuck unable to re-compile until you restart lucee engine. I would think that it would need to be able to deal with this since a developer would likely be trying to convert syntax like this in regular work.
class redefinition failed: attempted to change superclass or interfaces

I don't mind if we continued to use <cf tags, but lucee dialect isn't doing what it says it would do. For example, localmode="modern" is not forced when web admin is set to classic mode. If I can't get this to work, there is no reason to use lucee dialect.

It is also confusing that the same extension can optionally have a component tag in it. It should support multiple components in the same file if this idea was more complete, but I doubt you could do it with cfcomponent the way it is designed, it probably requires a new language construct like "class" to get away from the legacy of components not having a code-based name. I'd argue that lucee dialect should require exclusively component style syntax though and a more strict component path system that requires root relative paths like java. Not only do I disagree with this concept of allow cfm style code, but it is also impossible to switch between having a cfc and cfm style without restarting the Lucee engine. I get the same compilation error when doing this:
class redefinition failed: attempted to change superclass or interfaces

I would encourage removal of Lucee dialect from future releases until it is working as intended. Easy to do by forcing a false value in the xml config load compiler code.

Environment

windows and linux

Assignee

Michael Offner

Reporter

Bruce Kirkpatrick

Priority

Minor

Labels

None

Fix versions

None

Affects versions

Configure