Hook for page action buttons

[robertdown]

Create a new event and interface for injecting buttons into the page header rendered by OemrUI. Convert the current help icon, action icon, and expand icons into listeners to the new event. Move the pageHeading() rendering to Twig.

TBD

1. The Action Icon has some logic I need to still resolve
2. Create spot to inject custom Javascript to actually do something with your fancy new button.

[bradymiller]

@robertdown , just noted some escaping stuff. Otherwise code looks great to me :) (btw, I didn't test it)

[robertdown]

Updated the way javascript interacts with the interface

The interface dictates getAttributes() must return an array of attributes to be injected into the element. This means you could do the following:

public function getAttributes()
{
    return [
        "onclick" => "function(){ alert('do something'); }"
    ];
}

which would render the onclick attribute (Though the escaping would be problematic because it gets run through attr not a js-specific escape.

OR, you could leverage getClickHandlerTemplateName() and getClickHandlerFunctionName() which returns the name of the twig template containing your function and the name of the function itself. If you return those, twig will automatically add an event listener to your button.

Still some downsides here, Ideally, the template being included should only contain 1 function, named whatever your pass in getClickHandlerTemplateName(), however, it could be expanded and is now effectively a hook for any javascript you want. Not sure how to force a better solution though.

[sjpadgett]

@robertdown Installing this PR errors javascript with

And

[robertdown]

Hmmm, the patient finder page was one I tested against. Let me try to replicate

[sjpadgett]

Looks like a dependency scope issue. showActionClass looks like not making it into the DOM. You may need to change how it's declared.

[robertdown]

@sjpadgett I could not replicate the error.

Steps I took

1. docker-compose down -v to clear any lingering
2. git checkout master
3. git pull upstream master
4. docker pull openemr/openemr:latest
5. docker-compose up -d from development-easy to bring up a completely fresh instance

[sjpadgett]

Okay. I was treating it as a patch which should work and will still see what it takes to work that way. In the end I'll spin up a docker as you did.

[sjpadgett]

I think this has to do with the initial hide stats is in for the section and will account for why you're not seeing.
There is also the sql prepare error.
Or it could be my current dev environment so still checking it out

[robertdown]

Not sure where the SQL error is coming from, I'm not doing any DB interaction. I built this off of master and I think Brady is planning an actual release, not a patch in the coming days

[sjpadgett]

Nope sorry that was me not updating sql. I have a simple fix for the javascript error which I'll add to my existing PR.
With that we should be good. give me a call if need to.

[sjpadgett]

elementIcon is never defined I can see. It is defined within the show_hide click() handler so it would be out of scope elsewhere.
I don't see how this would work in any case because while show_hide click will set as soon as routine is exited then you lose scope. elementIcon needs to be assigned/declared somewhere global.

[robertdown]

Could you split it into its own PR. Still can't replicate so I want to test further

[sjpadgett]

If you're not seeing the error then you are not hitting the routine due to shouldDisplay not being set at around L-544 if (should Display) { ...}
After testing on this issue for awhile somehow something or flag was set that I no longer hit the errant code.
Easier if you give me a call to discuss. I can revert my fix if you want but the changes I made are necessary regardless if that section is never hit in our testing.

[robertdown]

I can give you a call Sunday at the earliest. I trust whatever your fix is