I am currently facing a challenge with a block that houses a wizard implemented across multiple screens. Upon pressing a button within this block, the application navigates to a different screen, which also incorporates the same wizard block. The issue lies in the circular dependencies between my CW module and End User module, particularly when attempting to navigate from the block (CW) to a screen (End User).
To address this, I considered using URLs instead of destination widgets. However, this introduces complications, such as the need to update URLs if screen names change and the potential for unclear URLs due to numerous input parameters.
Another solution I contemplated involves implementing a trigger in the web block. Yet, this approach requires duplicating a substantial client action, housing the logic for determining the destination screen, across all my screens, which doesn't feel optimal.
I am open to alternative suggestions to enhance the current approach and address these challenges.Regards Thibaut
The complexity for a large part is still in the blocks themselves, so from a maintainability point of view still a good solution. There is no right or wrong, easy solution, direction has its pro's and con's. In the end, you have to weigh yourself what makes sense in your case. I
Although the current architectural canvas no longer has the orchestration layer, conceptually you could still implement your application like that. Where your main app is in the orchestration layer, and all the screens as public in the end user layer. Not sure why you have a circular reference, seems unnecessary.
I wonder what use case needs 100 different forms to complete.
Hi @Thibaut G
Try to attach your oml. Would like to help you in it.
Thanks
Prince
Thank you for your response. Unfortunately, I'm unable to share an OML
Hi,
First question I have is, why do you use multiple screens, and not multiple blocks instead? It would make it so much easier to develop.
Regards,
Daniël
Thank you for your response.
The main reason for choosing screens over blocks is to ensure a clear overview. With the application set to accommodate over 100 different forms, each with complex validation logic, my concern is that readability might suffer with over 100 blocks on a single screen. Despite recognizing the advantages, do you still recommend using a single screen in light of this information? Additionally, using a single screen would definitely resolve the issue with circular dependencies.
a Quality Management System (QMS) tailored for a specific food industry across multiple countries and plants
Hi Thibaut G,
On Cw modules don't use screen destinations in upward references you can use external URL instead.
I believe that this can solve the problem
Hope that it helps you
I think Thibaut is already doing it but doesn't like the solution of using external URLs given the maintainability issues that come with it.