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

4: Re: Re: New openACS user...confused (response to 3)

Posted by Sam Nicholson on 02/22/06 09:35 AM

This needs illustrating in the docs. The *only* way I found it was by tracing the executable while giving it non-extant uris.

If one creates a subsite, say newsite, and mounts packages foo, bar, and baz at that subsite, then the following uris will be valid:

www.site.dom/newsite
www.site.dom/newsite/foo
www.site.dom/newsite/bar
www.site.dom/newsite/baz

while the uri, www.site.dom/newsite/zot will not be. No surprise so far.

Now, create the dir /www/newsite and edit therein the file zot.adp, and voila, www.site.dom/newsite/zot is no longer 404.

What this all means is that uris reference files until a uri pattern matches something stored in the database. Then the magic works.

I'm still of the opinion that creating a subsite should make the appropriate dir in /www. And that removing it should optionally remove the dir. But I can script around this.

Now, if I can figure out how to move /www out of the oacs dist filestruct, I'm golden.

Cheers!

5: Re: New openACS user...confused (response to 4)

Posted by Jim Lynch on 02/24/06 02:42 AM

Sam,

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.

6: Re: Re: Re: New openACS user...confused (response to 4)

Posted by Jim Lynch on 02/24/06 03:05 AM

Sam and David,

If either of you are interested in looking under the hood of openacs a bit and don't mind getting your hands dirty and editing some files in your favorite text editor, might I suggest the developer tutorial?

It shows a bit of how openacs works and how to create a package, mount that package, write scripts that install and remove the data model for that package and how to prompt the user and store and retrieve results.

Customization of openacs much beyond creating and mounting apps, setting parameters and granting permissions requires programming, and that's what the tutorial introduces.

7: Re: Re: New openACS user...confused (response to 5)

Posted by Sam Nicholson on 02/25/06 07:59 AM

Surely, and sometimes what is needed is a plain webserver. Sometimes, a scripted server, and sometimes a full blown content manager. Very few organizations can effectively support more than one webserver. So please don't be offended if sometimes I use the Swiss Army Knife to just cut a string.

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!

8: Re: Re: Re: Re: New openACS user...confused (response to 6)

Posted by Sam Nicholson on 02/25/06 08:34 AM

The developer tutorial is appropriate for just that: developing packages. There isn't a tutorial for *using* OpenACS. In fact, a great frustration that I have is that to *use* OpenACS, it is a bit difficult to follow the directions, and still *use* my favorite text editor. This forum is a classic example. I'm using a screaming hot computer, running Solaris, with vendor supported emacs (Wahoo!) on the side. And yet I'm typing this note in a tiny screen, and wondering how it will turn out! Troff, anyone? This is akin to the suggestion in the docs to create a home page for your brand, spanking, new OpenACS install by firing up ETP. And even then, there is no suggestion as to what to put in This Edited Page. FWIW, the acs-templating guide doc/acs-templating/demo/ is most helpful. But it's hidden in the docs.

Hey, my hands are filthy with OpenACS muck on them. And I still feel that it's the best thing going, all things considered. But the standard kit has a few nits, that if fixed, would make the kit much easier to grok for a wider user base. And yes, by fixing, I mean easing the use of the OpenACS as plain webserver as needed. Really, there's a tremendous amount of high-quality, ready-to-run code in the OpenACS kit. One ought to be able to just use it.

But, as I noted above, I've got my workaround. And on Monday, I'm going to show a static website developer how to add an OpenACS forum and journal to her website, and neither one of us will program a thing!!!

Cheers!

9: Emacs and web browser text boxes (response to 8)

Posted by Andrew Piskorski on 02/27/06 07:01 PM

Sam, you are an Emacs user, yet by choice you type your Forums posts into your browser edit box rather than in Emacs? That seems wacky - I just copy and paste from an Emacs buffer. If someone really cared to, it's probably possible to write some sort of fancy Emacs mode and/or Firefox plugin to improve on the text editor / web browser interoperation, but plain copy and paste works well enough.

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.

10: Re: Emacs and web browser text boxes (response to 9)

Posted by Sam Nicholson on 03/07/06 11:12 PM

Heh, Would that all the world had a .el interface!!! I generally use what's at hand. The context switch is too great when I'm reviewing a set of posts to switch over to emacs and then back to the web browser.

Forums are nice as a record of a specific conversation. Email lists are better transport mechanisms for those conversations, I think.

I'd propose a solution, but you beat me to it in this message: http://www.openacs.org/forums/message-view?message_id=389793

And very nicely, too.

Cheers!