Forum OpenACS Q&A: Don't understand "big picture" of what to do

I installed the system and spent a few days reading documentation, FAQs, and tutorials. I understand concepts like separating TCL code from presentation, etc. But I don't understand the "big picture" as far as how to build a website.

1. What am I expected to do to build a website? Take the default "ACME" site and modify it to be my own site? My first guess was "yes, that's what this product wants me to do," but I'm not sure.

2. Are packages supposed to be the "website" (in other words, do I create a website by building a package which implements the entire website) or are they just pieces or components of a website, which I use to build my own?

Thanks.

Also, the installation includes a many defaults (styles etc), which are then customized.

Each row in /admin/site-map is a mounted "instance" of a package.

1. The Main site is the defacto default subsite. Don't delete it. The internals of OpenACS are more consistent by making the main site an instance of subsite.

2. One common method of customizing an instance is by changing parameters.

3. display templates are customized via parameters in an acs-subsite instance. Changing parameters for one acs-subsite does not affect the others. There's a new way of using generalized template themes with ACS 5.6, but I don't have any experience with it yet (so I can't provide insight). Check out the parameters in the section "Navigation Tabs", "Templates" and "Theming"

cheers!

Torben

Sal,

Yes, that is correct.

An example of when OpenACS's subsite functionality can be useful would be as follows:

You are an international hotel chain with a corporate main website and a dedicated website for every hotel you own. Some of these use different languages, some use different character sets and all have their own sets of registered customers.

Any customer can potentially be a guest at any hotel, and whilst some employees may only need access rights within their own hotel website, many of the country and worldwide managers need to be able to access the website of several hotels or even all of them. The MD of the whole organisation needs access to everything.

In this situation, there are a number of ways that openacs can facilitate. Here is one:

You set up a domain name for your hotels group (let's say 'internotels.com'), and you set that up to resolve to your OpenACS 'Main' subsite. This becomes your central corporate website with shareholder info etc.

Because your hotels have fully delegated marketing, you now set up an individual subsite for each hotel, and delegate the admin rights to the individual employee at each hotel who is responsible for it.

The hotels can now operated independently, and you have centralised overall control (technical updates, new capabilities, admin, security, data, intellectual property, central marketing and access/control of customer database and lists).

Each of the subsites can be run as independently or non-independently as you wish. They can each have their own domain names, or operate as a url within the internotels.com
domain. Alternatively you could set them up to be resolved as onehotel.internotels.com, otherhotel.internotels.com

OpenACS is about flexibility and integration.

I hope this simplified example will help.

Have a look at the worldwide Greepeace website for an example.

Regards
Richard

An installation is capable of any purpose, demo, admin or developer tool etc.

The application code is in /packages

For upgrading purposes, it's best to think ahead. Put static files in /www/resources or somewhere in the /www file hierarchy and put new procedures etc in their own files. This way, when updating, you are not overwriting your customizations (as much).

A general rule for extending tables is to create your own tables and use a common reference from the existing one, such as object_id to join them via queries. This way, any modifications you make are unlikely to be affected by changes to the core system. There are advanced CMS db features available via the object database such as revisioning etc, but those features are not fault tolerant if used in a nonstandard way. It's best to have a test system running to implement changes you aren't sure about their impacts to the system. It's good experience to build the test site from a backup of the live site to verify your backup procedures work. Always make a backup before changes so you can revert if need be.

cheers,
Torben

Thanks Brian, I will check out the contacts package.

Still having a few problems understanding this. For instance, in trying to implement the functionality that I hope the contacts package will do for me, I created a subsite, which I then wanted to customize. My thinking was that sub-directories would be placed somewhere, and files copied there, which I could then modify in order to customize the subsite. Of course, this didn't happen (no sub-directory anywhere) so I was largely at a loss as to how to customize. I guess there is something fundamental I am failing to grasp.

Thanks again!