Forum OpenACS Q&A: Customisation Parameters of OACS Site

1: Customisation Parameters of OACS Site

Posted by Christian Eva on 10/08/02 03:10 PM

Dear Community 
I am just starting to build my first proper OACS project based on 4.6. 
I played a bit around and got the first prototype running on my test platform. 
What I'd like to do is to fork a copy of my test site on to the online testing site in order to share it
with the
customer and all the people involved (using the bboard etc). I have several subsites with different
permissions and functionalities etc. 
 
I use a fresh directory for the OACS tree and use lndir ../openacs-4 to link it with the CVS tree and have
a separate dir for my own (changed) files (templates, index pages etc) which I link into the project tree
before applying the the openacs-4 tree: lndir ../myoacs.

This works fine, so after a CVS update I remove my links and apply the above lndir's. 
 
Now my question: Would there be an easy way to offload all the customisation done in the DB say into an
OACS-acsii-parameter file, which then could be edited and applied to the production site, so that not all
the customisation has to be entered again manually?
 
Thanks for suggestions from those of you having created several custom projects!
 
Christian Eva

2: Response to Customisation Parameters of OACS Site (response to 1)

Posted by Tilmann Singer on 10/09/02 02:21 AM

I am not sure I understand what you are doing with linking, but would advise you to look into cvs vendor importing if you have not done so yet, as described e.g. here: http://pinds.com/acs-tips/openacs-setup, and here: http://eveander.com/arsdigita/asj/version-control/ and here: http://eveander.com/arsdigita/asj/cvs

How to preserve customizations to the DB is not really easily solvable, as you might propably want to preserve some things and others not, e.g. you want to always mount forums on a certain node but don't want to also copy the test forums that you created on the development server. Otherwise you could just do a dump of the database at a certain point and restore it on the new install.

Package installation, site node creation, mounting etc. could be automated by writing a script that calls various procs like for example site_node_apm_integration::new_site_node_and_package to mount a package etc. In that script you could also set package parameter values, create users and groups, assign permissions and lots of other cool stuff. I once started to write such a script for a specific project, but stopped at a point where it required a server restart after a certain package installation and the effort to solve that did not justify the benefits, as the project would not get reinstalled from scratch _that_ many times.

It would be cool though if there was some thing that could automatically generate such a script based on a running OpenACS configuration, with a clear structure and descriptive comments in it to make it easily customizeable. Has anybody looked into doing something like that already?

3: Response to Customisation Parameters of OACS Site (response to 1)

Posted by Tilmann Singer on 10/09/02 03:01 AM

Oops - the answer is yes: https://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0006Vq (Request for Comments and Discussion: Building a Leaner, Meaner OpenACS with MIST)

4: Response to Customisation Parameters of OACS Site (response to 1)

Posted by Christian Eva on 10/09/02 06:10 PM

Tilmann, thank you for your replies.

First point, lndir: Thanks for Lars's tips, I checked them before. As i am not very familiar with CVS i preferred my very simple linux based approach: The lndir command creates a 'shadow tree' with sym links to the actual files. I make basically a merge with my own files and the CVS tree for openacs-4. For the productive version my merged tree is then cpio'd over to the production area. This is all done in a simple shell script and works well.

Customisation: To be honest I looked before at the thread but got put off by searching between all the flames. Yes in Ben's paper i found the configuration script. If you can configure the parameters in the same way, that would about be what I am looking for.

Indeed it would be very cool if you could generate a customisation script from a running ACS installation and maybe store it in XML.

The DB issue remains, for that every package should have somewhat standardised import and export scripts for the metadata and separate for the userdata: could be a 'link' on the sitemap like 'set params' where appropriate: export data, import data.

You mention, that you had started writing a script for the site node creation and mounting. If you still can find it I would maybe look into it, as I am not yet familiar with the API.

5: Response to Customisation Parameters of OACS Site (response to 1)

Posted by Tilmann Singer on 10/09/02 06:44 PM

That's really all there is so far, don't know if that works at all right now, and don't take this as recommended way, I just looked in api-doc for procs that do what I need:

ReturnHeaders

apm_ns_write_callback "Installing packages

"

foreach package_key { file-storage, directory, general-comments, forums, notifications, acs-mail-lite } {

    set spec_file "[acs_root_dir]/packages/$package_key/$package_key.info"

    set version_id [apm_version_enable [apm_package_install -load_data_model 
                                            -callback apm_ns_write_callback 
                                            $spec_file
                                       ]]

    set main_site_node_id [site_node::get_node_id -url "/"]
    set main_site_package_id [site_node::get_object_id -node_id $main_site_node_id]

    site_node_apm_integration::new_site_node_and_package -name $package_key 
        -parent_id $main_site_node_id -package_key $package_key 
        -instance_name $package_key -context_id $main_site_package_id

}

apm_ns_write_callback "
Done.

"