-
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: Allow the UI to override the html-output of "displayPublishPanel" #16
Comments
This is directly related to another Proposal I made: Treat "Selectbox" as an "Association UI" that's bundled with "Association Field" Outsourcing the rendering of the default selectbox from |
I think this is a good idea, but I can probably explain why it wasn't constructed this way though. The idea to decouple the UI from the Field was trying to achieve a couple of things. One of those was making the barrier to create a new UI much smaller and from this perspective, allowing someone to do so just with Javascript and CSS ticks that box. The downside is that a developer who is PHP inclined now is in a bind as there is no way to replace the output without learning JS, or extending the field (which defeats the purpose at this point!) I wonder how we can get the best of both worlds. One idea is to abstract all of Thoughts? |
Thanks, that's good to hear :)
But that's kind of making quite a lot of assumptions about what developers might be good at or might want to achieve, isn't it? I'm defintively better with CSS and Javascript than I am with PHP, but I'd still prefer to build a clean and solid checkbox-view from ground up (using PHP/HTML/CSS) than hijacking a selectbox and transform it to selectboxes (using JS/HTML/CSS). Regarding what I'm aiming for this is not just totally overcomplicated but also feels plain wrong. But my main point is: my proposal doesn't make things more complicated for developers as I don't want to force them to output their own html. They just should be able to do so easily if we want to.
Don't think that would be too hard, as everything I'm proposing here and in the other related issue wouldn't take anything away from how AF is working right now - it would just add flexibility and a cleaner and more logical way to treat association interfaces.
I don't know exactly what you mean technically (as I'm (sadly) not really familiar with the concept of delegates) but if I understand you right this might be exactly what I'm talking about ;) My proposal from a conceptual point of view:Right now interfaces for AF consist of these two files to build the interface:
My proposal would be to prepare AF to expect/process an optional third file:
This file could then include a function that might get called by Conceptually this might work by checking for a custom render-function before using the default selectbox-widget (Which is still called as fallback/default output):
This code-snippet (beeing meant for lines 624-628 of field.association.php) is just meant to illustrate what I want to achieve - I'm pretty sure this can be done much more clever using delegates and such ;) That's why I'm not trying to code it myself. To deliver an example for how aui.interface.publish.phpshould work the the default selectbox-view could be decoupled and treated just like any third party interface for AF - that would fix the logical flaws I'm describing here and offer a good starting point for developers that want to build their own interface. Does that make sense to you @brendo? What do others think? |
At the very moment attaching an UI to Assocations Field technically follows a concept that to some extent still feels wrong to me.
When discussion about a new "A New Take on Subsections: An Association Interface" came up last year I really hoped for Association Field to finally offer a rock-solid concept that wouldn't force UIs to skin/hijack the interface of SBL, but instead offer a flexible and hopefully future-proof way of replacing/extending the interface:
In most parts these wishes are fulfilled by the way Association UIs are managed now, but one thing really spoils the party:
The field's
displayPublishPanel
-function still always renders a selectbox and after that the UI is attached/transformed by some black magic (and javascript).I know this works fine for the one UI this field intentionally was built for, but not every UI wants to build upon an already rendered selectbox.
Instead it should be possible for every UI to bring it's own html-output in form of a
renderPublishInterface
-function that hooks into thedisplayPublishPanel
-function of AF and overrides the rendering of the default selectbox view.In my eyes this is the missing link, that would make this UI-stuff somehow complete.
Without it the UI still isn't as independent, flexible and interchangeable as it should be.
The text was updated successfully, but these errors were encountered: