Closed edisonywh closed 3 years ago
I'm not sure if this is the best way since users now need to duplicate implementation for Index and Single.
Maybe one way to help is allow users to "tie" a "Single" module to a Index? For example something like this:
defmodule YourApp.Resource.Single do
use Backoffice.Resource.Single,
parent: YourApp.Resource.Index
end
This way it communicates the relationship between Single & Index, and also mean that user don't need to redefine all the resource opts. Not sure where to go from here.
Better handling of associations (still a bit to be desired)
Massive change of API, moved from a single
Backoffice.Resources
module that users have to use to two separateBackoffice.Resource.Index
andBackoffice.Resource.Edit
. Not sure if this is exactly the best idea, but I wanted a better UI to show associations (especially has_many), and the ideal scenario was a table/index view near the bottom of the edit page, but with the existing pop-up modal this is not really feasible. So as part of that change, I decided to break them to two separate modules.