... | ... | @@ -9,6 +9,12 @@ This document governs best practices for writing CFML for inLeague applications |
|
|
|
|
|
## Function Architecture
|
|
|
|
|
|
### Function definitions
|
|
|
* **Return Type Mapping**: Functions should declare a return type without an extended path name (e.g. `public Response function doSomething()` and not `public api.models.Response function doSomething()`. This is because the full mapping for a component may not be consistent across different versions of Lucee.
|
|
|
* **Return One Thing Or Don't Specify**: Functions could return a single return type, but may return null. If a function can return either something or null, don't specify a return type in the method signature. Functions should never return two different, non-null types (e.g. a struct or an array)
|
|
|
* **Returning Metadata and Data**: If a function is returning both data and metadata about what the function did, use a **Response@api** object, as it has plumbing for error status, messages, and data, and it maps very well to either cbmessagebox results or API endpoints. When in doubt, return a `Response`.
|
|
|
|
|
|
### What to put in Handlers, Models, or Services
|
|
|
Handlers' job is to handle input. Their job is not to apply business rules, or even be aware of business rules. They are concerned with:
|
|
|
|
|
|
* processing incoming data in the request scope
|
... | ... | |