Hi Brian,
The approach I use is to keep everything server-side as much as possible, for the usual reasons:
1.avoids/reduces compatibility issues between browsers
2.issues that develop are server-side, and easier/less costly to diagnose when there is a variety of client browser technology
3.reduced full stack size and number of components
The trade-off is that everything necessary is processed server-side, thereby placing a considerably lower upper-limit on active users per processor. Optimizing the code could reduce any process bottlenecks. For the intended applications, this is an acceptable limitation.
CSS is relied on for consistent, customizable UI.
Browser implementation of smart html5 input tags and form rendering helps to reduce any need for dynamic/javascript input that also tends to adversely affects accessibility measures.
From an interactive perspective; Common "best practices" or conventions apply:
If something doesn't validate, the form is presented with the revised input values.
Inputs are quoted by default, then re-unquoted if the form doesn't validate.
From a coding perspective, additional features are included by default, or as an option. For example:
The code audits input as to reduce any tampering.
Extraneous info is "unset" ie ignored and it's memory released. The info can be accessed before processing, when needed.
If the form input detects tampering of hidden values, the form is reset.
Procs that might contain sensitive user input (such as these ones that may be used to convey credit card info) are defined within the standard namespace, where values are always cleared before use. Otherwise, they are defined in a dedicated namespace per coding standards.
A hash feature can be used to automatically screen out inputs not generated from a server-side rendering of the form. This reduces spam and may be used as a security feature.
Versioning uses an incremental number instead of the classic development of major/minor number/type numbering that often begins with "0.1d", because if a package is significantly different, it's probably appropriate to give it a new name. This way, package developers can expect that any updates will not break anything, only fix bugs or add features.
Is this what you mean by approach? If not, rephrase and I'll try again 😉
cheers,
Ben
