Program Structure
This section covers the basics of the program structures of BoxLang
๐ File Types

BoxLang can be written in 3 types of files:
Scripts (*.bxs, or in compat mode *.cfs)
Templates (*.bxm, or in compat mode *.cfm)
Classes (*.bx or in compat mode *.cfc)
Each of these files follow the same program structure with different syntaxes. The only one of these that you will write using our templating language is the templates (*.bxm).
๐ Scripts/Templates
Scripts and templates in BoxLang do not require a class definition and can be executed via the CLI binary directly: boxlang {script|template} or ran by the MiniServer/CommandBox/Servlet/Etc.
Scripts
Script files have a bxs file extension and will use script notation, but you can also use the templating language by using opening and closing tag island notations: ```
Templates
Templates have a bxm file extension and will use the templating language but can also use scripts via opening and closing <bx:script></bx:script> tags.
โก Classes
Classes have a .bx extension and can be executed via the CLI if they have a main() method by convention. Unlike Java or other languages, the main() method does NOT have to be static, it can be an instance method or a static method, you chose.
๐ฆ Package Names
Package names are not necessary for these types of files as BoxLang will automatically create them for you. You will refer to these scripts or templates by path location or via mappings.
๐๏ธ Path Imports
BoxLang allows you to access any BoxLang class or script/template by location convention first with no need of imports explicitly. The following approaches can be used via path imports:
new class_path()createObject( "class", path )include template="path"Any BIF that requires a path
{% hint style="info" %} The discovery is done by looking at your global, application mappings and then relative pathing. {% endhint %}
Then we can do so by location reference:
These work great but the caveat is that when searching for those files and templates, BoxLang will try to discover them:
Is there a location mapping (globally or in the application)
does the file exist
use it
Works great, but yes, some lookup is done, but cached.
๐ Simple Imports
Another approach in BoxLang is to use the import statement or the <bx:import> template statement if you are in templates. This allows you to fully define the location of a class or template explicitly. This is also used not only for BoxLang classes but for any Java class:
From the example above I made no distinction on what was a Java class or what was a Boxlang class. By convention BoxLang will auto-discover the class for you according to it's package path. However, you can also use object resolver notation to disambiguiate the location and define it explicitly.
{% hint style="info" %} The implicit resolver is bx meaning a Boxlang class. You don't need to use it if you don't want to. {% endhint %}
๐ฏ Object Resolver Imports
BoxLang ships with two object resolver prefixes:
java:- To demarcate a Java class pathbx:- To demarcate a BoxLang class path
This is useful to disambiguiate paths and make them explicit. You can use it in the import or in the new() or createObject() syntax.
๐ Location of Imports
In box templates and scripts you can add the import/<bx:import> statements ANYWHERE in the file. We will collect them internally for you.
โญ Star Imports
Boxlang, like Java, allows you to import all classes from a package using the * after the last package path. All classes within that package/folder will be available for shorthand usage and reserved.
Now let's use start imports
This can be for both Java and BoxLang class paths.
๐ท๏ธ Import Aliases
BoxLang allows you to alias your imports in order to break ambiguity and to be able to import classes with the same name but with different aliases.
Here is another example:
๐ฎ Execution Examples
Running Scripts
Running Templates
Running Classes with Main Method
โ๏ธ Best Practices
๐ฏ Import Strategy
Use explicit imports for clarity and IDE support
Group imports logically (Java classes, BoxLang classes, third-party)
Use aliases to resolve naming conflicts and reduce ambiguity
Prefer specific imports over star imports for better performance
๐ก Naming Conventions
Scripts:
CamelCase.bxs(e.g.,DataProcessor.bxs)Classes:
PascalCase.bx(e.g.,UserService.bx)Templates:
camelCase.bxm(e.g.,userProfile.bxm)
๐ Cross-File Dependencies
๐จ Common Pitfalls
โ Avoid These Patterns
โ
Preferred Patterns
๐ File Discovery Process
BoxLang follows this discovery order when resolving files:
Relative paths (from current file location)
Application mappings (defined in Application.bx)
Global mappings (server-wide configurations)
Classpath resolution (for imported classes)
๐ Mapping Example
Last updated
Was this helpful?
