Archive of UserLand's first discussion group, started October 5, 1998.

Discussions for Multiple Membership Groups

Author:David Theige
Posted:4/18/1999; 12:14:30 AM
Topic:Discussions for Multiple Membership Groups
Msg #:5101
Prev/Next:5100 / 5102

The Problem Let's say that you would like to host two or more membership groups, each with access to a seperate discussion group...I know I would! Frontier 6.0 provides sample code for creating a discussion group website and the docs include instructions for building multiple discussion groups. However, the existing docs do not explain how to associate multiple membership groups with their own websites. MailToTheFuture.root and WhoIs.root contain useful example membership code. First Step Begin by following Userland's documentation for Multiple Discussion Groups Create a New Membership Group Create a new subtable in member.root by copying the default table and pasting it back into members.root with a new name, for example, "newGroup". Change the value of newGroup.cookieName to, for example, "newGroup". The value of newGroup.cookieDomain should be an empty string. Make sure the newGroup.users subtable is empty. Edit other settings in the newGroup table as you deem appropriate. Secure Access to the Discussion Website Let's assume you named the new discussion website table in htmlInterfaces.root "newDiscussion". Jump to "newDiscussion.edit.#members", or create a string at this location if it doesn't exist. Change the value of the string to "newGroup" (without the quotes) or whatever you named the new top-level table in members.root. If you leave the #members directive at this location, security will work like discuss.userland.com---anyone will be able to read messages, but only members will be able to post. If you prefer to limit all acess to your site to members, copy or move newDiscussion.edit.#members to the top-level of your site (newDiscussion.#members). Copy the logon table from htmlInterfaces.root and paste this inside your new website table. You should now have a "newDiscussion.logon" subtable. Rename the "newDiscussion.logon" subtable "public" without the quotes. This is very important! This subtable should include a #members directive with the value identical to the one you created above. Copy the people table from htmlInterfaces.root and paste this inside your new website table. You should now have a "newDiscussion.people" subtable. Clean Up Your Code You must be careful that scripts in your new website do not refer to the default discussion group (for example by calling config.mainresponder.globals.defaultMembershipGroup) or the default URLs table (by calling config.mainresponder.urls). Unfortunately, as of this writing the sample discussionGroup website in htmlInterfaces.root contains several such references. As you recall, you cloned this website as the first step in this process. Some of the problem references are within htmlInterfaces.root (which is sample code only), others occur indirectly via calls to mainResponder.root objects which contain these references. Where these calls exist in mainResponder.root they could be considered bugs, and they may be fixed in the future by Userland. The workaround will involve three steps. First, copy problematic scripts from mainResponder.root (i.e. mainResponder.discuss.listDay and mainResponder.discuss.readMessage) to a #tools table in your new discussion website. Alternatively, if you want to use these scripts in multiple websites you could place them in the user.html.macros table. Second, edit the scripts or wp text objects which contain the problematic calls. Any references to "config.mainresponder.globals.defaultMembershipGroup" in a script should be changed to "pta^.members". The same data can be called from a macro in a web page by referring to "members" (without the quotes) because the page table is always in scope. References to "config.mainresponder.urls" should be changed to "pta^.urls^" in a script or "urls" in a macro. Finally, make sure that the pages and scripts in your new website are calling the edited scripts instead of the original scripts. To call a script in your website's #tools table named "listDay" you would refer to pta^.tools^listDay. Known Bugs Here are some specific examples of problems that you may need to fix if you have cloned the discussionGroup table: mainResponder.discuss.listDay calls config.mainresponder.globals.defaultMembershipGroup. This script is called by discussionGroup.default. mainResponder.discuss.readMessage calls config.mainresponder.globals.defaultMembershipGroup. This script is called by discussionGroup.msgReader. mainResponder.discuss.topicsToXml contains this line: local (adrmsgs = @[f].discuss.messages). This script is called by discussionGroup.topics.xml. discussionGroup.people.["#tools"].viewProfile calls config.mainresponder.urls.prefsHome logon.welcome calls config.mainresponder.urls.discussHomePage, config.mainresponder.urls.prefsHome, and config.mainresponder.urls.memberLogoff logon.#tool.logoff calls mainResponder.members.setCookie without supplying an addrMembers parameter. Troubleshooting When you are finished editing the website table, be sure to rebuild the glossary. Work in Progress This is obviously a work in project. Any credit for any know-how contained herein is due to the Userland team and the members of Frontier community. My role has been to try to assimilate tidbits from various mailing lists and websites. I will try to update this page when needed.



There are responses to this message:

This page was archived on 6/13/2001; 4:49:24 PM.

© Copyright 1998-2001 UserLand Software, Inc.