Forum OpenACS Q&A: Re: New openACS user...confused

Unlike say Zope, OpenACS does not lock you into any strange object storage system, you can use the file-system in any way you wish - if you wish. It is not a case of, "everything must be in the database".

Generally, with OpenACS, if you are manually editing files on your Production web server, either: One, this is an exceptional case and you know exactly what you're doing and why. Two, you don't know what you're doing.

There are also files, not in CVS, which are created by OpenACS itself, which you would never edit. Files uploaded to File Storage and then stored in the file system come to mind. But as far as I remember, any files which you the admin would edit, you would edit as part of your development process, typically on your Dev server. (There may be other exceptions I've forgotten, and which hopefully someone will point out, but in general that should be true.)

With having subsite creation make dirs for their subsites, you've just invented a plain webserver... which is not what the -interesting- part of openacs is. Aolserver's capability of allowing the application to interpret the url rather than have hardwired directories is used to add collaboritive features to the site.

Active web sites typically interpret the part of the incoming URL past the http://site.name/ and try to match its pieces in order to allow -active- content. This is what the openacs request processor does... it matches the url to values in the site_nodes table in order to determine (a) which mounted package instance is being requested and (b) which page within that package is desired. Some packages even arrange to interpret their part of the URL either using the database or in other programatic ways.

The request processor acts like an extra decision tree: it answers the question of "should I serve a file that exists in www, or should I look for the page in a package, and if so, which one?"

If it were not for this, the arrangement of packages as they exist now would not be possible, a problem that was dealt with when going from openacs-3.x to 4.x; if memory serves, this was the point at which openacs moved to a packaging system.

The www dir is pointed to in the aolserver config file; consult that file for the correct variable; it could be pageroot. I can't say what the consequences of moving that dir are.

In my usage model, the system administrator is responsible for providing applications (cgi, adp, whathaveyou), and individual website masters provide their own content. So, we need separation of filesystem space to allow for ftp accounts and so forth. Once the administrator has made the subsite, and associated it with the ftp accounts, home dir paths, logfile paths, and so forth, then the site master can choose what to use. If they want to create plain html pages, that's their affair. Of course, they often ask for similar features, and don't care how they are provided, so the OpenACS/AOLserver combo is quite nice.

To me, the *interesting* part of OpenACS is that a single platform can provide support at the basic, scripting, and full-on-bad-mojo level.

Cheers!

Btw, there has been some sort of WYSIWYG-style HTML editor supported in OpenACS for some time. I haven't tried it yet, as personally I like the non-WYSIWYG nature of HTML and similar markup styles.