-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Treat "Selectbox" as an "Association UI" that's bundled with "Association Field" #10
Comments
I hope I'll find the time to post a longer answer later, but here is the short version: Yes, Association field still uses a select box as default "no interface" variant. Two reasons:
So it's a compromise right now and I understand your counter-arguments. |
Totally valid points, but I don't see how they would speak against what I proposed. I did not mean to get rid of the selectbox interface in this extension, I just said that it should be treated different from a conceptual (and technical) point of view:
So nothing would change for the user except the fact that he'd see "Association Interface: Selectbox" instead of "Association Interface: None" when inserting a new association field. That's all. Moving away from SBL to Association field is a big step either way, so I think we should use this change to get it right from the beginning instead of starting with conceptual compromises. As I wrote above this is directly related to the general question if and how Association UIs are able to build their own HTML output. In fact that's the main question I came from (while trying to build my beloved multicheckbox UI), but conceptually it all starts here with the question how Association Field includes the selectbox UI and builds the HTML output for that. I already tried to understand what's happening in the code, but I fear that the way UIs are treated right now is a little over my head - so I'm sorry that I just can write things up instead of help out with a coded proposal. Will work on my skills ;) |
I just took a look at how I could adapt a checkbox view I had built for an earlier experimental version of an association field and noticed that the "Selectbox"-HTML-output is still hardcoded into the
displayPublishPanel
-function and therefore isn't treated as one possible UI, but as a kind of master UI for the association field.Does that mean that association field always renders as a selectbox that afterwards is hijacked by an Association UI via javascript? If so I really don't like that approach (As explained here).
Or does the new Association UI concept already consider the possibility to hook into the
displayPublishPanel
-function and give the UI full control over the HTML output?If so - is this already documented somewhere?
If not - shouldn't that be the way to go?
In my opinion the move from SBL to Association Field shouldn't miss the chance to not only get rid of the "Selectbox" in the name, but also in the code. Instead of hardcoding the selectbox-output into the
displayPublishPanel
-function of Association field the actual html-output should be decoupled as "Association UI: Selectbox" and then be bundled with Association Field.This way it would be a more like a "Default UI" (that's treated like any other UI) instead of a "Master UI" (that's treated like something special).
Not treating the "Selectbox" the same way then other UIs also results in field settings that feel quite weird. The default setting for "Association Field" is "None", but results in a selectbox on the publish pages. Isn't a selectbox an interface too? Shouldn't it be treated like that on the settings page?
Having a default UI bundled with Association Field would also give developers a better start in building their own Interfaces.
@nilshoerrmann , @brendo - would really love to hear your thoughts about this...
The text was updated successfully, but these errors were encountered: