I am writing an app that runs from the browser. However, some model functions are also called from the Yii2 console. Therefore, I am getting errors when trying to access variables that are set in the GUI.
Is it possible to tell which mode I am in? Is there some environment variable automatically set, or should I just set some session variable in the console app to indicate the state?
You can use
if (Yii::$app instanceof \yii\console\Application)
for console, and
if (Yii::$app instanceof \yii\web\Application)
for web.
Correct variant
Yii::$app->request->isConsoleRequest
There is a simpler way to figure this out without going through the Yii objects
if (php_sapi_name() == "cli") {
return;
}
...and it works for all PHP scripts
...and it is lighter
By default for console:
Yii::$app->id == 'basic-console'
And for web application:
Yii::$app->id == 'basic'
Yii::$app->id stores the id of the loaded configuration params. By default for console application it is 'basic-console' and for web application it is 'basic' (defined in configuration file)
Yii2 provides a number of different classes for application's console and for those of type web. In addition to this division of the mode of operation of the classes, there are also a set of rules governing the organization of the code of the application. The first, fundamental, it is the respect of giving the MVC Model object information, to view the management interface with the user and, finally, to the controller the role of coordination among them. In your case it seems to sense that a piece of code runs in console but referring to classes that provide a Web interface. Probably because in some Model classes were introduced with functions with HTML or other code that should not be there. If you need two separate applications should precisely separate applications that use a type controls
yii\console\Controller
and another that uses controller type web
yii\web\Controller.
Obviously Model classes will be common and, thanks to separate controller, be sure to invoke View appropriate to the type of user interface in use. I Hope this could be useful.
Works for nginx and apache:
function isConsole()
{
return 'cli' == php_sapi_name() || !array_key_exists('REQUEST_URI', $_SERVER);
}
Pure PHP:
global $argv;
if (empty($argv)) {
// Browser mode
}
else {
// Cli mode
}
Related
I have created a new solution for my MvvmCross app that supported Windows Store and I want to support UWP on Windows 10. I have moved over the PCL successfully, but I am having problems getting the basic UWP app working using a sample provided by MS (NavigationMenu) which uses the SplitView and the AppShell pattern they are recommending for the new navigation/command model. I referenced a helpful blog post (http://stephanvs.com/implementing-a-multi-region-presenter-for-windows-10-uwp-and-mvvmcross/), which gave me some guidance on how to integrate mvvmcross into the AppShell, but startup is failing because the AppShell does not have a valid Frame defined. Frame is a read-only property, and I have been unable to see where this is being set up.
I am using the standard AppShell implementation from the NavigationMenu with the following changes as recommended in the blog post:
public sealed partial class AppShell : MvxWindowsPage // was Page
public Frame AppFrame { get { return this.Frame; } } // was this.frame
Except for code after the error, there are no differences in the setup. In looking at the MvxWindowsPage implementation, there doesn't seem to be anything special as it still invokes the Page initialization. Is there something obvious I am missing?
So the link to the blogpost is correct, in other words you'll need to use MultiRegions from MvvmCross to get this working.
But what the blogpost doesn't show is a complete working version...
I've added one on my github here:
https://github.com/Depechie/MvvmCrossUWPSplitView
Some pointers to take away, like I said in the comments.
Your view where the SplitView will be present, needs to have a property to return a valid Frame to look for while injecting new views. This can be returned like this return (Frame)this.WrappedFrame.UnderlyingControl; found in the code here https://github.com/Depechie/MvvmCrossUWPSplitView/blob/master/MvvmCrossUWP.Win/Views/FirstView.xaml.cs#L13
Than all views you want to load up in the SplitView will need to reference to the region you defined in that SplitView, in my case I named it FrameContent as seen here https://github.com/Depechie/MvvmCrossUWPSplitView/blob/master/MvvmCrossUWP.Win/Views/FirstView.xaml#L48
So use that name for the region attribute in all to be loaded views like so [MvxRegion("FrameContent")] example here https://github.com/Depechie/MvvmCrossUWPSplitView/blob/master/MvvmCrossUWP.Win/Views/SecondView.xaml.cs#L7
I see what you're trying to do with the SplitView template that's provided by Microsoft. There is however a mismatch between things managed by MvvmCross and UWP.
By default MvvmCross maps ViewModels to Views based on naming conventions. What you are trying to do is use a view 'AppShell' (which is derived of Windows.UI.Xaml.Controls.Page) that doesn't adhere to the default MvvmCross convention.
The way I choose to implement this SplitView (Hamburger) functionality is by deleting the provided AppShell class entirely. I then created a new view named HomeView (since I have a ViewModel with the name HomeViewModel) and added the SplitView control there as described in the post you mentioned above.
For completeness I've created a Gist with the App.xaml.cs and HomeView.xaml as you requested. You can find them here: https://gist.github.com/Stephanvs/7bb2cdc9dbf15cb7a90f
So SimpleInjector now has a packaging nuget that you can use to isolate different aspects of root composition.
Say I have a configurable composition root in a library that is reused by multiple projects in an application. For example, in an Azure solution I might have a Web role and a Worker role which share a large set of the same dependencies for the most part, but with slightly different configuration options depending on the consumer. When I compose the root, I can pass in a plain old RootCompositionSettings object with properties that tell SimpleInjector how to register dependencies.
However, I am not sure how (or if) I can pass these settings to an IPackage instance. Is it possible to pass custom settings to a SimpleInjector package, and if so, how?
I see that the standard practices for registering packages is to invoke either
container.RegisterPackages(); // scans all loaded assemblies for IPackage
// or
container.RegisterPackages(IEnumerable<Assembly>) // specific assemblies only
...so how can we pass parameters into the packaging instance(s)? Is there some way to do it via the container?
The trick here is to pass the information on with the container to the package. You can do this by using the container's Items dictionary, that is much like ASP.NET's HttpContext.Items collection. This can be done as follows:
using SimpleInjector.Advanced;
container.SetItem(typeof(RootCompositionSettings), settings);
container.RegisterPackages();
Now inside your packages, you can do the following:
var settings =
(RootCompositionSettings)container.GetItem(typeof(RootCompositionSettings));
Please note that:
SetItem and GetItem are extension methods that are located in the SimpleInjector.Advanced namespace. Those methods allow you to access the (internal) Items dictionary.
You can pass in any key you like. Passing in typeof(RootCompositionSettings) is just convenient in this case, but not required.
If you need to call the settings in more places, it might be useful to create a more specific extension method that allows you to access the setting instance, but that's up to you.
Another option is to not use the IPackage interface and the SimpleInjector.Packaging library at all. In most cases it doesn't really add anything and you could simply define a public static method in the assembly that does the same as a package does. For instance:
public static class BusinessLayerBootstrapper
{
public static void Bootstrap(Container container, ScopedLifestyle scopedLifestyle,
RootCompositionSettings settings)
{
// Here the same logic as what you would write in your package.
}
}
Most applications are not that dynamic that you need to load assemblies dynamically and the startup project usually has a hard reference to all the other assemblies. In that case it is perfectly sane to simply call a static method.
And even if you have the requirement of dynamically loading assemblies and allowing them to register their stuff in the container, it's quite trivial to build your own IPackage abstraction instead:\
// Your own IPackage interface
public interface IPackage
{
void RegisterServices(Container container, RootCompositionSettings settings);
}
// Your own extension method
public static void RegisterPackages(this Container container,
RootCompositionSettings settings)
{
var packages =
from assembly in AppDomain.CurrentDomain.GetAssemblies()
from type in assembly.GetExportedTypes()
where typeof(IPackage).IsAssignableFrom(type)
where !type.IsAbstract
select (IPackage)Activator.CreateInstance(type);
packages.ToList().ForEach(p => p.RegisterServices(container, settings));
}
In fact, except for some extra validations and filtering out dynamic assemblies, the SimpleInjector.Packaging project is not much more than this.
I´m developing an App that will be available for Windows Phone 8 and the Windows Store. To reduce redundancy I´m using a Portable Class Library (PCL) and on top of that I'm trying to apply the MVVM pattern with the help of the MVVM Light PCL Toolkit. The ViewModels are placed in the PCL and are bound directly in the XAML of the Apps pages.
When the data is received without an error, everything works fine. But I don´t know how to get the exceptions/error message back to the App when errors do happen.
Inside the Windows Store App errors will show as a MessageDialog while the Wp8 App will use the MessageBox class. Obviously the PCL isn´t aware of any of these classes. What I´m not getting is how to know if a ViewModel ran into an error, and how to get the message inside the App. Is this even possible when the ViewModels are bound inside the XAML?
The code in the ViewModel (inside the PCL) looks like this:
DataService.Authenticate((token, error) =>
{
if (error != null)
{
// This is, obviously, not going to work.
MessageBox.Show(error.Message);
return;
}
Token = token;
});
So I have to save the error somehow and let the App itself know the error has occurred, and then call the matching way of showing the error to the user.
Currently I´m thinking of something like defining an Error-property inside the BaseViewModel and fill it when errors in the ViewModel occur. Then, in the CodeBehind of the pages, make them aware of the current ViewModel and bind a PropertyChanged-event to this Error-property. But I was not able to implement it yet, so I don't know if this is even the right way to go.
Do I have to step down from the idea to bind the ViewModels inside the XAML, and do I instead have to initialize them inside the pages Codebehind?
Your instinct is correct, but there are more than a few ways of going about this.
First and foremost, you can use Mvvm's Messaging library, which will allow your ViewModel to send messages directly to your View. Your View can then handle it in any way it wishes, including but not limited to using a MessageDialog.
Secondly, you can also create a Function or Action (likely the former) in your ViewModelLocator for ShowMessageDialog. This Function will likely take a string and return a Task. Then, after you initialize your ViewModelLocator initially, you can inject your ShowMessageDialog code. Your ViewModels can then use whatever platform's MessageDialogs that they please.
Ex:
Note: This code uses the BCL Async libraries that are accessible in Nuget. They work in the PCL just fine.
ViewModelLocator:
public static Func<string, Task> ShowMessageDialog { get; set; }
App.xaml.cs:
ViewModelLocator.ShowMessageDialog = (message) =>
{
// For Windows Phone
return TaskFactory.StartNew(() => MessageBox.Show(message));
// For Windows 8
MessageDialog md = new MessageDialog(message);
return md.ShowAsync().AsTask();
};
ViewModel:
await ViewModelLocator.ShowMessageDialog("This is my message.");
Secondary Note: The md.ShowAsync().AsTask(); must be run on the UI Thread. This means that you will have to invoke it via the dispatcher in the case that you are running it in a task asynchronously. This is possible using a similar method of injecting the use of the app's CoreDispatcher via the RunAsync method.
This means that you can, on any platform (Windows 8 and Windows Phone shown above), inject whatever Message Dialog system you want and use it in your PCL.
I would say that it is much easier to do the first method I suggested, as that is what it is there for, but the Function method version is definitely helpful at times.
I'm After several days learning angularJS through converting my standart JS app to a ng one.
I was wondering about this simple scenario:
I have a global function called fb_connect(),
it can be used from any page (or any controller if you like) to make a facebook-based login.
This function makes a simple http call and receives a JSON object contain data to move on (display a pop up, login, etc...)
I read that I can define a Factory or a Service for my app and use it in any controller, which works fine.
So, I created a fb_connect factory function.
The problem is that now, in every page (every controller), I have to define that fb_connect in the constructor of every controller - for example :
function welcome($scope,fb_connect){});
What is the proper way to do this kind of actions using Angular without having to define these functions each and every time in every controller?
Thanks
Setting up factories and services is all part of the dependency injection system of Angular. Using that system is great when you need to create things that depend on other injected things. It's a big tree of dependencies. It's also nice for creating singletons, such that everywhere in your code end up using the same instance of some object.
It sounds to me like neither of these benefits apply in your case. I'd suggest just not using Angular's DI for it. You have some function defined globally, just call it directly and skip the DI. There's nothing wrong with that.
Of course you say it makes an Ajax call, so doesn't depend on the Angular $http service?
Your two options are:
Declare the function on the $rootScope
Inject it as a service
My advice is to go with making it a service. The whole purpose of services is explained in the Angular.js docs, just like this quote:
Angular services are singletons that carry out specific tasks common to web apps... To use an Angular service, you identify it as a dependency for the dependent (a controller, or another service) that depends on the service.
As you mentioned in your question, you'd prefer to not define the service in every controller you wish to use it in. With $rootScope you'll be injecting that also in every controller. So really it's a question of which you prefer, although to answer your question, the proper way of using a factory or service is to inject it into the controller you wish to use it in.
You can always put it in the $rootScope
myApp.run(function($rootScope, fb_connect){
$rootScope.welcome = function(){
};
});
I'm using PHPStorm v3 and have some code which connects to a certain SOAP service. (via a simple PHP SoapClient) No problems whatsoever. But the PHPStorm inspector cant find the methods available of the WSDL and thus cant recognize the used methods:
$this->soap = new SoapClient('somewsdl url');
$issues = $this->soap->getIssuesFromJqlSearch($this->auth,
'ticketId = '.$ticket->getId().'
AND impId ~ "'.$currentImplementation->getIdentifier().'"', 1);
Everything works but the method 'getIssuesFromJqlSearch' which is provided by the external WSDL is highlighted with the mentioning of an undefined method... How can i 'tell' PHPStorm what should/could be used (or explain how to parse the WSDL?)
You can suppress the inspection for this statement from the Alt+Enter, right arrow menu:
This is not perfect, since it does not parse the WSDL and you have to do it manually, but works fine after the initial setup.
Create a class extending the native SoapClient and use annotations to add virtual methods:
/**
* #method mixed getIssuesFromJqlSearch
**/
class VendorSpecific extends \SoapClient {}
Or you could generate such client yourself, implementing all the methods as a proxy to self::__soapCall(). See my SoapClient generator for reference. The upside is that it can parse the WSDL, though not perfectly.