Automatically generated apps are a fantastic starting point. With a few clicks, you have a powerful, professional-looking application with robust capabilities for creating, reading, updating, and deleting records (CRUD). But real-world business requirements are rarely that simple.
What happens when your users need to do more than just edit a product? What if they need to trigger a specific business process, like marking a product as discontinued, changing its supplier based on complex rules, or applying a batch update to dozens of records at once? This is where a standard CRUD interface reaches its limit, and the true power of your application platform needs to shine.
From Simple Clicks to Smart Operations
In Code On Time, the answer lies in a powerful, decoupled system of Actions and Business Rules. Think of it this way:
- An Action is the user-facing component—a button in a form or an option in a context menu that a user can click. You define what it looks like, where it appears, and what it's called.
- A Business Rule is the server-side logic that executes when the Action is triggered. This is where you define what actually happens.
This separation is key. You can have multiple actions in different parts of the UI trigger the same underlying business rule, ensuring consistency and reducing code duplication.
For example, a "Mark as Discontinued" option can be added to a row's context menu with just a few property settings.
Clicking the 'More' icon next to the first column displays the row's context menu, which is populated with actions defined in the 'Grid' scope group. The tooltip that appears on hover, "Remove product from the catalog," is pulled directly from the action's Description property, demonstrating how configuration directly maps to the user experience.
And you can easily add a confirmation dialog to prevent accidental clicks, providing a crucial safeguard for important operations.
A simple modal confirmation dialog appears when the action is invoked, serving as a crucial safeguard against accidental operations. This dialog, generated from the action's Confirmation / Text property, is intuitive for the end-user, who can dismiss it with the 'Esc' key or confirm it with the 'Enter' key.
Collecting User Input for Complex Tasks
Some business processes require more information. Replacing a product's supplier isn't a simple "yes/no" decision. You need to know which new supplier to choose.
This is where you can leverage a "Confirmation Controller"—a dedicated form designed to collect additional parameters from the user before an action is executed. This technique allows you to create complex, multi-step operations that feel seamless to the end-user.
The view1 form of the Products_ChangeSupplier is shown when the user is selecting a new supplier for the product. The form is displayed when app users initiate the changesSupplier action in the `Products controller. This modal form acts as a temporary data collection tool. This powerful technique allows for the creation of complex, multi-step operations that require additional user input without cluttering the primary interface.
Bringing Intelligence to the Front-End, with SQL
The most innovative part of this system is how you can control the entire client-server interaction without leaving the comfort of a familiar language like T-SQL. The business rules you write on the server can intelligently direct the user interface on the client.
Imagine the "Change Supplier" action requires that the new supplier must already provide other products in the same category. You can write a simple SQL business rule to validate this logic. If the user selects an invalid supplier, the rule can instruct the front-end to:
- Stop the action from proceeding.
- Set the focus directly on the invalid input field.
- Display a precise error message right where the user needs to see it.
This targeted error message showcases intelligent server-client communication. Instead of returning a generic error, the server-side business rule uses the @Result_Focus parameter to instruct the client-side UI to focus on the specific field that failed validation and display a helpful message directly next to it. Use a comma to separate the field name from the message. The front end will automatically activate the tabbed category or category associated with another wizard step if the field input is not visible at the moment.
This entire sophisticated, client-side interaction is commanded by your server-side SQL script. You don't write a single line of JavaScript to make it happen. The framework handles the complex plumbing, allowing you to focus purely on the business logic.
Ready to Build Your Own?
From simple confirmations to multi-step, validated batch operations, Custom Actions provide the flexibility to mold your application to fit any business need. This high-level overview just scratches the surface of what's possible.
To learn how to implement these features step-by-step, from creating your first action to programming conditional validation logic, dive into our comprehensive tutorial.
Read the Full Tutorial: Custom Actions