October: hasManyThrough display wrong relation table

[abstractFlo]

Expected behavior

i want to create orders with many order items over the customer create/update view.

Actual behavior

I want to create a order from my customer view. I have create a customer controller with a hasMany relation to orders and a hasManyThrough relation to items over orders. The relationRender show me the right table for orders, but after click in create order, modal is open with the price and qty field correct, but the relationrender table is wrong. it renders the order relation table instead of the items.

Reproduce steps

i've created a repo with my acme plugin to reproduce the step

https://github.com/abstractFlo/october-cms-hasManyThroug

October build

389

Images

The relation modal from customer side

The relation from orders side

[LukeTowers]

This is a result of the RelationController not supporting nested relations - i.e. you can't have a RelationController render a RelationController within itself. As a side note, the RelationController does not currently support HasManyThrough relations (as noted in #2508).

What you can do as a workaround for now (until these issues are resolved), is create a repeater grouping field for items that would only be shown in a relation controller context, and then use the beforeSave() method on your Order model to manually create and attach the items from the data provided by the repeater field. If you have any questions about how to specifically implement that workaround, feel free to ask.

[daftspunk]

Related issue #1959

[SebastiaanKloos]

I always use recordUrl in the view section of the relation config file.

[daftspunk]

@SebastiaanKloos makes a good point, this is the approach I use personally as well. Simply link to another controller.

The Relation Controller support does not appear to support nesting. We will look at writing a tutorial on how to address this soon. Moving to #1959 as this is a duplicate.

[jvanremoortere]

@SebastiaanKloos but what to do in the following situation:

Company

Contacts

Interests

Action:

• You create a new company
• Create a new contact in that company
  (Leaving out the interests field in the relation of contacts when creating a new company because that won't work...)
• Realise that you forgot to add something to the contact

Then you should always first save the company and update the contact later? Would rather see it support the nesting :) ... #MovingOn

[SebastiaanKloos]

Yes you are totally right. It is not a solution. It is a workaround till the nested relations are supported.

[daftspunk]

Just a heads up, nested relations probably won't be supported. Behaviors are designed to be helpful in speeding up development, not as the answer to every possible implementation.

We are working on a series of screencast tutorials that describe this in more detail. See the following repo for more details: https://github.com/daftspunk/oc-formist-plugin

Thanks @abstractFlo for providing the basis for this plugin.

[SebastiaanKloos]

@daftspunk For a better workflow, it would be better if when the recordUrl is set, the "create" button redirects to the create page of the controller of the related model.

The ID of the parent then needs to be available on de create page. So they can be attached to each other.

So you do not have to create a child in the modal and then go to the child via the recordUrl add relations to newly created child.

I would suggest to always use this method when using nested relations.

[daftspunk]

@SebastiaanKloos That is a great suggestion! You can specify the toolbarPartial option in the relation controller to render your own custom toolbar.

To render the standard buttons alongside the custom ones, use $this->relationMakePartial. For example to render the delete button:

<?= $this->relationMakePartial('button_delete') ?>

If you find success with this approach, feel free to add it to the documentation with a PR.

[Upperfoot]

I strongly suggest that this capability is added to October, it's one of the most used aspect of a CMS that has a relation heavy schema (which is how most websites are structured), what exactly is the crux of the problem? Is it simply that the controller can only attach relations to its initial model instance (page load), and the subsequent popups are hardcoded to always refer to its initial model.

If that's the case, can we not simply keep a unique reference to subsequent popups so they are always separate? Rather than referring to its initial reference?

[LukeTowers]

The base of the problem is that October's RelationController doesn't support nested relations. While this is technically possible to implement (and would be an awesome feature to have), we simply don't have the time or motivation to work on such an feature given that use cases that are needed for it can be implemented yourself by using the existing resources available to you in October. See http://octobercms.com/support/article/ob-21 for more information on implementing nested relationships yourself. Now, if you really really want nested relationship support in the default relation controller, you can either open a bounty for it https://www.bountysource.com/teams/october or implement it yourself and open a PR for your changes.

[Upperfoot]

That's all fine and I understand your motivations, I just want to collaborate to get to its root cause and resolve it.

The base of the problem is that October's RelationController doesn't support nested relations

But why doesn't it support it? Is there something we can do to resolve it? Is there a limitation of the current implementation and what is that limitation?

[LukeTowers]

Because it's only setup to support one level of relations. It's not a bug so much as a factor of how the current implementation is structured.

There's a lot involved with supporting such a recursive setup. Even when you just take into account a single Form widget, you have to make sure that every formwidget and formfield within that main form is bound to the controller, on every request made. If they're not, then you'll get error messages about how such and such AJAX handler registered by a certain formwidget was not found. This compounds when you're talking about doing it for multiple relationship levels and ensuring that the aliases used by each of these formwidgets on every level of the relationship don't conflict with each other (the aliases are how October knows which specific widget instance you are referring to. This is something that has to be considered for both formwidgets and the list widget for each relationship.

On top of all the handlers that need to be in the right places at the right times, you are also faced with the question of how do you structure all of this information? How do you setup such nested relationships in config_relation.yaml? config_relation.yaml (where you define the relationship configuration for the RelationController behaviour) is tied to controllers, fields.yaml (where you define the fields that render the RelationController behaviour) is tied to models. Are you doing autodiscovery and support in that manner? Or do you get users to specify each level of the relationship nesting in the config_relation.yaml? Then how are you going to structure the data within the RelationController behaviour itself so that it can accurately display and modify the required information on each level of the relationships?

This is a lot of stuff to factor when adding such support. Like I said, it's totally doable, but when considering the cost/benefit analysis of adding such support, we simply haven't found that it is worth enough in the benefit category (easier support of nested relationships for our users) to make it worth the cost category (the voluntary investment of our time into making those design decisions and then implementing it in the code) yet.

If the cost/benefit analysis were to change, i.e. the benefit going up (receive a worthwhile bounty for our time invested into adding such support) or the cost going down (instead of implementing it ourself, just having to review and test somebody else's implementation provided in a PR), then I could see such support being added, but for now it's simply not worth our time; especially given that it's not a question of such a setup being impossible in October (because you can always implement a more specific solution to your case as demonstrated in http://octobercms.com/support/article/ob-21) - simply a question of making the development process slightly faster by allowing such support to be implemented by developers through YAML changes or an otherwise simple process.