Forum OpenACS Development: Re: How to handle dotlrn-specific changes in core?

Collapse
Posted by Torben Brosten on
"change .LRN to use its own membership state change script. .LRN totally redefines what being a user means with its predefined groups, etc. Anyone writing code that changes fundamentals to this extent should be prepared to supply custom scripts to support such changes"

This is consistent with how the ecommerce package handled registration for 4.6.3, namely separate registration code.

Obviously, care would need to be taken to intercept the bypassed openacs protocols sitewide. Using the separate ec code as an example, there were cases where users found their way to the standard openacs registration outside of ecommerce. Those users lost anything they had put in their shopping basket. The final solution was to write the ec requirements into the standard openacs register behavior.

Likewise, as an alternate to writing completely separate code and trying to track all cases where default openacs behavior exists, is there a way to add a switch or something to the openacs procs so that calls that require site-wide non-openacs-default behavior will be consistent sitewide?