I've tried changing the models.ejs file located in: node_modules/sails/bin/boilerplates/templates
Seems to ignore any change I make in there.
If you're doing sails generate model, it's using the code in the globally installed Sails, so you'd have to change the template there. On OS X Sails installs globally to /usr/local/lib/node_modules/sails, but it may vary by system.
This is one of the reasons that Sails v0.10 moved to using separate generators rather than baked-in templates!
Related
Is there a way to make a user created class/package to be read only in Modelica preferably through annotations? Make Modelica class read-only in Dymola gives a Dymola option, I am using OpenModelica and is required to verify a package across its two different versions, since both these versions are editable I am unknowingly making modifications in the older version. Thanks in advance.
I tried to search OpenModelica documentation to see if any OM specific annotations are available. But I couldn't spot them. I am pretty much sure that I have missed it in them, probably used a bad keyword.
In OMEdit there are two ways to open a library: either use "File->System Libraries" or "File->Open Modelica/Library File(s)".
The system libraries only shows packages installed at $HOME/.openmodelica/libraries (on Linux; other path in Windows). These are installed by the package manager or installed there manually. When loading libraries through "File->System Libraries", they are always read-only.
If you load the same library by pointing out the package.mo file, it is opened writable.
You can mark a class read-only in the filesystem by not making the file writable (and if you use a hierarchical file structure instead of the whole library in one file, you can restrict editing to only certain parts in this way).
When loading an encrypted library, it is possible to prevent certain operations on the package using annotations, but editing is always restricted.
Yes, I'm beginner. and I used Webstorm but now using Vscode.
I know to say 'extension' in Vscode.
But sometimes to say 'plugin' in Vscode.(ex. Do you know Vscode's Prettier plugin?)
Can others understand this?
I understand it like this Python's pip and Node's npm to understand.
Just different name.
Is that what I understand right?
There is very thin border line between the two.
Extension and plugins often confused people. And Mostly people believe both are same.
The main difference between the two is that plug-in provides extra functionality which does not modify the core functionality.
While extension is made for modifying core functionality, may be provided due to version change or improvement.
Securing plugins is more complex than extension.
Extension are individual identity so one extension needs one set of privileges, whereas plugins are more complicated and needs to identify privileges for each application runs plugins rather than a whole plugin.
Extension is specific to particular application. It extends functionality of a particular application or software.
While plug-in can be made generalized which may runs independently in coordination with particular application or software.
In his Sentry TYPO3 Integration, Helmut Hummel defines the environment via $GLOBALS['TYPO3_CONF_VARS']['SYS']['environment'] here.
I've never seen this TYPO3_CONF_VARS setting before and searching the TYPO3 core of TYPO3 9.5 I can't find it either.
Background to my question is, that the environment detection doesn't work for me with the Sentry TYPO3 Integration. I have defined the TYPO3_CONTEXT in my .htaccess file like this:
SetEnvIf Host "ddev\.site" TYPO3_CONTEXT=Development/DDEV
So the question is, do I just need to define $GLOBALS['TYPO3_CONF_VARS']['SYS']['environment'] manually in my LocalConfiguration.php / AdditionalConfiguration.php or is there a better solution?
You need to define it manually, or dynamically based on application context.
The setting was introduced by the extension itself and is not provided, nor used, by TYPO3 itself.
Usually, if you want to modify anything installation wide in $GLOBALS['TYPO3_CONF_VARS'], it's put into the typo3conf/AdditionalConfiguration.php file.
Some configurations, that are only relevant for extensions you might also find in those extensions ext_localconf.php files, but that's probably not what you need.
LocalConfiguration might work, but that one is generated and overwritten by the install tool.
As a side note: The default configuration can be found in typo3/sysext/core/Configuration/DefaultConfiguration.php.
I have changed the source code in the /lib/coursecatlib.php file. Can I set apart this changes to plugin?
There are some changes that can be made entirely withing plugins, by using the hooks made available in Moodle.
You haven't said what changes you have made to coursecatlib.php, but I suspect that anything you have done there will be hard/impossible to transfer into a plugin.
The closest you can get is usually to minimise the changes by adding a single line of code that calls a function in a custom plugin (preferably one in an automatically loaded class).
I want to use two Modelica libraries together, in Dymola, so for convenience I wrote a little script, loadLibraries.mos that just opens the two libraries.
But they use different versions of the MSL (3.2.1 versus 3.2.2), defined by the uses annotation in the top level package.mo:
annotation(uses(Modelica(version="3.2.1")));
The library developed by us uses 3.2.2, the library that uses MSL 3.2.1 is developed by someone else.
Now whenever I run the mos script (or when I open the two libraries manually), Dymola wants to run an update script. As far as I can see, nothing gets changed by the update script, so I would like to
either not run it at all, e.g. by defining a range of accepted versions like annotation(uses(Modelica(version>="3.2.1")));
or always run it, without asking first, e.g. by setting some flag AlwaysSilentyAcceptMSLUpgrade.
Under Edit, Options, Version there is a checkmark Force upgrade of models to MSL version but I am unsure how to use it from my mos script (for all users).
My pragmatic solution would be to ask yourself if your own library really needs anything from 3.2.2 which is not yet present in 3.2.1. Hence change your library to only require 3.2.1. Or the other way round (given you can change the package.mo of the other library) change the uses annotation there to 3.2.2
Don't change your own library, but make the library using Modelica 3.2.1 read-only (e.g. by making the files read-only).
That should skip the prompt (at least from Dymola 2016) - and as far as I understand you don't edit that library yourself anyway.
That works for libraries that don't need any update between the versions; which obviously holds for Modelica 3.2.1->3.2.2 since there is no conversion - but it would also work if there were a conversion that didn't influence this particular library.