Forum OpenACS Q&A: Peeking at openacs.org source/verbatim...
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?
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.
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.)
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.
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 openacs.org 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...
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
openacs.org, 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.