Greetings!

We have installed some Modules as part the Application required for our Foundation, a Give-Away-Shop.
some worked as installed, some missed functions used, etc.
got it all working now.

We would like discuss the 'need' for Coding-Standards.
the reason being to have Variables with same Size and Naming, to have them same among Modules in Module-Market.
the why for this is to have the modules same structure, so they can fit together.
when this is the case We are sure it will help in making Trongate-Framework more used, not just private but also corporate (for/not-for profit).

some examples:
the use of Primary-Key and Foreign-Key, the FP are sometimes not same as PK.
trongate_users; PK trongate_users_id
trongate_administrators; FK trongate_user_id
trongate_members; FK user_id
trongate_tokens; FK user_id
login_sessions; FK trongate_user_id
trongate_pages; FK created_by (which in cases like this is practical)
members; FK trongate_user_id

the code variable seems have different sizes:
members; varchar(16)
trongate_comments; varchar(6)
trongate_users; varchar(32)
trongate_tokens; varchar(3)
news; varchar(6)

We made changes to several sizes but leave them open to discussion.

the use of tinyint(1) or boolean.

then theres the point of Hard and Soft Deletes.
with Hard Deletes there is no History for Logging and Reporting.

which brings Us to Separate-Tables used for CRUD History, by Who and When and Why.
this would mean heaving a Separate-Screen for Admin.

it seems we have to accept Admin have a separate table, if only because no 'members' has been installed.

probably We missed some, but this gives 'others' the option add to discussion.

also, We hope the Modules get Updated-to-Perfection.

again, We hope there could be some discussion,
to (Co-)Create many Modules/Applications,
to make Trongate more used …


thank 'you' for testing 'me',

your Humble Servant.

Thank you for your post and for sharing your experience with the modules for your foundation’s give-away shop. It’s great to hear you’ve resolved your issues and everything is working as needed. Below, I’ll address your key points about coding standards and database schema consistency, keeping in mind that stability is Trongate’s top priority, and changes to the table schema are only considered for critical bug fixes.

Primary and Foreign Keys - you highlighted inconsistencies in key naming, such as:

• `trongate_users.id` (primary key)
• `trongate_administrators.trongate_user_id` (foreign key)
• `trongate_tokens.user_id` (foreign key)
• `trongate_pages.created_by` (foreign key)

While uniform naming (e.g., always `trongate_user_id`) could improve compatibility, the current variation supports clarity and flexibility. For example, `created_by` reflects its purpose. Given our focus on stability, altering the core schema isn’t an option unless a bug demands it.

Code Variable Sizes:

• `members`: varchar(16)
• `trongate_comments`: varchar(6)
• `trongate_users`: varchar(32)
• `trongate_tokens`: varchar(3)

These differences are deliberate, and tailored to each module’s needs. Standardising sizes might waste space or restrict functionality. Stability and performance outweigh the benefits of uniformity here, so no changes are planned.

`tinyint(1)` vs `boolean`:
You asked about `tinyint(1)` versus `boolean`. Trongate supports MariaDB (commonly used over MySQL), where `tinyint(1)` is standard for boolean values (0 = false, 1 = true). This ensures compatibility and works seamlessly with `Model.php` PDO bindings, so no adjustment is needed - (check out the get_param_type method—it maps booleans to `PDO::PARAM_BOOL`).

Hard vs Soft Deletes:
You raised concerns about hard deletes losing historical data. Trongate’s default is hard deletes (e.g., `DELETE` in `Model.php`), but soft deletes can be implemented by:

• Adding a `deleted_at` column (e.g., `int(11)`).
• Filtering out records where `deleted_at` is not null.
• Updating rather than deleting records.

For logging CRUD actions, you could add a `change_log` table. These are left to developers to customise, as simplicity and stability are Trongates' core priorities.

Separate Tables and Admin Screens:
The `trongate_administrators` table is already separate from the optional members module. For history tracking or admin features, you can create additional tables and use `Model.php` methods (insert, update, etc.) to manage them.

Community Contributions
While core schema changes are limited for stability, you can:

• Build modules with your preferred standards and share them on the Module Market.
• Create a soft delete or history logging module with admin interfaces.
• Your contributions could enhance the Trongate ecosystem.

