Associate product module to different workspace module

Posted by Simon de Kraa on 01-Apr-2016 04:31

At the moment application standard objects and customer objects are in different product modules but the same workspace modules (so in the same directory). We would like to move the customer objects to different directories so the difference between standard objects and customer objects is not only visible in Roundtable but also on disk (different directories). I have created a new workspace module pointing to a different directory but I cannot assign it to the already existing customer product module. Any ideas?

All Replies

Posted by Jeff Ledbetter on 01-Apr-2016 10:05

Hi.

I see that you've contacted support. They should be able to help you as this is not doable right out of the box.

For the benefit of others though, I wanted to respond in this forum.

The concept behind variants is that the Object is moved to a different logical location (Product Module) but the physical location (Workspace Module) remains unchanged. This way the custom code doesn't require any PROPATH changes or any change(s) to the calling procedure(s).

Can you share why you wish for them to live in a different physical location?

Thanks.

Posted by Simon de Kraa on 04-Apr-2016 04:09

At the moment we have products like gui, server, tty and product modules like gui.params, server.params, tty.interface, gui.assembly etc. Total number of standard product modules is ~200. Custom objects are in product modules like abc.server.params for customer ABC. Both product modules server.params and abc.server.params are linked to the same workspace module server.params that is linked to a physical directory ./server/lib/params. Before RTB we already had the custom objects stored in a separate directory like ./gui/cus/params. When RTB was introduced we decided to move everything into the same directory like ./gui/lib/params. That works. But... We also like the idea of being able to distinguish between standard and custom objects on file system level, do diffs, use symbolic links, use the propath to manipulate behavior etc. That is the reason why we would like to introduce new workspace module like cus.server.params that is linked to ./server/cus/params. Product module gui.params will be linked to workspace module gui.params and product module abc.server.params will be linked to workspace module cus.server.params (instead of server.params).

Posted by Simon de Kraa on 04-Apr-2016 04:11

I seriously wonder why all formatting in the post ^^^ is removed??? If I edit the post everythink looks fine...

Posted by asthomas on 04-Apr-2016 04:50

I understand from your explanation why it would make sense to have the physical structure and the logical structure match each other more closely.

It is quite common if you have tools external to RTB that are using directory structures for various processing, like making deployment builds etc.

You mention :

"Product module gui.params will be linked to workspace module gui.params and product module abc.server.params will be linked to workspace module cus.server.params (instead of server.params)."

With regard to the last one, with the server.params - are you just planning on having one custom module for this? Or would it also make sense here to have a 1:1 relation between the product modules and workspace modules?

This thread is closed