Forum OpenACS Q&A: How much programming is needed before site is "useful" ?

Before I set up a system to play with OpenACS, I'd kind of like to
know how much Tcl/SQL hacking is required before a newbie can get
some form of satisfaction from his/her experiments.

To define my newbie status: I know nothing about Tcl, next to nothing
about SQL, but I do know my way around HTML and have built a couple
of pretty neat sites using Lotus Domino.

I'd love to get into the ACS stuff, because even though Domino is one
web solution, there *are* things that ACS handles way better for the
kind of sites I usually do/like to do.

So, after I install-and-get-to-start-up, will I have a demo site or
something to look at in a browser (as a user, not admin pages)?
Basically, is there some sort of index.tcl to look at and go from
there?

TCL is simple to learn if you know a programming language already.  It took me about a day to learn the syntax.  I would suggest either going to an Arsdigita boot camp or doing the home study program.  The courses will guide you through using TCL, SQL and ACS.  I'm doing the home course right now and I find it useful.  It's better than trying to piece together how to use the package from the documentation.

Here's the link:  http://photo.net/teaching/boot-camp.html

After you setup ACS, you will have pages that people can access.  It's plain and text only, but it is fully functional.  I tried out a few of the modules like the bboard and the classified ads.  It's good stuff =)

Enjoy!

To expand on the earlier answer, most of the modules are fully functional without any programming effort.  Programming or template modification (HTML work on .adp pages) is necessary to change the look and feel other than header/footer changes (adding decoration to the top of a page, etc).

Still, though, you can set up bboards, ecommerce, news, classifieds, etc without writing a single line of code, merely by editing the ad.tcl initialization file to reflect your installation.

The result will look a lot like this site, or the bboard, etc portions  of photo.net.

Where programming's really needed within the current framework is to either add new functionality or to complete functionality that's not been generalized to the full toolkit.  For instance, user groups are really useful but only a few modules make use of them.  Likewise general permisssions.  aD keeps working on this, and this general shortcoming, plus the need to modify .tcl scripts to change look and feel for untemplated modules, have driven much of the discussion on general architectural issues here at openACS.org.  Ideally all grouping issues (which groups of visitors see what features, who can read or write to various forums etc) should be abstracted out as should SQL and presentation issues.

We're in a similar situation, Joerg, although we have a bit more background with SQL. If you look at our site you'll see that we have implemented only a small part of the OpenACS functionality with some relatively minor changes. As you have heard so far, turning on default functions (once your system is installed) often requires no programming at all. So for example, a complete non-programmer (like me) can create a new bboard and set its characteristics from a web interface. Other changes require minimal futzing with .ini files and the like, which shouldn't be too intimidating for you if you've had to keep, say, a Win95 machine running for more than an hour at a time. 😉

However, be warned that even seemingly minor changes can turn out to be major headaches. Part of this is inherent in programming, but much of it is because ACS (and therefore OpenACS) is not well abstracted in a lot of areas. The most frustrating part for us has been not being able to anticipate what's going to be hard to change. Again, the problem is not that tcl or SQL is hard; the problem seems to be mainly with the way ACS is wired together.

Fortunately, OpenACS has a truly fantastic, supportive, smart community associated with it. In some ways, the community has been more valuable than the software itself for us, because they have made it much easier for us to solve our problems quickly.