Working with DataObjects

[henzigo]

Hello,

we would like to migrate from our custom administration to Sonata Admin. Currently I'm trying to adapt the Sonata to our needs, but we could use some help.

Our workaround is:

For every entity we have DataObject which is created from our Factory method. The saving is then done using the method in Facade. For Example for Product entity:

// I want to create new Entity
// Factory returns App\Product\ProductData
$productData = $this->productDataFactory->create();
// create form with $productData
// submitting form
$product = $this->productFacade->create($productData); // This method will create entity with all additional tasks that must be done

// I want to edit existing Entity
$productData = $this->productDataFactory->createFromProduct($product);
// create form with $productData
// submitting form
$this->productFacade->edit($id, $productData); // This method will edit entity with all additional tasks like recalculations etc.

For list objects in datagrid/filtering we want to use entities.

At the moment we are a bit at an impasse because of some of the methods that are final. In the past, there was a way to do this using the https://github.com/mishaklomp/SonataDtoModelManager/blob/master/README.md extension, which did +- the same thing. I know that I can implement custom AdminInterface, but I'm trying to find simplest way to achieve my requirements.

Currently I'm stuck with getFormBuilder method where is data_class set by function $this->getClass() and I'm not able to set my DataObject to the form.

I would like to ask if it would be possible to do something like this without having to implement the whole AbstractAdmin class.

Thank you for your answers

[zyberspace]

The getClass() method gets used by quite a few other methods and as you can only configure one class per admin, i would say that having different object for list, create, edit, delete, etc. is simply not supported.

Even if you could still override those methods, it would always feel hacky and you would probably get a few errors from time to time, due to the code not expecting the admin class to change depending on the route.

What i would suggest instead is having two different admins, one for your list and batch actions and one for you create, edit, show and delete actions. (Literally configure one admin for your entity and one for your DTO)
You could then set a custom controller for those admins that overrides the actions and switches the admin based on the current action.

Basically you have two admins that both use the same controller, but the controller selects the admin based on the current route / action.

One drawback i see is that this would result in two routes for each action, e.g. /mycompany/myobject/list and /mycompany/myobjectdto/list, but you could implement a redirect to the correct route in your controller.