Conclusion
Your ideas about coding standards are thoughtful, but Trongate prioritises stability and flexibility over uniformity. Schema variations are intentional, and changes are avoided unless critical. Adapt modules as needed for your project, and consider sharing your work to benefit the community.

Cheers,
DaFa

its good have stability, however, it be better have improvements/perfections as well, reason being to attract more users for trongate.
when watching the vids of david, while doing some live-programming, they are made on-the-fly, meaning not all is same in other situations, meaning differences can be introduced.
many this live-programming ended as modules.
he does mention to check for these and report.
now, considering your reply on stability, does this not mean making any changes in modules, as to perfect them, considering future users?
for same reason could be good idea, for stability, to have some 'standard' on varchar-lenght etc, or just make all varchar(255), mmmmmmmm.
there is another option, having Versions in modules, with a Description of changes/additions.
also could have extra methods using current methods, so all be happy.
We wonder the opinion of others on these subjects as well ...

Stability is a cornerstone of Trongate, but we also value enhancements and fine-tuning to keep the framework thriving. Our “v1 forever” philosophy doesn’t mean the framework is static—far from it. Trongate is updated regularly with new features, bug fixes, and performance tweaks to stay current and robust. However, these updates are carefully crafted to avoid breaking changes, ensuring that existing applications remain reliable and developers can trust the foundation they’ve built on. Proposals like renaming primary and foreign keys or standardising all `code` fields to `varchar(255)` would disrupt this balance, breaking compatibility with current setups and clashing with our core commitment to stability. Such changes would force users to overhaul their databases and code, undermining the dependable experience we aim to provide with every update.

that sounds well, however, some posted modules could have been deleted.
also, how many people do you think Really have Implemented these Modules, on-line?
should not there be Staps-to-Perfection, at least in Modules?
dont you think these people would Appreciate said Perfections?
having a Stable-Base is ok but may need some Additions.
such as some Helper-Functions for DB, perhaps a Fist and Last.
to be In-Dependent of External-Libraries it be nice if there be some more Date-Time functionality, such as ability define what Dates/Times may be Selected, such as for Making-Appointments or Delivery-Date/Time.
what is Life with-out Change, when Able Create a Pattern-Change ...

I’ll respond to your points one by one to keep things clear. Since English seems tricky for you, I’ll try to make this simple and direct.

1. “Some posted modules could have been deleted”

Your first point confuses me. Are you talking about the Trongate Framework (its core code and database schema) or the Module Market? All my earlier answers were about the Framework—its tables, keys, and stability. If you mean the Module Market, please say so clearly. Otherwise, my points stand: stability is the priority. Changing primary keys (PK) and foreign keys (FK) just to “look nice” would break things for no good reason. That’s not smart—it’s reckless.

2. “How many people Really have Implemented these Modules, on-line?”

You ask about “Modules” again, but I’m unsure what you mean. Trongate is over 5 years old, and many live websites use it—real projects, online, working fine. Do you mean “Modules” from the Market, or do you mean “websites” built with Trongate? Your words aren’t consistent, so it’s hard to follow. Either way, these developers and site owners rely on Trongate staying stable. If we made big changes—like you suggest—they’d be upset. Breaking their sites for “perfection” isn’t fair. Steps to improve are great, but not if they destroy what already works. What do you think those users would say?

3. “Stable-Base is ok but may need some Additions”

Now you talk about new ideas: helper functions for the database (maybe “First” and “Last”?), and more date-time features (like picking dates for appointments or deliveries). This part is off-topic from your first post about keys and sizes—it’s a whole new direction. I agree life needs change, but Trongate already grows carefully. We add features all the time—check the updates!—without breaking what’s there. For your ideas:

• Database helpers: You can make these in your own modules. No need to change the core.
• Date-time stuff: Trongate keeps it simple and avoids external libraries, but you can build a module for this too. Share it if it works!

Your last line about “Pattern-Change” sounds poetic but doesn’t explain what you want. Can you give clear examples?

I get that you want Trongate to grow and be “perfect.” We all do! But stability keeps users happy, and big changes to the Framework (like PK/FK names or sizes) would hurt more than help. Get involved with the community - create modules and share them on the module market. That is growth.

thank you Brother.
We appologize for Our bad use (ab-use) of the English-Language.
knoweth We are from a Different-Universe (Royaum Sans Frontieres).
We are As-King;
does any on this site have a Different-Opinion?