· Jan 28, 2016

Can we map CSP pages from another namespace?

Is there a possibility to map a CSP page residing in namespace ABC to a namespace XYZ so you could access it as if executing from XYZ: http://localhost:57772/csp/xyz/MyPage.csp ? Some odd cocktail of web application and package mappings that could make this happen?

The idea is to keep the CSP page in sort of a read-only namespace that only contains code, with the data residing in another namespace. This works for zen pages, but not for CSP.

Discussion (6)0
Log in or sign up to continue

I asume since you used MyPage.csp in your example you are doing tag-based and not class-based CSP development?   

Remember that tag-based .csp files compile into classes within the namespace (by default these are csp.* classes).  So you could package-map csp.* (or whatever package you configure your CSP pages to compile into) from your Readonly namespace to the XYZ namespace, and then you could point the /csp/xyz application to the source directory holding the csp pages.  I think this is likely to do what you want (although I haven't tested it).  


You might be running into some security issues (check the audit DB to confirm).  Or, you might not have it working because you have "Lock CSP Name" set to "Yes" in one of the web applications (ref:

I just did a quick test as follows in my 2015.1 instance:

1) Created a SAMPLES2 namespace with new SAMPLES2 DB

2) Package mapped "csp" from SAMPLES namespace to SAMPLES2 namespace

3) Edited /csp/samples2 web application as follows:

- added Unauthenticated

- added %DB_SAMPLES Application Role

- Unchecked "Lock CSP Name" AND "Autocompile" (this should be done in both /csp/samples and /csp/samples2)

- pointed "CSP Files Physical Path" to c:\intersystems\e20151\csp\samples\ 

After this I was then able to see /csp/samples2/form.csp (although with errors because I didn't map the Samples.* package to the Samples Namespace).

So it appears to work - you just need to figure out which of the above pieces you missed :)



This is solution using class/package mappings.

Another alternative would be only using global mappings.

So if ABC is your centralized application/code namespace/db, you can create XYZ namespace/db which by default is pointing to your central application ABC db (routines and globals) BUT with global mappings added to (own) separated XYZ namespace/db. To ensure your data is separated.

You only need a login dispatcher (csp-app) in front which in the login process will route/redirect the csp-process to be run in approperiate destination namespace via url, e.g. /app/login.cls -> /app/xyz/...

No need to remap js-files, etc. on webserver config, etc. with that since /app/xyz csp-app is physically pointing to your central location.

You can add as many "clients" like XYZ through this, all working with the same base/central application-code but with separated (or common data) depending on your global-mapping definitions.