I have written this method in a parent class in order to be able to get instances of children too.
/** #return static */
public static function getInstance()
{
/** #var $instance static */
static $instance = false;
if (!$instance) {
$instance = new static();
}
return $instance;
}
When I get the instance, PhpStorm doesn't know about child class implementation (methods, constants, etc). How can I tell him about them?
In snippet I am suggesting #return and #var as methods that work in contexts that don't imply static refference.
#return static does work in PhpStorm 6 (I tested in 6.0.2.) So you should upgrade to the latest version if you want to use this feature.
Related
Can somebody tell me why the autocompletion doesn't work when I'm using a getInstance() method instead of new ClassName?
Following is the getInstance() method of the class:
// Define The Namespace For Our Library
namespace JUnstoppable;
class JUnstoppable
{
// Instance Of The Class
protected static $instance = array ();
public static function getInstance ($forPlatformName = 'joomla')
{
$forPlatformName = strtolower($forPlatformName);
if (!isset(static::$instance[$forPlatformName]))
{
static::$instance[$forPlatformName] = new \JUnstoppable\JUnstoppable($forPlatformName);
}
return static::$instance[$forPlatformName];
}
public function __construct ($platformName = 'joomla')
{
}
public function doExecute ($test = 'lalala')
{
return $test;
}
}
Can somebody tell me why the autocompletion doesn't work when I'm using a getInstance() method instead of new ClassName?
That's because IDE does not know what can be inside your $instance static property and therefore it cannot figure out what getInstance() returns. From IDE point of view it's just plain array (elements of any types) and not an array of JUnstoppable instances.
You can place caret on $test and invoke View | Quick Documentation to see what IDE knows about that variable. If it does not say JUnstoppable there then no wonders.
Just add proper type hint for return value of getInstance() method via PHPDoc's #return tag:
/**
* My super method.
*
* #param string $forPlatformName Optional parameter description
* #return JUnstoppable
*/
public static function getInstance ($forPlatformName = 'joomla')
You can specify concrete class (JUnstoppable in this case) .. or static if this method will be used by child classes as well and they will return different instances.
Alternatively (or better say: in addition) you can typehint $instance property which IDE will use to figure out what getInstance() method returns:
/** #var JUnstoppable[] Instance Of The Class */
protected static $instance = array ();
I am using ajax for ratings. Rating successfully but return response with html code above the json. And it is because of send mail function.
The this code alwasy attached when return response and may be it was from send mail function.
When I am removing Mail function it will return proper result and its working well.
If i were in your place i will work with jobs.
So Here is how it goes
php artisan make:job SendingEmail
App\Jobs\SendingEmail.php
<?php
namespace App\Jobs;
use Illuminate\Bus\Queueable;
use Illuminate\Queue\SerializesModels;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Support\Facades\Mail;
class SendingEmail implements ShouldQueue
{
use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;
protected $admin_email;
protected $email_data;
/**
* Create a new job instance.
*
* #return void
*/
public function __construct($admin_email,$email_data)
{
$this->email_data = $email_data;
$this->admin_email = $admin_email;
}
/**
* Execute the job.
*
* #return void
*/
public function handle()
{
Mail::to($this->admins_email)->send(new RateNotification($this->email_data));
}
}
App\Jobs\SendingEmail::dispatch($podcast);
In Your Controller add this
App\Jobs\SendingEmail::dispatch($admin_email,$email_data);
I've been struggling with a property on one of my Symfony2/Doctrine objects that isn't persisted in the database. It's an array of objects that contain properties like label, key and value, but even if it is defined as a simple array of arrays, it doesn't show up.
Here is the way that the array is defined in the object that is normally persisted:
/*
* #Accessor(getter="getReceipt",setter="setReceipt")
* #Type("ArrayCollection<MyProject\ReceiptProperty>")
* #Expose
* #Groups({"details"})
*/
protected $receipt;
public function setReceipt($receipt) {
$this->receipt = $receipt;
}
public function getReceipt() {
return $this->receipt;
}
And here is how the object in the array is defined
/**
* #ExclusionPolicy("all")
*/
class ReceiptProperty extends APIObject {
/**
* #Type("string")
* #Expose
* #Groups({"basic"})
*/
public $label;
/**
* #Type("string")
* #Expose
* #Groups({"basic"})
*/
public $type;
/**
* #Type("string")
* #Expose
* #Groups({"basic"})
*/
public $key;
/**
* #Expose
* #Groups({"basic"})
*/
public $value;
public function __construct($data) {
$this->label = $data['label'];
$this->type = $data['type'];
$this->key = $data['key'];
$this->value = $data['value'];
}
}
By straight printing the objects before going into serialization with print_r, I can see that the data is there, but no matter what the configuration is, that field is never shown.
In an effort to help those that might have similar issues going forward, my problem was essentially an incorrect annotation.
In the first code block you'll notice that the annotation comment begins with /*
It turns out that JMS Serializer does not process comments that do not start with /** so effectively it was ignoring my commands. After updating the annotation comment, it worked as expected. It's always the little things...
I wanna pass class reference when dispatching the deluxe signals in AS3Signals ?
My code here for dispatch,
public var signal:DeluxeSignal = new DeluxeSignal(this);
protected function button1_clickHandler(event:MouseEvent):void
{
signal.dispatch(new GenericEvent());
}
and here i listen,
protected function creComp(event:FlexEvent):void
{
viewB.signal.add(onDeluxDispatched);
}
private function onDeluxDispatched(e:GenericEvent):void
{
trace(e.target, e.signal);
trace(e.currentTarget);
trace("SignalTest.onDeluxDispatched(e)");
}
But i received null in trace.
where i am wrong ?
from the documentation of DeluxeSignal class ( https://github.com/robertpenner/as3-signals/blob/master/src/org/osflash/signals/DeluxeSignal.as )
/**
* Creates a DeluxeSignal instance to dispatch events on behalf of a target object.
* #param target The object the signal is dispatching events on behalf of.
* #param valueClasses Any number of class references that enable type checks in dispatch().
* For example, new DeluxeSignal(this, String, uint)
* would allow: signal.dispatch("the Answer", 42)
* but not: signal.dispatch(true, 42.5)
* nor: signal.dispatch()
*
* NOTE: Subclasses cannot call super.apply(null, valueClasses),
* but this constructor has logic to support super(valueClasses).
*/
public function DeluxeSignal(target:Object = null, ...valueClasses)
it has to be declared and dispatched that way :
public class ClassName {
public var signal:DeluxeSignal = new DeluxeSignal(this, ClassName);
private function dispatch():void {
signal.dispatch(this);
}
}
then retrieved that way in the referenced class :
public class Parent {
private var childClass:ClassName;
private function bindSignal() {
childClass.signal.add(signalListener);
}
private function signalListener(classReference:ClassName) {
/* do your stuff with classReference */
}
}
i ran into same issue and that worked for me
Depending on your requirements you may not need to use DeluxeSignal. I'll use Willo's example to illustrate.
public class Parent {
private var childClass:ClassName;
private function bindSignal() {
childClass.signal.add(signalListener);
}
private function signalListener(classReference:ClassName) {
/* do your stuff with classReference */
}
}
Yes, we get a class reference. But this class reference is not the one that was passed to DeluxeSignal when it was instantiated, but instead it is the one that was passed to dispatch.
public class ClassName {
/* this is not the reference to 'this' that the listener gets. in fact,
all this one does is sit inside the signal as a property */
public var signal:DeluxeSignal = new DeluxeSignal(this, ClassName);
private function dispatch():void {
signal.dispatch(this); // this is the reference that the listener gets
}
}
The reference we passed into the constructor just sits inside a public property called target.
public function DeluxeSignal(target:Object = null, ... valueClasses) {
/* the reference is set as _target and is not used anywhere else in the
class other than in the setter/getter */
_target = target;
valueClasses = (valueClasses.length == 1 && valueClasses[0] is Array) ? valueClasses[0] : valueClasses;
super(valueClasses);
}
public function get target():Object { return _target; }
public function set target(value:Object):void {
if (value == _target) return;
removeAll();
_target = value;
}
So it seems the idea is to access this property when the listener is called, using a reference to the signal:
public class Parent {
private var childClass:ClassName;
private function bindSignal() {
childClass.signal.add(signalListener);
}
private function signalListener() {
/* not passing the reference in the dispatch() call means we can
still access the target at this point by using... */
childClass.signal.target;
/* but it just feels nicer to have the reference provided as an
argument rather than as a mutable property, right? */
}
}
Technically that works but it doesn't feel great to be getting a reference from what is a mutable property.
Where it might come in handy though is when using a dependency injection framework like Robotlegs, where the signal is injected into a command. Your command wouldn't have a listener with which to be provided a reference in an argument, but it would be able to access the reference from the signal via its target property.
The way Willo used DeluxeSignal here though, you can actually use the plain old Signal class to do exactly the same thing with less overhead.
public class ClassName {
/* note: no pointless use of 'this' in the constructor. instead,
just the types we will actually be providing to the listener */
public var signal:Signal = new Signal(ClassName, String);
private function dispatch():void {
signal.dispatch(this, "Whatever else you want");
}
}
And on the other end you get this.
public class Parent {
private var childClass:ClassName;
private function bindSignal() {
childClass.signal.add(signalListener);
}
private function signalListener(classReference:ClassName, foo:String) {
/* do your stuff with classReference */
}
}
So you get the same result for typing less code and for less inheritance overhead.
Where you might want to use DeluxeSignal though, other than when needing to keep a reference to the target in your DI frameworks, is when you're using native events. DeluxeSignal overrides the dispatch method to do some extra work with those.
I have an object "User" that has attributes whose accessability is declared as protected but which can be set directly via a magic __set-method.
Now PhpStorm signals this apparent inconsistency with a big red column on the right side.
Is it possible to explain to PhpStorm what is going on so this is not shown as an error any more?
EDIT :
I use PhpStorm 2.1.4
okay here is some code that exemplifies the issue (together with the so far suggested workaround from Alexey which sadly doesn't do it for me):
c.php:
<?php
/**
* #property mixed $a
*/
class c1
{
protected $a;
public function __construct() { $this->a = __CLASS__; }
public function __get($n) { return $this->{$n}; }
}
/**
* #property $a mixed
*/
class c2
{
protected $a;
public function __construct() { $this->a = __CLASS__; }
public function __get($n) { return $this->{$n}; }
}
test.php
<?php
require "c.php";
$c1 = new c1();
var_dump($c1->a);
$c2 = new c2();
var_dump($c2->a);
and the output:
string 'c1' (length=2)
string 'c2' (length=2)
and how it looks like in PhpStorm:
my goal:
either having PhpStorm "understand" the design or just getting rid of those annoying red marks everywhere while not impairing the error detection apart from this issue.
This is now working in PHPStorm 3 :)
Unfortunately this is a open request in our tracker, see
http://youtrack.jetbrains.net/issue/WI-4468
The only way to avoid this warnings now, is to add #property to $user's class declaration. i.e.
/**
* #property $name string
*/
class User {
protected $name;
}
$user = new User();
$user->name = "me";