Nima

I could be wrong, but I don't think this will work.

My experience has been to set up different AOL server instances running on different ports, and point each instance to the same database (in the <instance>.tcl file).

If the only reason to have multiple instances is to have different designs, there is a way of doing this, but it is a bit of a hack and will affect performance because it involves effectively turning off the template caching.

It does work, though, and you can apply a different master templates to each community/subgroup and the way I implemented it, you can choose whether child subgroups inherit their parent's template or not.

If you want more details, let me know - although I hope I am wrong and there is another way :)


<Raad>

Install.xml is using during site installation to determine which packages to install initially.  It's not touched after that.  If you want several different "sites" that share a common user database, use subsites.  Create a new subsite for each different department, and use the features of acs-templating (modifying the default templates in each subsite directory) to give them unique appearances.  If you want to run two different, isolated instances on the same computer, you need a separate OpenACS instance (ie, directory tree, config.tcl, database) for each.  You can then give each one a unique IP, or have them share an IP and use different ports, and direct incoming traffic with any of several different virtual hosting schemes.

Hi Joel,

where do I create new subsites? The Site-Map does not allow me to make several copies of the default dotLRN instance on the same level so that I could have something like this:

https://dotlrn.server.de:8443/dotlrn/ default
https://dotlrn.server.de:8443/school1/ School1
https://dotlrn.server.de:8443/school2/ School2

But I guess you mean something else. I don't want two independent instances just multiple for each school with different templates.

Greetings,
Nima

There are several problems we face:

1. How to achieve different designs for different institutions that have the same user base.

2. How to organize the communities and courses separately depending on the school.

3. How to merge that information back for a student who is a subscriber within multiple institutions. I don't think that is possible.

Greetings,
Nima

Nima - you are right in stating the problems that exist should subsites work, however, I don't think they can in any event.

Janine - I missed the obvious! Different instances would present the same communities with different presentation, so that would not be much use unless you started a very messy filtering process - I don't think I'll go there!!
You mention themes, but I guess you mean designs as opposed to the actual .LRN themes, as they only go a little way to providing a custom look.

If people are interested in our solution, I'll gladly provide details. It's not ideal for 2 reasons:

- It involves a change to template_tag in the templating handler, which seems fairly core stuff
- The templating cache has to be refreshed constantly because I could not find another way around a problem where the master template would be cached from page to page, even if it had changed. Obviously this change is detremental to performance, although I'm not certain to what degree.

The second issue is probably resolvable if someone with more experience looked at what was going on - in the end I got it to work and we are living with the performance hit.
The first issue is only significant if this was a feature people wanted in core .LRN, so I guess it would be down to whether this was put forward as a TIP.


<Raad>

What our solution does, is allow one instance of .LRN to be customised so that each community or subgroup can have it's own specific master-template.
That mean each community or subgroup can have it's own look that extends beyond the community portal and into the package pages (e.g. forums). The user portal would still use the master-template specified by the ACS main site.

So the question that arises is this:

If a user is a member of 2 communities, each with a different master-template, does it matter that when they go to Community A, the forums-portlet and forums pages look different to those in Community B?
The answer depends on several factors: how different are the designs? Are people expecting a different look? Would it surprise them that the fishing club's pages look different to the chess club's pages?

One thing to consider is the use of closed communities and limited users.
If you wanted to host seperate communities/groups with a discreet set of users, you could set them up as limited users (can't see other communities, no personal portal if member of one community only).
The other thing to consider is design. You could make the design for one community very, very different to that for another; but in practise you will be constrained by the structure of the .LRN portals, portlets and pages in general. So although the package pages could look very different, I don't think they would be so different as to make it confusing for users to understand.

Just a few thoughts :)


<Raad>