I have found some ways to config Yii 1 with phpstorm. But I don't know how to deal with Yii 2.
When use phpstorm, there are some errors. such as Yii::$app->db2, This method will cause
"Field access via magic method",
and some method bindValue,queryOne will also cause some problems.
There is, at this point, no native functionality for Yii2 as a framework (It's just Yii1 and Symfony if I recall correctly).
That being said: Yii2's source code is filled with DocBlock's (and the needed #var and #property statements. So the editor is able to make out a lot on its own now even without native support.
For that reason I don't think they will be implementing support for it anytime soon.
Related
Note: this is not a dupe of this or this other question. Read on: this question is specific to the Code-Sharing template.
I am doing some pretty basic experiments with NativeScript, Angular and the code sharing templates (see: #nativescript/schematics).
Now I am doing some exploration / poc work on how different "build configuration" are supported by the framework. To be clear, I am searching for a simple -and hopefully official- way to have the application use a different version of a specific file (let's call it configuration.ts) based on the current platform (web/ios/android) and environment (development/production/staging?).
Doing the first part is obviously trivial - after all that is the prime purpose of the code sharing schematics. So, different versions of the same file are identified by different extensions. This page explain things pretty simply.
What I don't get as easily is if the framework/template supports any similar convention-based rule that can be used to switch between debug/release (or even better development/staging/production) versions of a file. Think for example of a config.ts file that contains different parameters based on the environment.
I have done some research in the topic, but I was unable to find a conclusive answer:
the old and now retired documentation for the appbuilder platform mentions a (.debug. and .release.) naming convention for files. I don't think this work anymore.
other sources mention passing parameters during the call to tns build / tns run and then fetching them via webpack env variable... See here. This may work, but seems oddly convoluted
third option that gets mentioned is to use hooks to customize the build (or use a plugin that should do the same)
lastly, for some odd reason, the #nativescript/schematics seems to generate a default project that contains two files called environment.ts and environment.prod.ts. I suspect those only work for the web version of the project (read: ng serve) - I wasn't able to get the mobile compiler to recognize files that end with debug.ts, prod.ts or release.ts
While it may be possible that what I am trying to do isn't just supported (yet?), the general confusion an dissenting opinions on the matter make me think I may be missing something.. somewhere.
In case this IS somehow supported, I also wonder how it may integrate with the NativeScript Sidekick app that is often suggested as a tool to ease the build/run process of NativeScript applications (there is no way to specify additional parameters for the tns commands that the Sidekick automates, the only options available are switching between debug/release mode), but this is probably better to be left for another question.
Environment files are not yet supported, passing environment variables from build command could be the viable solution for now.
But of course, you may write your own schematics if you like immediate support for environment files.
I did not look into sharing environment files between web and mobile yet - I do like Manoj's suggestion regarding modifying the schematics, but I'll have to cross that bridge when I get there I guess. I might have an answer to your second question regarding Sidekick. The latest version does support "Webpack" build option which seems to pass the --bundle parameter to tns. The caveat is that this option seems to be more sensitive to typescript errors, even relatively benign ones, so you have to be careful and make sure to fix them all prior to building. In my case I had to lock the version of #types/jasmine in package.json to "2.8.6" in order to avoid some incompatibility between that and the version of typescript that Sidekick's cloud solution is using. Another hint is to check "Clean Build" after npm dependency changes are made. Good luck!
I'm trying to cache the db calls for Yii2 exists validation, but can't work out where to initiate it.
Because I'm using a multi-model form with a lot of relations, the overhead is getting a little too much.
Any ideas?
You'd better not. Actually, there is an issue on Yii2 official Github project where one of the framework's core developers, Alexander Makarov aka #samdark, explains why caching ExistValidator is a bad idea:
Exist validation isn't the kind of validation to be cached. Each second database may change its state so it should be validated just before it's saved.
This is not supported by Yii, you either have to :
Extend the ExistValidator and implement your caching logic there
Add a custom ActiveQuery class to your model in question and override
the exists() and count() methods
Application Insights does not support tracking for MySQL dependencies out of the box, so I would like to add it as my project relies heavily on MySQL.EF6.
Per the documentation here: https://azure.microsoft.com/en-us/documentation/articles/app-insights-api-custom-events-metrics/#track-dependency
It is possible to add tracking, however to avoid having to wrap every call I make to my database, I would like to override the MySQL.EF6 Library functions of SaveChanges, SaveChangesAsync, Find, FirstOrDefault, etc.
However I am unsure how to accomplish anymore than the SaveChanges/SaveChangesAsync as they are easily overrideable in my DbContext class.
You can try using EF6 logging - https://msdn.microsoft.com/en-us/data/dn469464.aspx.
I have designed a initial module lazy-loading system for a particular goal. In my special case there're a few modules that are needed to decorate forms and entities of the rest of the app.
However most of my members will only require a single one of them that will most likely never update. That is why I do not wish to load all of these modules in every request.
Now that worked like a charm until I required to provide extra view files from these modules. It appears like the module's
view_manager
config is not it merged into the
ViewManager
which is why the resolver is not capable to resolve the view file. I am now loading all these modules by default for testing -- it works.
My lazy loading mechanism bases on a
ModuleManager::loadModule()
call in case it is not it loaded already.
Do you know easy approach to properly inject/merge the config into the ViewManager? Also is this a general problem that possibly also affects other components? Or is it a error?
Thank you in advance!
I currently use RoleEnvironment.GetConfigurationSettingValue(propertyName) to get the value of a setting defined in my WebRole config file (csdef + cscfg). Ok, sounds right.
This works well if the setting exists but failed with an Exception if the setting is not defined in the csdef and the cscfg.
I'm migrating an existing app to Azure which has many configuration settings in web.config. In my code, to read a setting value, I d'like to test : if it exists in the webRole config (csdef + cscfg) I read it from here, otherwise I read it with ConfigurationManager from web.config.
This would prevent to migrate all settings from my web.config and allow to custom one when the app is already deployed.
Is there a way to do this ?
I don't want to encapsulate the GetConfigurationSettingValue in a try/catch (and read from web.config if I enter the catch) because it's really an ugly way (and mostly it's not performance effective !).
Thanks !
Update for 1.7 Azure SDK.
The CloudConfigurationManager class has been introduced. The allows for a single GetSetting call to look in your cscfg first and then fall back to web.config if the key is not found.
http://msdn.microsoft.com/en-us/LIBRARY/jj157248
Pre 1.7 SDK
Simple answer is no. (That I know of)
The more interesting topic is to consider configuration as a dependency. I have found it to be beneficial to treat configuration settings as a dependency so that the backing implementation can be changed over time. That implementation may be a fake for testing or something more complex like switching from .config/.cscfg to a database implementation for multi-tennent solutions.
Given this configuration wrapper you can write that TryGetSetting as internal method for whatever your source of configuration options are. When this feature is added to the RoleEnvironment members, you would only have to change that internal implementation.