01 / Case study
The challenge
New features in enterprise panels commonly need entry and edit forms, validation, access control, searchable lists and reports. Implementing these separately produces similar code across pages and makes shared fixes harder to maintain. I built a foundation where developers define data structures, fields, rules and presentation, and shared engines generate recurring interface and data operations while keeping product-specific logic extensible.
My contribution
Implemented this approach through SamirCore and complementary panel tools: form and data-operation engines, configurable reporting, identity infrastructure and permission models, and patterns for visualizing application data. Shared behavior lives in the library, while product settings, layouts and business rules extend it. Administrative forms, payment lists, wallet history and sales dashboards demonstrate its use in actual application development.
Dynamic architecture: definitions into working pages
Forms and reports use structures defined in code. Developers give the shared engine a page definition instead of repeating markup and general operations.
Define the structure once
A form definition specifies field names, input types, labels, layout, validation and data binding. A report defines its data source, columns, filters and presentation. Shared engines turn these definitions into interfaces and runtime behavior.
Shared core and product extensions
SamirCore implements general behavior; advanced report layouts and complementary tools sit in the application layer. Products can adjust presentation and business rules while reusing the underlying engine.
A consistent development workflow
A new administrative module starts with its data and access scope, followed by form and list definitions and business logic attached at extension points. This gives similar pages a consistent implementation and review structure.
Advanced form generation and data operations
FormRecords combines interface generation, input processing, validation and configurable insert, update and delete workflows.
Rich fields and dependent selections
Supported fields include short and multiline text, integers and decimals, passwords, phone numbers, standard and searchable selects, multiple selections, radio groups and checkboxes. Definitions also support API-backed dependent options, hierarchical selection and modal selection controls.
Persian dates, files and images
Date and datetime inputs, Persian dates, single and multiple file uploads, image selection and crop settings belong to the same form structure. File presentation, storage paths and image settings can be configured per field.
Validation and bilingual interfaces
Required fields, maximum length and regular expressions are defined in field settings. Server checks and interface validation settings share configurable Persian and English messages and button captions. Layout, read-only behavior and custom content are also configurable.
CRUD and flexible storage
Forms bind to a table and record identifier to perform inserts, updates and deletes. Alongside conventional database columns, the engine supports JSON fields and dynamic widget records. Real or soft deletion and navigation after operations can be configured.
Business logic around each operation
Synchronous and asynchronous hooks before and after insert, update and delete allow business-rule checks, data transformations or stopping an operation with a message. Change logging and a route to record history are also provided by the core.
Security and access control
Identity, permissions, data scope and input and request protection work together across the core and application layer. Implemented techniques include parameterized queries, server-side validation, anti-forgery tokens and output encoding.
Identity and controller access modes
JWT management and signed-in user information live in the core. The base controller supports public, administrator-only, user-only and combined access modes, making identity information available to panel components.
Granular operation permission model
The model separates view, add, edit, approve, delete, report, history, import, export and print permissions. The form engine consumes supplied permissions to configure insert, edit, delete and history actions and buttons. Permission allocation policies belong to the product layer.
Record-scope checks during retrieval
When loading a record for editing, forms can accept additional conditions such as owner or organization and include them in the query. Developers can check the permitted data scope alongside the record identifier and connect each form to its module's access rules.
Organization scope in application pages
The application layer uses organization or tenant identifiers to limit data. For example, the sales chart aggregates orders for the current tenant. Operation permissions and data scope are complementary parts of administrative page implementation.
Addressing SQL injection with parameterized queries
Parameterized paths in the data layer and form engine separate input values from SQL command text using Dapper or SqlParameter. For example, record identifiers and owner or organization conditions are passed as parameters when loading a form record, keeping those inputs treated as data.
Server-side input validation
Before saving, the form engine checks required fields, permitted lengths and configured patterns on the server. Before-operation hooks also allow product-specific business checks and stopping an insert or update, keeping data checks independent of browser validation.
CSRF protection for requests
The controller infrastructure generates anti-forgery tokens and validates requests. Form and report paths using this control reject invalid tokens. Specific product operations, including password changes and customer data submission, also use anti-forgery validation.
Output encoding to reduce XSS risk
Application code encodes values in selected custom HTML renderers. For example, notification titles and summaries and organization names in some reports pass through HtmlEncode before display, preventing those text values from being interpreted as HTML markup.
Professional reporting and configurable lists
ReportCreate receives a query and column definitions, then generates shared search, data presentation, pagination and export behavior. The advanced panel layout builds on this engine.
Columns and custom rendering
Each column defines its title, presentation, sorting behavior and inclusion in exports. Rendering functions can turn a value or whole row into text, status indicators or action links. Row classes and attributes can also depend on data.
Combined filters and multi-field search
Text, select, multiple-choice, single-date and date-range filters are supported. Multi-field search, default filter values, query conditions and filter presentation can be configured for each report.
Sorting, counts and pagination
Configurable sorting, default ordering, selectable page sizes, result counts and pagination belong to the shared engine. Reports can also supply an external count or disable counting when their requirements differ.
AJAX updates and advanced panel layout
Results, filters and pagination can update through AJAX. The advanced layout combines general search, a filter panel, action buttons and result counts in a reusable structure whose presentation can be customized in the product layer.
Excel exports and practical adoption
XLSX exports use EPPlus and each report's permitted columns. Payment lists, invoice payment history, wallet transactions, user lists and other panel modules use this infrastructure, with their own queries and settings.
Dynamic charts and analytical dashboards
Dashboard data comes from backend endpoints or page models. Series, labels and values are built from application data, with ApexCharts providing the visualization layer.
Series generated from operational data
For the sales chart, the backend aggregates the tenant's orders by day and sends time labels and values to the interface. The chart is built from this response, including days without sales to preserve a comparable timeline.
Visuals matched to analytical questions
Column charts support comparisons, trend charts show changes over time, donut charts show sales shares and scatter plots relate metrics. Purchase analytics visualize brand sales, customer composition, order counts and conversion rates from system data.
Updates and readable details
The sales chart refreshes through AJAX and a refresh control. Tooltips, number formatting, Persian labels, responsive settings and empty-data messages help make the charts useful in administrative panels.
Connecting charts to management decisions
Sales trends, brand shares, customer-grade performance and the relationship between visits and orders turn operational records into analytical views. New analyses focus on defining metrics, extracting data and configuring presentation.
Development speed and maintainability
The benefit appears in everyday development: general components come from a common foundation and product-specific logic has defined extension points.
Less repetitive implementation
New forms and reports center on field definitions, rules, data sources and presentation. The shared core supplies much of the markup generation, input handling, validation, general data operations and pagination.
Central maintenance and consistent behavior
Shared fixes happen in the form or report engine and reach pages using that implementation. Keeping common logic together makes similar modules easier to review, maintain and extend.
Flexibility for actual product rules
Customizable layouts, rendering functions, data-scope conditions and operation hooks accommodate product-specific requirements within the shared structure. The goal is faster development with organized code that remains practical to extend.