Just in passing I saw this earlier:

  public function prepare(Request $request) {

    parent::setData($this->ajaxRender($request));
    return parent::prepare($request);
  }

We don't usually directly call the parent like this for another method. There is no setData method on AjaxResponse so we're just calling JsonResponse::setData, which we can just do with $this->setData().

If there is a good reason for this, apologies in advance :)

CommentFileSizeAuthor
d8.ajax-response-parent-call.patch546 bytesdamiankloip
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fledev.com’s picture

Hi,
your point is right, the $this-> and parent:: are equal in that situation. You should not forget that while willing to extend the AjaxResponse's class with setData method would bring confusion into the prepare method.
While using the parent:: syntax, it is clearly defined that the extended - parent class method should be used there. The $this-> syntax is taking the parent if the actual object doesn't have it or the current object method.

Here's a small experiment which I've used to clear this:

class Main_class{
  public function one(){
    return ('Im the one function from Main_class');
  }
}

class Child_class extends Main_class{
  
  /* comment out the following function */
  public function one(){
    return('Child class one');
  }
  
  public function Child_class(){
    echo $this->one();
  }
}

$tst_var = new Child_class();

Please process your issue regarding the solution or close it.

damiankloip’s picture

I'm not really sure what your point is there :/

The fact that the parent class is used in that situation means you cannot use an overridden setData method. If it is not implemented on the class it will always inherit from the parent class. So $this->setData() will either get the current class or the inherited parent method. Isn't this just standard OOP?!

damiankloip’s picture

Issue tags: +Ajax

.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

It's the same during runtime, but it's not the same in terms of expression of code. We call another function here, and not "extend" the function here.

This feels ready to fly.

catch’s picture

Status: Reviewed & tested by the community » Fixed

Committed/pushed to 8.x, thanks!

Automatically closed -- issue fixed for 2 weeks with no activity.