What is the benefit to removing these methods from the PHP side and requiring it to be done from the JavaScript API beyond the separation of church and state (or in this case PHP and JavaScript)? Remember I'm absolutely terrible here with JavaScript stuff so I honestly don't know what the before and after looks like or why one way is preferred over the other or if changing methods is going to make things more complex for whomever is working with this part of the code.

@mbabker you didn't like the idea passing functionality to data attributes, right?
So this will prevent that. Check the readme xtd button on the other branch and you'll see why these functions are totally useless. It's old, working but redundant code, if we step up a bit the xt-buttons implementation (mostly that's the place these are used)

I'm not a big fan of pushing executables into data attributes, personally my uses of them are more for actual data I need to make available, not callback type stuff.

Other big comment.

There are things you can do from the PHP API that you can't do from the JavaScript API. In the case of core this might be totally irrelevant but for extensions it does become important (i.e. you have no way in JavaScript alone to make decisions based on whether the user is authenticated or a guest since we do not push user data into the JavaScript data). I know that's a terrible example in this context but it does demonstrate why even if core doesn't take advantage of them the hook points need to remain available.

So long and short, I don't think we can make blanket decisions on removing all the JavaScript generating code and hook points from core. We can possibly structure the core extensions in a way that these aren't used in favor of a more pure solution, but I think it's borderline irresponsible to just completely remove them and tell folks their only hook points for some stuff is through JavaScript and using other plugin events to ensure the needed data is loaded or created inline to the HTML document to make it work.

As an example, xtd button readme right now has this php code:

$getContent = $this->_subject->getContent($name);
$js = "...
var content = $getContent
..."

which is the same as this js code:

var content = Joomla.editors.instances[editor].getValue();

Well, OK, now that I've looked at that specific example, it's not so simple. In 3.x the getContent() call is to a JEditor instance (presumably someone could subclass it and have it behave differently) which just has a really awkward way of dispatching a onGetContent event. 4.0 has that converted to a proper event call. So by that alone I'd say that's not a good idea because of what I said above about removing hook points (if you change that to a JS only thing and remove the event call).

Like I said before I get what you're trying to do, really. But digging into at least this one case, it seems like it's adding more complexity in favor of a "pure" solution.

If you can demonstrate how you could replicate the event call without losing functionality I could probably support that.

If you can demonstrate how you could replicate the event call without losing functionality I could probably support that.

Lost you here, care to elaborate a bit more?

Using #12409 (comment) as your example change, you replace the PHP call (which triggers a plugin event) with a single line of JavaScript without that event call. So I think if you're going to replace the PHP function call generating that JavaScript there needs to be a suitable replacement otherwise we're removing functionality from core.

Doable, let's use the current code of none.php as an example:
php:

    /**
     * Inserts html code into the editor
     *
     * @param   string  $id  The id of the editor field
     *
     * @return  void
     */
    public function onGetInsertMethod($id)
    {
        return null;
    }

javascript:

function jInsertEditorText(text, editor)
{
    insertAtCursor(document.getElementById(editor), text);
}

As is right now the js already override the plugin event. The ~right~ implementation would be that the script none.js should had the result of the particular plugin event onGetInsertMethod. So this could be mitigated by triggering the events and passing the result to the initialisation script (maybe through scriptOptions). So all bases are covered (I think)

@mbabker how about:
php side:

JFactory::getDocument()->addScriptOptions('xtd-readmore', $this->_subject->getContent($name));

javascript side:

var content = (new Function('return ' + Joomla.getOptions('xtd-readmore')))();

We don't deprecate anything, and we get clean output.

What do you think?

I am not realy in the ropic what is it.
I always thought it some J1.5 legacy, made by "PHP guys".

Editor it is mainly Client side code, so I think we can remove this for J4. And replace with Client side API. But need something nicer than ugly function jInsertEditorText(text, editor) ?
Like Joomla.getEditor().setValue() ? ... well, nevermind, just random thoughts ?

But I would not do for J4:

var content = (new Function('return ' + Joomla.getOptions('xtd-readmore')))();

it is the same Egg but in profile

@Fedik for j4 some kind of event management is needed.
Let's say that the PHP function on save is removed and now editor need to do that in their initialisation code. Right now they could use editor.form.addEventListener('submit'.... If we end up with many such calls (e.g. calendar) something will be overridden...
So apart form introducing some API for registering these behaviours we still need event system...

PR: #12561