Forum OpenACS Q&A: Peeking at source/verbatim...

Hi all -

I'm playing with building an openacs site.  To help me I'd like
to be able to look "under the hood" at the openacs site itself -
e.g. be able to see how the home page is coded (etc.).  Is there
a way of accessing/browsing/downloading the verbatim site,
without any server side processing?


- B.

Posted by Jonathan Ellis on
No, but if you have a specific question like, "How did they do xxx?" we can probably help.
Posted by Jerry Asher on
I think Barry's question should be taken to heart, it's something that has been asked for at various occasions for about two years now.

A lot of ACS implementations are documented, um poorly.  It's getting better, but few of us are good technical writers or have the resources to devote a great deal of time to the doc.  The APIs are developed quickly by different people with different vocabularies.  But if a picture is worth a 1000 words, I cannot begin to estimate how useful it can be to see actual data in actual columns and actual rows....

It would be a real feature, it would make implementation much much easier, if there was some demo'd real life site online somewhere that allowed people to peek at (read only) it's underlying database by allowing folks to run arbitrary "selects" against the database.

At a gross level, it would be pretty easy to do to. It would require installing an oacs 4 site with a dummy db and installing a variety of modules. let folks login and use the apps and then have a page that lets folks enter select statements against the db.  I am not expert in pg security -- what are the security implications of allowing arbitrary select statements?

What would be real cool would be a dummy site with a safer version of developer support turned on.

Posted by S. Y. on
Do you mean like surfing to a web site and seeing the raw Tcl code? At one time ArsDigita hosted a browsable repository. You need to set up a second web server (listening on a different port); in the nsd.tcl config file set enabletclpages to false, disable ADPs, and remap both default and noextension to text/plain (I think) in ns/mimetypes (remove all other mimetypes). Naturally, you could use another web server (like Apache) since you're just serving up HTML and what the server thinks is plain text files.

The only time I found any benefit for such a site was when I wasn't on a PC with the ACS installed. But that's just me.

However, there's far more benefit if you create a standalone documentation web server (for guides, the stuff in /usr/share/doc on a Linux box, kernel docs, the ACS code, AOLserver manuals, PostgreSQL manuals, Oracle HTML docs, etc.) and index it with htdig, swish++, whatever. I've done this on my own machine; htdig takes about an hour to spider and index the documentation server and reports viewing over 30,000 pages. (The htdig database files take up something like 300-400MB, but I keep 'em on a slow drive.)

Posted by Jerry Asher on
No, I'm not concerned with the raw tcl code itself, as long as I know which version of the acs has been installed.  I want to see what's in the tables, because it's what's in the tables that describes how a module *really* works, or what others have done to get two modules to interact with each other.

An OpenACS 3.2.5 example: group scoping?  Try figuring that out on your own, it can take hours and hours.  But if you could look at some of the tables in a site that has group scoping already set up, you could probably get a much better idea within the hour.  The same may be true of OpenACS 4 permission or search issues.

Posted by Don Baccus on
In the ACS 3.x world, ACES provides a decent example of the kind of stuff Jerry's talking about, as it provides pre-canned classes, communities and code that creates new ones with component parts like file-storage and calendar.  And lots of portlets to do the same.

That was based on 3.4 which in some ways was a bridge between the past and ACS 4.x (it has packages and a request processor, though packaging of packages was incomplete so things are "blurry" in regard to old vs. new paradigms).  So it would be somewhat useful to someone interested in  understanding OpenACS 3.2 groups etc but you'd have to ignore a bunch of 3.4-isms.

In the OpenACS 4 world dotLRN should help out a lot as it will provide ACES functionality integrated with our latest OACS 4 release.  It will be a real world example of how to use subsites, groups etc to build a fairly complex and integrated site.  There's a fair amount of look-and-feel stuff needed for dotLRN, too, so this should serve as a decent example in that area, too.

So ... Jerry, yes you're right and fortunately dotLRN will help folks by providing a real-world example of how to hack look-and-feel and site structure using the toolkit.  Since MIT has already put up a page for dotLRN, maybe they'd be interested in hosting a dotLRN instance with sample classes and commmunities set up as a demo (they'll have a large example set up called SloanSpace but that only helps if you're going to school there!)

As far as the source to this current site goes, it could be made available but very, very little hacking/customization has been done.  Do a "view source" and you'll see that there's a stylesheet being referenced and some table stuff to control width, set the nav bar, etc.  All that's going into ad_header presumably, which is why bboards don't share that look-and-feel (because bboard has its own header proc for historical reasons).

So the source could be made available but Barry's need is probably met by telling him to 1) play around by hacking ad_header to see how that changes pages in various modules and 2) check out "view source" to see  the html used to build the index page in particular.  This site doesn't do anything fancy with groups, etc so doesn't serve as a good example in the sense Jerry's thinking of.

But ACES and (later) dotLRN do...

Posted by Don Baccus on
The first paragraph of my response makes more sense if you realize that classes and communities in the 3.4-based ACES distribution are implemented as user groups and use the scoping facilities, i.e. exactly the areas Jerry mentioned as being somewhat opaque if you're just reading the source code.
Posted by Andrew Piskorski on
Guys, there's also the ACS 4 API Browser...  Sean, Jerry, and Don and
others have mentioned other, different stuff, but being able to just
read the live code is exactly what Barry was asking for.  The API
Browser let's you read most of what's in the sql/ and tcl/ directories
- basically, almost everything EXCEPT all the individual pages under
the www/ directories.

I assume that once the Musea folks finish the Openacs 4 version of, the API Browser will be there, and it shouldn't be too
hard to extend it a bit so that the site admin can configure things to
let people view the code in the actual pages too.