Building an admin with 61ade: field definitions and custom actions

61ade is my PHP and TypeScript framework for building web admin applications. Its source is available free of charge on GitHub. It provides a DHTMLX-based interface with sign-in, permissions, searchable lists and editing forms. Application data, fields and actions can be defined in PHP or modular JSON.

A contact register demonstrates how to build an admin from those components. The example turns shared field definitions into a searchable list and editing form, then adds CSV import and export. I had Codex build the application; the task prompt, relevant code and a working demo are included below.

A shared field definition for the list and form

The contact register needed fields for name, email, phone, company, city, address and notes. In 61ade, the list and the form use the same field definitions. These three fields come directly from the example's code:

new Field('name', 'Név', required: true, max: 120,
    column: ['minWidth' => 190]),
new Field('phone', 'Telefon', max: 40,
    column: ['width' => 155]),
new Field('city', 'Város', max: 100,
    column: ['width' => 140]),

SqlResource connects these definitions to the database table holding the contacts. Labels, length limits and required fields come from a shared definition; the library renders the table and form. The agent did not need to build a separate table component, editing dialog or save mechanism. Search, column filters and sorting also belong to the existing list view.

This provides a starting point for another admin application too. An equipment register, for instance, could replace contact fields with an inventory number, type and status. Its database table, field definitions and rules would need to be designed; 61ade would still provide the common foundation for the list and editor.

The prompt and development environment

The agent had access to the library, a working PHP environment, documentation and skills for using 61ade. The task explicitly required it to read those materials and use the library's existing interfaces. Sign-in, permissions and file uploads therefore had an established system to fit into.

The prompt specified the application decisions: which fields were required, what made a contact unique, and what importing should do. A known email address meant an update; a new address meant a new record. Any invalid row had to leave the address book unchanged. These requirements gave the agent both the rules for its custom handlers and the criteria for checking the result.

Below is the original task prompt in English. Its environment section belongs to this project; elsewhere, the library location, data directory and test URL need adapting. It requires an agent that can read source, modify files, run commands and exercise the application in a browser.

Relevant shared rules: Establish the working context; Project and platform boundaries; Placement and data handling; Project URLs; Minimal implementation; Implementation, validation and completion.

Build a working Hungarian contact-register demo with the existing 61ade library in this PHP project. Read the project's AGENTS.md and 61ade's 61ade-consumer and 61ade-application skills first. Use the library's actual documented APIs and existing examples; do not change the library.

Environment: the application belongs in public/contact-demo/ in the sanch.hu project. Keep private PHP implementation outside the public webroot, under includes/contact-demo/. The read-only library is /space/share/libs/61ade; link only packages/php outside the public webroot and packages/frontend/dist in a dedicated public assets directory. All SQLite files and persistent demo state belong under /space/share/data/sanch.hu/contact-demo/. Use the managed development URL https://dev.sanch.hu/contact-demo/. Do not deploy or change server configuration.

The application must do the following:
- Use 61ade's sign-in, shell, table, forms, validation, registered actions and permission checks. Do not build a second admin framework or a separate login system.
- Provide a Hungarian contact list with search, column filters, sorting, creation, editing and deletion. Fields: name (required), email (required, valid and unique ignoring case), phone, company, city, postal address, notes. Give the app a clear Hungarian name and useful empty/error states.
- Import a UTF-8 CSV file with the columns name,email,phone,company,city,address,notes. Accept a UTF-8 BOM and comma or semicolon separators. Validate the whole file before writing; on error report row numbers and leave the address book unchanged. Update matching email addresses and insert new ones. Show inserted/updated counts. Limit imports to 1 MiB and 1000 contacts. Reject ambiguous headers, malformed rows, duplicate emails within a file and invalid email addresses. Use a transaction and the framework's registered-action authorization/audit path.
- Export the current address book as a downloadable UTF-8 CSV with the same columns and BOM. Properly quote values and neutralize spreadsheet formulas. Make the export importable again; document any deliberate neutralization of unsafe cell values. Provide a downloadable sample CSV with clearly fictitious Hungarian contacts at reserved example.test email addresses.
- This is a publicly linked practice demo, not a shared real address book. Each visitor gets an independent SQLite copy of a prepared sample database; the SQLite file and session state remain outside the webroot. Use the 61ade demo login demo@example.test / 61ade-demo, with only contact-management permissions, and display these public demo credentials on sign-in. Explain briefly in Hungarian that the data is temporary and only fictional contacts should be used. Expire abandoned workspaces after 24 hours, with bounded cleanup and safe handling of active workspaces. Do not run schema migrations in HTTP requests: prepare the template explicitly from CLI, then copy it for visitors.
- Keep all server operations behind framework authorization and CSRF protection. Bound inputs and escape displayed values. Never expose private data, secrets, whole library source trees or SQLite files through public links.
- Use supported 61ade components and extension points for the import/export UI. If generic CSV tooling is missing, implement the smallest contact-specific registered handlers and project module, record this boundary, and report actual framework defects separately without patching 61ade.

Finish the implementation, initialize the demo data, and exercise it with Playwright on the managed development URL. Verify sign-in, CRUD, valid CSV import, rejected CSV with no partial writes, duplicate-email behavior, export/re-import, Unicode/quoted cells, spreadsheet-formula neutralization, unauthorized access, and isolation between two browser sessions. Fix application defects and rerun the affected checks. Preserve existing unrelated work. Record the exact checks, limitations and actual framework issues in the project's documentation. Retain a short setup/run guide and the sample CSV. Report what the library supplied and what application code you had to write; do not invent a time saving or claim the first attempt passed if corrections were needed. Do not deploy.

The contact register specification

The task: try 61ade by building a contact register.

CSV import and export through 61ade actions

CSV import and export show how this foundation can be extended. The contact import rules required custom code, but the operations were registered with 61ade. Its uploader receives the file; execution uses the shared authorization and audit path, with a transaction for the import. Export returns the completed file through the library's download response.

The application's own responsibilities are easy to identify: the database table and fields, email uniqueness, CSV processing, and separate temporary databases for visitors to the public demo. None required changing the 61ade source. For me, this is the strongest part of the example: ready-made admin functionality and task-specific behavior fit within the same system.

Contact management, CSV checks and demo

After implementation, Codex used Playwright to check sign-in, contact creation, editing and deletion, search and filtering. In the import check, one file updated an existing record and created a new one. Another file containing an invalid row was rejected in full, leaving the address book unchanged. Export, re-import and data isolation between two visitors were also checked.

The checks led to corrections in the application's CSV error messages, alignment of email validation between the import and form, and fixes to the demo's file access and session handling. All four cases in the final focused Playwright run passed. No confirmed framework defect was found in this implementation.

Try the example application built with 61ade
Sign in with demo@example.test / 61ade-demo. This development demo gives each visitor a separate temporary address book; use fictional data. Downloading Minta CSV and importing it again yields 0 new, 4 updated for the four initial records. Export prefixes cells that could be interpreted as spreadsheet formulas with an apostrophe. That prefix remains on re-import, including for phone numbers beginning with +.