Forum OpenACS Development: Re: GUI Redesign of OpenACS, ]po[ and Others?

Collapse
Posted by Maurizio Martignano on
Dear Ben,
I believe that comparing something like
http://johnpolacek.github.io/expressive-css/
to something like
https://www.oracle.com/webfolder/technetwork/jet/index.html
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.
Maurizio
Collapse
Posted by Benjamin Brink on

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.

Also, javascript should be avoided for improving visual rendering, and yet is okay for client-side input validation when html5/browser cases are not adequate.

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?

https://next-scripting.org/xowiki/getstart#hello
https://next-scripting.org/xowiki/docs/nx/nx-migration/index1

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.

cheers,

Ben

Collapse
Posted by Benjamin Brink on
And if one were to take on refactoring of OpenACS into NSF, there are other shortcomings that would be strategic to address at the same time.

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.

cheers,

Ben

Collapse
Posted by Malte Sussdorff on
Three days ago I had a discussion „how to make ]project-open[ backend development ‚sexy‘“. And I did think of just using NSF for this. Or at least for all the endpoints which we code for the (typescript) frontend. but then I thought... well, not a very commonly used sexy language either.

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 😊.

Collapse
Posted by Benjamin Brink on
Hi Malte,

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! 😉

cheers,
Ben