Forum OpenACS Development: Re: GUI Redesign of OpenACS, ]po[ and Others?
I believe that comparing something like
to something like
is like comparing apples with oranges, from all points of view: e.g.
1. solution breadth: number and type of functions, or if you like, number of problems, needs covered by the solution
2. momentum: see who/what is behind the solution
3. effort needed in implementing not only the styling part but also all the "machinery" required by a web application (and not just a website).
The only thing they have in common is they are both on GitHub.
But I believe also that what you have in mind in terms of what needs to be done, to be achieved is very different from what for instance Frank has in mind for its ]project-open[.
If the goal is to have a "responsive" website than the solution you're suggesting might be more than adequate.
You're right, Maurizio, like apples and oranges.
One has to be careful when adding complexity. A GUI for OpenACS should seek simplicity, because OpenACS historically has issues with overthinking solutions that results in technical debt and artificial limits to what one can do using the framework. By simplicity, I mean:
- Define html forms by declaration of field names, values and data types.
- Have form event-handling use a standardized flow.
- Have code that defines a form take less keystrokes than building a form manually.
- Have form generation code create accessible and responsive forms by default.
- The GUI should make it easy to meet best practices by default, even for the most complex permutation of features.
These are things that ad_form may have intended to solve over time, and yet, complexity abounds. ad_form is avoided instead of used by default. There is a habit of bypassing ad_form by passing variables via urls, which is not good practice. For example, some browsers read ahead to cache pages, which puts more of a burden on the server. By changing these urls to form buttons, browsers (and web spiders) should not follow.
Also, consider re-factoring the table and list display API to default to show best practices in accessibility. For example, one row max for headers.
If one is going to refactor the GUI, why not take a slightly bolder approach with something like Next-Scripting Framework, and really rocket into the next decade?
Code could be written to migrate most code that is not oacs-core. And, since the majority of oacs-core functionality was coded in about a year that should be doable for an endeavor like this. You might actually get more volunteers. Also, according to the documentation, NSF is made for this type of endeavor --unlike OpenACS core.
While one is at it, make the system usable in a container / microservices environment ie cluster mode by default. You may get even more volunteers.
For instance, adding an 'ad_proc' feature that allows overwriting of release code procs with custom ones of the same name using some kind of standardized glob recognizable file pattern, such as *-custom.tcl in the same package, or maybe in sequential order from any package installed that follows core initialization on startup. This would make it easier to keep custom code separate, while allowing complete intercepts of the standard API.
Especially as we don‘t have to code that much backend code in TCL anymore (with the rest endpoints provided) we „sidestep“ the problem for the time being. Especially as this allows us to have people utilize OpenACS first (using the apps with a container running the Backend) and then maybe encourage more people to either write endpoints in NSF or any other language we write TCL code wrappers for. But as I said... first we focus on the Apps .
Yeah, I'm focusing on apps, too. As soon as I have a suite of apps working, I'm going to see about building OpenACS 6.0 on NSF --unless that project starts first, then I'll go with it!