Forum OpenACS Development: Re: A data types package, Q-Forms now has a quasi-event handler web ui

Hi Ben,

these look interesting - I will try to find some time to take a look. What approach have you taken to one page apps?

best wishes

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 😉


Thanks Ben,

very interesting! When I hear the phrase, single-page app, I think of something like Facebook or Gmail or frameworks like React which are obviously very Javascript intensive. So I was curious to see how you would have designed something like this within the confines of the OpenACS.


I see. Thank you for asking.

Here, 'single page' is about reducing complexity that often accompanies an object-add, object-edit object-view multi-page paradigm in OpenACS.

An OpenACS package that manages multiple objects would be expected to have at least one page per object. A page provides context for end-user, so design is a matter of user experience preferences and the amount of complexity a developer wants to dedicate to a page.