[RFC] Ability to edit certain relations as "SubResource" on a resource edit page #319
mallardduck
started this conversation in
Ideas
Replies: 1 comment 1 reply
-
Here is a screenshot of the working proof of concept in PR: #318 |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
TL;DR:
The gist of the idea would be a mechanism similar to RelationManager that can be registered to a resource.
However this differs as this would provide an on page form for the SubResource.
The main target in mind would be data stored in
HasOne
relationships that simply don't need a dedicated page/resource.Description:
The main objective here would be for exposing fields that for reasons are stored as a separate Model, but is conceptually part of the same resource. Put another way - the entities this feature would expose to a resource would not fit a model that requires a UX for attach/detach.
One concrete example of this might be a very simple blog implementation where SEO/open-graph meta-data is stored in a table separate the main blog posts. In this case a Developer may be requested to facilitate the creation of a single page where both the Blog Post and this meta data can be edited. While the RelationshipManager can facilitate this for the most part - this feature would allow devs to create a more seamless user experience.
Ultimately, this could be accomplished via two forms on the same page (i.e. two different save/cancel actions) or by a subform concept with a single set of action buttons. However the former is likely easier than the later - but potentially both mechanisms could be supported alongside each other.
Future
As mentioned, the initial build could/should probably be simply adding a second form for the sub resource.
This is a good default user experience for the new feature, however this could be expanded later.
A no brainer, would be an option to embed the fields into the main form directly to circumvent two fields.
The other areas of expansion could be around more complex relations that could benefit UX similar to
HasOne
.So potentially this could be expanded to support
HasOneThrough
as well and other such similar relations.DB Example:
Note: both tables here are truncated just to show the basic
HasOne
relationship in mind.blog_posts:
blog_post_metas:
Beta Was this translation helpful? Give feedback.
All reactions