Announcement

Collapse
No announcement yet.

Action on loading entity page

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Action on loading entity page

    Hi,

    I want to perform an action when someone opens up some contact profile, like loading a field via script.


    At first I imagined i could do this via hooks on Espo: https://docs.espocrm.com/development/hooks/

    In this page tho, I have not seen a hook refering to when a page gets loaded, so I don't know if it's possible to do this via hooks.

    I imagine the Hook should be something like onPageLoad, onEntityLoad, onLoad ...


    Does Espo supports this kind of action? Using hooks or with some other tool

    Thanks in advance
    Last edited by luizthomasini; 08-03-2021, 07:31 PM.

  • #2
    Hello,

    To catch an event like view rendering requires front end coding (javascript).

    Hooks are a back-end tool that allow you to inject some actions before or after a record is persisted in the database, but in a client-server architecture, the server is never aware of when a page is loaded or any other client event, it only sends the data to the client, so the browser is the one that detects this type of event.

    If you are comfortable coding with javascript, you could implement logic in a custom Contact detail view script, to be triggered when the view finishes loading and it is rendered, something like this:

    1) Create a custom view script for the Contact entity

    client/custom/src/views/contact/record/detail.js
    Code:
    define('custom:views/contact/record/detail', 'crm:views/contact/record/detail', function (Dep) {
    
        return Dep.extend({
    
            afterRender: function () {
                Dep.prototype.afterRender.call(this);
                // WRITE THE CODE HERE FOR THE ACTIONS THAT YOU WANT TO PERFORM AFTER THE CONTACT VIEW HAS BEEN RENDERED
        });
    });
    2) Create a custom clientDefs for Contact to let Espo know that it should invoke a specific script to render the record detail view

    custom/Espo/Custom/Resources/metadata/clientDefsDefs/Contact.json
    Code:
    {
        "recordViews": {
            "detail": "custom:views/contact/record/detail"
        }
    }

    Comment


    • #3
      You don't need custom view.


      Use little trick: https://docs.espocrm.com/development/custom-buttons/

      Create detailActionList button without label, name, acl.

      Code:
       "detailActionList": [
      "__APPEND__",
      {
      "data": {
      "handler": "custom:my-action-handler"
      },
      "initFunction": "initHiddenButton"
      }
      ],
      and the initFunction function will be executed once when you open entity detail view.

      Comment


      • telecastg
        telecastg commented
        Editing a comment
        I agree that order is applied to php not js, however you define which view is invoked in your entity's clientDefs file which is merged at metadata.php which is controlled by "order" for example:

        Espo/Modules/ModuleA/Resources/metadata/clientDefs/Case.json
        Code:
        "recordViews": {
            "detail": "moduleA:views/case/record/detail"
        }

        Espo/Modules/ModuleB/Resources/metadata/clientDefs/Case.json
        Code:
        "recordViews": {
            "detail": "moduleB:views/case/record/detail"
        }
        If moduleA order is 30 and moduleB order is 20, "moduleA:views/case/record/detail" will take precedence in namespaces where Case does not have a detail record view defined in its Case.json clientDefs. (Crm, the module where "CasoObj" is defined has an order value of 10)

        However in the ModuleB namespace, "moduleB:views/case/record/detail" will be always used because it is explicitly invoked.

        If you just define a custom detail view and not call for it in any clientDefs (directly or indirectly), Espo will ignore it because it uses metadata as the "blue print" to build the back end (entityDefs) and the front end (clientDefs).

        Code:
        define('moduleA:views/case/record/detail', 'moduleB:views/case/record/detail', function (Dep)
        define('moduleB:views/case/record/detail', 'moduleA:views/case/record/detail', function (Dep)
        Is in my opinion, bad coding, because custom modules should be treated as encapsulated "extensions" and should only inherit, if required, from Espo's base code, otherwise why bother with different modules if everything is going to be interrelated anyway ?.
        Last edited by telecastg; 08-12-2021, 01:12 AM.

      • dimyy
        dimyy commented
        Editing a comment
        In my version, it does not matter at all what modules are now and what will be in the future

        This is the advantage :-)

      • telecastg
        telecastg commented
        Editing a comment
        Fair point

        Best Regards
    Working...
    X