Proposal: Allow the UI to override the html-output of "displayPublishPanel"

[twiro]

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:

I'd really love too see the handling of different UIs beeing developed as a kind of field-plugins/addons that hook into a UI-Management provided by the fields itself instead of going the skinning/hijacking way where a "Select Box" is turned into "Not a Select Box anymore" by a UI-Extension. That's the way this had to be done in Symphony most of the time (like using "Multiselect to Checkboxes") and it always felt kind of wrong to me. – (Quoting myself)

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 the displayPublishPanel-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.

[twiro]

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 displayPublishPanel into an own "Selectbox UI" that's treated like any other UI (apart from beeing the bundled default-choice) would not only solve the conceptual flaws described at issue #10, but also be the first usecase and a good example of how the method described above could actually work.

[brendo]

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 displayPublishPanel as a delegate and then have the Association UI Selector listen for this delegate and construct the markup. We could potentially watch the variables that are passed, and if they are not filled, it will default to existing behaviour. This is a duplication of existing code, but it'll allow for people to fully override the markup at a PHP level, or skin the existing markup.

Thoughts?

[twiro]

I think this is a good idea...

Thanks, that's good to hear :)

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.

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.

wonder how we can get the best of both worlds.

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.

One idea is to abstract all of displayPublishPanel as a delegate and then have the Association UI Selector listen for this delegate and construct the markup. We could potentially watch the variables that are passed, and if they are not filled, it will default to existing behaviour. This is a duplication of existing code, but it'll allow for people to fully override the markup at a PHP level, or skin the existing markup.

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:

• aui.interface.publish.css
• aui.interface.publish.js

My proposal would be to prepare AF to expect/process an optional third file:

• aui.interface.publish.php

This file could then include a function that might get called by displayPublishPanel and return custom-html-code that replaces the default selectbox-html-code that AF delivers right now.

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):

// Build output using an interface
if ( FIELD HAS AN INTERFACE AND THE INTERFACE INCLUDES A AUI.XXX.PUBLISH.PHP-FILE ) {

    // Let the interface render the output


// Build output using the default selectbox widget as fallback
} else {

    $label->appendChild(
        Widget::Select($fieldname, $options, ($this->get('allow_multiple_selection') == 'yes' ? array(
            'multiple' => 'multiple') : NULL
        ))
    );

}

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?