How can i keep pyro from forcing decorators on my objects

Created 6 years ago by mattcdavis1

I'm not sure what the point of adding decorators to everything is, but it's frustrating when stuff like this get's forced on me. In my controller i'm doing the following:

$propertyBuilder = app('form.property')->make();
$propertyForm = $propertyBuilder->getForm();

if ($propertyForm->getResponse()) {
    // get id of entry and redirect to edit
    return redirect()->route('account.listings.edit', [$propertyForm->getEntry()->id, 2]);
}

$step = 1;

return view('theme::account.listings.form', compact('propertyForm', 'step'));

In my view, instead of getting a property form object, i'm getting a decorated object. This is causing issues because in other places i'm not getting a decorated object. I have a macro for rendering front end forms and the specific issue that this is causing is that sometimes a labels is accessed via field_type.object.label and in other cases it's just field_type.label.

Is there way that i can pass my variables to a view with pyro decorating it? Can i get rid of decorators altogether?

piterden — 6 years ago

Maybe you just call getObject() when you need it? Also I've seen undecorate() method inside decorator.

Link

ryanthompson — 6 years ago

Decorating is a best practice for view layers and decorating is SUPER annoying - so we auto decorate in the view layer. If you like though you should be able to treat the presenter almost JUST like the object itself as it passes most missed get / call attempts.

Collections also have an undecorated() (alias for undecorate()) as well that will accomplish this on a larger scale.

Lastly though you should not need to access the object directly: Aaand while looking for a good file (wrapper.twig in forms partials) looks like there might be a weird bug for label.. Cause I use object there and only there as well which is odd.

Link

ryanthompson — 6 years ago

https://github.com/anomalylabs/streams-platform/blob/1.2/resources/views/form/partials/wrapper.twig#L13

Link

mattcdavis1 — 6 years ago

Yeah - i'm not sure why that label is coming through differently in certain contexts. I just happened to notice this presenter issue while i was troubleshooting it. I had to add the below to make my macro work:

{% if field_type.object is defined %}
    {% set label = field_type.object.label %}
{% else %}
    {% set label = field_type.label %}
{% endif %}

I guess my experience with presenters in Pyro so far is that the additional complexity and issues that arise from using them outweighs the value but maybe there is value that these are adding that i'm not aware of. My other concern is just the additional overhead performance-wise of this extra layer.

Link

ryanthompson — 6 years ago

I'll try and dig into that label issue - Presenters though are a pretty important component of separation of logic. ANYTHING made for view/presentation purposes should go in the presenter. By default field types provide most the heavy lifting but they are super helpful on the entry as well (and other items). Actually most all heavy lifting is already in there (above I was talking from a perspective of building new / extending) so the benefit might be harder to see :-/

Link