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

Howdy devs,

Two new packages are available, via or via

Q-Data-Types (new)
Q-forms (updated with new features)

These packages, with Q-wiki (a refactoring of ecommerce package's templating system), provide a library of procs that simplify the development of new packages and one page apps.

Your input is greatly appreciated as these will be used to port sql-ledger to make a new ecommerce package suite for example.

best wishes,


Oh, just realized I neglected to include a reference to two demo pages in the Q-forms package.

See q-forms/www/admin/test-qfo_2g-a
and test-qfo_2g-b
These two pages need to be moved to somewhere else in an OpenACS instance to test, since Q-forms is a service-only package.


There's a typo in the filename I posted.

Anyway, here's the demo/test forms in action:

With just one flag, the form can switch between presenting checkboxes or "select multiple" options. And, switch between radio and "select" options.
It also detects doctype to generate html5, html4 or xml.

Accessibility features are chosen by default, if not provided.

Here are the component files, to show how form cgi code has been reduced to a little bit of declaration:

I haven't had the need to use the INPUT tag, type="file" yet, so haven't checked that yet. Most everything is backed by unit testing by design.

best wishes,


Looks like these demos required permission to access at the site. --Not very helpful.

The permissions have been removed on these urls, and remain within the www/doc of the package for security purposes.

Sorry if this has been an issue for you. I wasn't aware until now.

best wishes,

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.


Should someone audit the and wonder why certain design anti-patterns were used, here's why:

While building this one page app paradigm, some design anti-patterns were useful, albeit their use would not be needed in refactoring the code, should that be needed:

The code is fairly monolithic for this first version of qfo_2g, mainly because I wasn't sure of the subtlety of dependencies early on. It turned out to save a bunch of development time in spite of the concern of dealing with variables outside of their intended use (and debugging), because large chunks of code was moved around, and redundancies could be eliminated through selective variable re-use.

The q-forms tag building procs (qf_*) used a somewhat unique design anti-pattern of consistent variables across all procs (within the paradigm) and unbroken lines of any length. Most all cases where consistent handling of data inputs, such as html tag attribute handling, could be identified with a simple editor search, and logic kept consistent throughout as features evolved.

The qf_* procs use an anti-pattern of sorts for passing parameters. As a result, parameters can be passed in a variable containing a list of name/value pairs, or as individual name/value list elements, or a combination of the two (mainly for flexibility for end-developer's needs). It seems more flexible and consistent than using {*}args argument expansion ( ), because with this anti-pattern there's no need to be concerned about list parsing in an unexpected way, such as can happen when lists contain some elements with spaces, or a string with spaces is inadvertently parsed into a list.