Hello! Thanks for the question. This is a typical question on some machines or with some networking software. Try looking through the issues to find the answer. In my experience, as well as my colleagues experience we never encountered these problems.

Thanks! Considering the points others mention, I agree that projections should not be the way to install things but rather the acceptable exception as for WebTerminal and other complex packages.

True points. For sure, developers can customize it. I can do another version of WebTerminal specifically for ZPM, but it will involve additional coding and support:

1. A need to change how the self-update mechanism works or shut it down completely. Right now, the user gets a message on the UI, suggesting to update WebTerminal to the latest version. There's quite a lot of things happen under the hood.
2. Thus, create an additional pipeline (or split the codebase) for 2 WebTerminal versions: ZPM's one and a regular one with all the tests and so on.

I am wondering is it worth doing so in WebTerminal's perspective, or is it better to make WebTerminal a kind of an exception for ZPM. Because, still, inserting a couple of if (isZPMInstalled) { ... } else { ... } conditions to WebTerminal (even on front-end side) looks as anti-pattern to me.

Thanks! Exactly, I completely agree about simplicity, transparency, and installation standard. But see my answer to Sergey's answer - what to do with WebTerminal in particular?

1. Why would I need to rewrite the update mechanism I developed years ago (for example)?
2. Why would I need to maintain 2 code bases for ZPM & regular installations (or automate it in a quite crazy way, or just drop self-update feature when ZPM is detected)
3. Why all these changes to the source code are needed, after all, if it "just works" normally without ZPM complications (which is how the ObjectScript works)

I think this leads to either "make a package ZPM-compatible" or "make ZPM ObjectScript-compatible" discussion, isn't it?

Exactly not for installing purposes, you're right, I agree. But what do you think about the WebTerminal case in particular?

1. It's already developed and bound to projections: installation, its own update mechanism, etc.
2. It's also shipped outside of ZPM
3. It would work as usual if only ZPM supported projections

I see you're pointing out to "It might need to support Projections eventually because as you said it's a part of language" - that's what mostly my point is about. Why not just to allow them.

Hello Matthew! Thank you for your feedback.

Indeed good point. One idea that comes to my mind for this case is to improve the import script to file the list of classes which were ever imported and those which are used now. By using this list the import script can resolve which classes to delete and which to keep. However, deleting classes can always introduce unwanted side effects, but in terms of a project this should be consistent.

Thank you Benjamin! Glad to hear this 

Check it here: 

https://github.com/ZitRos/cache-visual-editor

So this is strange. Try installing some of my other projects like WebTerminal or Caché Visual Editor and check whether they have the same issue. If yes, double check your Caché security settings, and especially web apps and their privileges.

Kumar,

Does it have the same network configuration (any load balancers/firewalls/etc)?

Did you compile them in samples namespace as shown in webapp settings? Also are you sure that nothing unexpected is set up in front of Caché which can prevent normal routing (like load balancers/other routers)?

Hello Alexander!

Yes, these are definitely the good points to improve the application. But most likely Class Explorer will be rewritten from scratch rather than enhanced with new features. This is because the internal framework choosed for development on the very early stages is very hard to extend.

We’ll take a note you mentioned for the future software! Thank you! Maybe you’ll also like my other projects like Caché Visual Editor, check them out.

Hello Kumar!

Did you compile the classes you’ve imported? Try importing and compiling ClassExplorer.xml once again.

Thank you Rich for noticing this. We’ll update the links shortly. This problem is related to WebTerminal repository migration to intersystems-community organization on Github. Follow WebTerminal there!

Nice! Thanks! At least I diagnosed the problem: that's because I/O redirection, there's no I/O redirection routines in a new mnespace if the routine performs any writes or reads.

We need to find a better way to intercept Caché process I/O. Any help is very welcome!

Hi Alexey!

This is a known issue I still didn't figure out how to solve. If you can help here in any aspect (for example, how did you figured out that the thing is in DAQ() code?), it is very welcome. Please - continue bug/feature discussions as well as this one on Github.

In short, WebTerminal had problems with mnemonics, and what I did to solve them is a bit crazy - I just copied the code from %X364 to let them work here, as that code was utility. Maybe, there is a better solution, but I didn't came to it because of my lack of experience at some point.

Alexey, any help is very welcome. Do you know where even to find ^JOBEXAM's code to investigate the problem? Thanks!

Daniel, thank you for these important points.

Thank you very much, Robert! Good to know about MANAGEDEXTENT, I have never heard of it.

Do you think it's okay just to copy storage definition/globals as people suggest below? (to duplicate globals data and alter storage definition to use new globals)

Thank you Gerd! Paul just posted the same answer a little while ago :)

Works perfectly. Thank you!

Yes this works! Thank you Dmitry!