nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Changes for the scripts/mappings/reports folders since 2023 R2.1

medini_1059007410

Hi, Starting with medini 2023 R2.1 we changed the access to the scripts, mappings and reports folders. Background is the introduction of the medini Collaboration server, which required a change away from the files-in-a-folder approach to storage of files in the database. What has changed? In the past, the script/mapping/report files were stored in the project folder within the workspace under "config/", and modifications had to be done via the Windows Explorer or the deprecated Navigator view in medini. Only the script files could be displayed in the model browser and opened in an editor, but adding/deleting/moving files still required separate access. Now, the config folder with the mapping/script/report files is directly shown and accessible via the Model Browser - please enable script development support in the Preferences to see it. All config files directly visible and accessible in one place. The files in there are handles as External Documents, similar to any .txt, .pdf, .docx... file you can add to your project via context menu or drag & drop. Thus you can similarly add or delete your config files via the model browser. Important: Even though the config files are stored for a local medini project in the project's config folder within the workspace, medini does not synchronize new/modified files in that drive folder with the config section of the model browser. So please don't touch the "config/" folder in the workspace anymore! Files added there will not be available to medini anymore. How should the config files be worked with now? Only work with the files through the Model Browser, please don't try any other access method. Add new files either via Drag & Drop or the "New > External Document" context menu. Open the files for contents modifications via double-click or use "Open With > ..." from the context menu. My personal favorite is "System Editor" to open it in your preferred editor like VS Code or Notepad++. Export the files also via Drag & Drop or the "Export" context menu. You can also replace it with an updated file via "Update...". Also deletion is possible. Execution is as before via "Execute Script", or anywhere in the model browser via "Execute..." context menu (especially if your script needs a selection). I hope that helps you working with our new solution. In case of any questions or suggestions, please answer on this post. Regards, Nils P.S.: Duplication, renaming and moving of files is already on our roadmap ;-)

Find more posts tagged with

medini

medini legacy

Accepted answers

All comments

medini_1063548292

Hi Nils , Thanks for the very good summary! Two questions: Would it be possible to also use Link object (URL) for the script file /mapping file? I am asking because I noticed that when i used Link object to be used as a m2doc word template in M2doc configuration checklist that one worked but for the .*js or .mappings it does not seem to work. How are the path of the linked files treated ? Example 1:external files A.js and B.js file A.js located o

/GIT/scripts and file B.js in

/GIT2/scripts As you shown both js files would be created as an external document under the scripts package Now A will have a load ("B.js") will this work ? Example 2: external files A.js and B.js file A.js and B.js are located o

/GIT/scripts As you shown only A.js file would be created as an external document under the scripts package Now A will have a load ("B.js") Will this work ? Example 2: external files A.js and B.js file A.js and B.js are located o

/GIT/scripts and B.js is also located

/GIT2/scripts As you shown only A.js file would be created as an external document under the scripts package and B will be linked form a D/GIT2/scripts folder Now A will have a load ("B.js") Will this work ? Thanks & regards, Marian

medini_1059007410

Hi Marian, No, External Links are currently not supported for any package within the "config" area. Background is that the projects still have to function also when stored on the Collaboration server. External Links for such files would likely be used with locations not accessible for every user (like your "D:\..." examples), so that user couldn't use scripts, import mappings or custom (BIRT) reports. We need to avoid that and therefore currently only support External Documents, which are stored in the project itself and are thus always available to users. Regards, Nils

medini_1069429433

Is there a possibility to add a programmatic means of adding/deleting Rhino Javascript files? In the past it was very convenient to be able to simply add/delete/modify any code in the folder config folder because a simply python script could be used to update all the code in the project. The only solution I can think of now is to use Eclipse to automate the creation of a file given a name and text for it. Not a huge deal and I do appreciate how this enables the benefits of the Collaboration server but at the same time I really do feel that users having to deploy large or complex sets of files have lost some well loved functionality.

medini_1040753747

Thanks for the update Nils; a couple things from my end: 1. When I drag and drop our script files to the project config/scripts folder (through the medini model browser) and 'Execute Script', I get the following error: "Failed to execute Java Script: Encountered code generation error while compiling function "null": generated bytecode for method exceeds 64K limit." - doing the same thing in 2023R1, it works fine. 2. Not sure the exact setup, but I believe our IT org has set up a customized menu in medini which links to a centralized folder on all user laptops that contains our scripts (C:\Users\\MGP\businesslogic\scripts) and all the projects access. This location gets updated on all user machines whenever IT deploys updates to the scripts. What is the best way to handle this situation with the current configuration in 2024+?

medini_1024169437

Roy, sorry, I have not seen your reply here for some reasons. Anyway, as your statement is still valid... there is indeed no direct support for that "update a bunch of scripts in one step in a collaborative project". Note that for local projects that still may work as the local project still relies on the local file system. For shared projects, one way could be to work with an offline copy for a short period of time, use that offline copy to update he scripts and then push the changes to the server. Note that since 24.2.1 there is a "Sync Scripts", later named "Sync Files" on the config/scripts resp. config folder to synchronize any modification you did directly on the file system with the project. That should help to support he "I edit my scripts on the file system rather than in thr project" use case. If you have better ideas how to support that, please let us know. Regards Jan

medini_1040753747

Jan, if we do not have a collaboration platform/shared project setup implemented and we are still using a local project that relies on a local file system, then scripts should still work as before (ie. 2023R1)? Or is there some other change that also needs to happen for the same functionality on 2024+?

medini_1024169437

Hi Johan, it is still different as Nils pointed out, each script is not anymore just a file on file system but an "external document" in the sense of an attachment to medini. About your two problems: the first one is strange indeed, we upgraded the JS engine to a newer version and the error itself is known, but I never saw that error as a consequence of a version up. You may out the $NO_OPTIMIZATION$ pragma in the first line of the script to disable (see Pragma like directives in java scripts : Ansys medini analyze Support for details). Anyway, its a bit strange so if you could hand in the script via our support team so we can have a look why the engine behaves differently, that would be great, The other question is more tricky. Do you know how that menu was contributed to medini? Is that an additional eclipse bundle that is deployed? And second: just having that menu in the main tool bar is probabaly not the full fucntion, right? What exactly happens if a user uses the menu? Is the script executed on the selected project or is is deployed / copied to the project and executed there? Regards Jan

medini_1040753747

Thank you! the $NO_OPTIMIZATION$ directive seemed to get me to the next error (incorrect instantiation of a Java class that 2023R1 does not complain about), which I was able to fix :-)
I believe the menu is made possible through an Eclipse plugin: "menuclick" and I think it points to a centralized folder (C:\Users\\MGP\businesslogic\scripts) - so all the projects refer to this location; there are no scripts in the individual project config folders. If I try to run the script through the menu, it prompts me to pick the project but then nothing happens... no errors or warnings. I am assuming IT has it set up when the user launches medini, the centralized folder gets overwritten with the latest package of scripts.

medini_1024169437

Glad you've overcome the first hurdle. That plugin you mentioned, is that an in-house development? At least I cant find it in the net or eclipse market place. And: do you see any entry in th eeclipse/medini error log? Regards Jan

medini_1040753747

Happy Valentines day . I believe you are correct, it seems to be an in-house plugin managed by our IT group. They are currently working on the fix internally. Sorry, for the confusion or if it caused additional work on your end...

medini_1024169437

Thanks Johan, same to you. No need to apologize, really, if you or the team that manages the plugin needs help, please let us know, we are happy to help. It might be that it is not anymore as easy as before to write a custom plugin that executes scripts. Regards Jan