civix: flow of questions

[totten]

We might want to go back to hacking the help variable for the moment. When I hit "View Source" on the profile form, I can see that this snippet shows up in several different spots:

$('#current_employer').crmAutocomplete({'action':'publicget'},{'field':'sort_name'});

To understand why this happens, consider:

1. Postfilter applies to *every* template compilation that occurs during the page request. There are a lot of templates that make up a given page.

2. This is mitigated in typical usage because many of the templates have already been compiled and cached (templates_c/...) before viewing the profile page, but...

3. It's aggravated by inline Smarty templates. Apparently, HTML_QuickForm_Renderer_ArraySmarty::_renderRequired uses an in-memory Smarty template to represent the red '*' next to form fields. (To see this in action, you can call devel's ddebug_backtrace() in publicautocomplete_civicrm_add_js().) That in-memory template gets compiled during every request -- which means that we're guaranteed to have the postfilter run at some point during the request. It also means that the Javascript gets outputted next to every required form element.

4. If you really wanted to take the postfilter route, I guess one could hack further with something like:

Code: [Select]

  function publicautocomplete_civicrm_add_js($tpl_source, &$smarty) {
    ...
    global $need_publicautomplete_js = TRUE;
    // generated template should respect the flag
    $tpl_source .= '
      global $need_publicautomplete_js;
      if ($need_publicautomplete_js) {
        echo '<script>...</script>';
        $need_publicautomplete_js = FALSE;
      }
    ';
    ...
  }

The output would still be positioned arbitrarily (depending on the mix of template compilations and form fields), and the snippet might bleed into irrelevant templates used for other page requests (via template_c/...), but the impact would be limited by the global variable.

At best, I could imagine this technique being tidied up and used to inject <script> tags (which can be positioned arbitrarily) -- but it seems prohibitively complex to inject HTML. The crux of the problem is that the interface for postfilters provides the compiled source -- but it doesn't tell you the name of the template being compiled.

I really only suggest these things because I like to sound clever sometimes -- not because it's a good idea. The best thing is to use the 'help' hack or to patch core. If compatibility is a big concern, then make a stink about backporting the patch.

[totten]

Tangential note: there was a bug in the civix template which produced publicautocomplete.civix.php that breaks installation. You should search that file for "foo" and replace it with "publicautocomplete".

[xavier]

Hi,

Didn't notice it's called for every include as well. seems to be another way to inject in smarty
http://www.smarty.net/docsv2/en/api.register.compiler.function.tpl

For the sake of it.

Agree the best is probably to create a civicrm_add_js

Something I find missing in the drupal version (or that I missed) is to wrap by default js code into an anonymous function to avoid namespace pollution.

And talking about that.  I prefer using a static instead of a global for   $need_publicautomplete_js

[totten]

That is another neat Smarty API.

The API for registering JS is roughly item #3 in my current queue.

Regarding the static, I agree that it can be better than global (i.e. at providing encapsulation). For that snippet, 'global' was required because it's liable to be injected into multiple .tpl/php files. (Although the exact number depends on both the design of the active tpl's and the list of pre-compiled tpls.)

[xavier]

Hi,

Did test the wrapping everything into an anonymous function to avoid polluting the global namespace and enforce good practices by default

https://github.com/TechToThePeople/tobechecked/blob/master/tobechecked.php

Works (that's not the complete add_js function, just generating the js). Both options are useful IMO, eg when there is already a civicrm hook that exists to alter the page and inject the js

[totten]

Last night, I spent time working on this and created a ticket:

  http://issues.civicrm.org/jira/browse/CRM-10593

It turns out that we already had a helper called:

  CRM_Utils_System::addHTMLHead($string)

but it wasn't supported well across different UF's. In branches/v4.2.mixin, I've fixed it for D7 and implemented it for WP -- I'm guessing it still works in D6 and haven't tested Joomla yet. (My dev env needs some attention to run bleeding-edge Civi under Joomla.) It might make sense to add wrappers to handle the typical cases of registering JavaScript and CSS.

[totten]

The work for CRM-10593 (/branches/v4.2.mixin) has been tested with D7, WP3.4, and J2.5. It adds support for the following six examples:

Code: [Select]

<?php

require_once 'regionex.civix.php';

function regionex_civicrm_config(&$config = NULL) {
  _regionex_civix_civicrm_config(&$config);
}

function regionex_civicrm_buildForm( $formName, &$form ) {
  if ($formName == 'CRM_Contact_Form_Search_Basic') {
    CRM_Core_Region::instance('html-header')->add(array(
      'markup' => "
        <script type='text/javascript'>
        alert('hello from region(html-header) via markup');
        </script>
      ",
    ));
    CRM_Core_Region::instance('html-header')->add(array(
      'template' => 'CRM/Regionex/head.tpl',
    ));

    CRM_Utils_System::addHTMLHead("
    <script type='text/javascript'>
    alert('hello from addhtmlhead');
    </script>
    ");

    CRM_Core_Region::instance('page-header')->add(array(
      'markup' => '<div style="color:red">Extra header!</div>',
    ));
    CRM_Core_Region::instance('page-body')->add(array(
      'markup' => '<div style="color:red">Extra content!</div>',
    ));
    CRM_Core_Region::instance('page-footer')->add(array(
      'markup' => '<div style="color:red">Extra footer!</div>',
    ));
  }
}


[totten]

Per request, I've also implemented more sugary syntax for including Javascript and CSS. When calling the add() function, you can alternatively include one of these parameters:

 - script: string, Javascript code
 - scriptUrl: string, URL of a Javascript file
 - jquery: string, Javascript code which runs inside a cj(function($){...});
 - style: string, CSS code
 - styleUrl: string, URL of a CSS file

Note that you have discretion to include the JavaScript in the HTML header (region "html-header") or in the page footer (region "page-footer") -- which is commonly used to tweak performance.

(Edit)

Although a module can insert <script> and <link> tags which reference a URL, the module will still have trouble reliably linking to resource files (.js/.css/.png). This is a separate problem which stems from the fact that admins choose their own extensions base directory -- and Civi doesn't know the public-facing URL of that directory.

[totten]

After some discussion, we decided to tackle the problem of linking to resource files in 4.2 and to hide some of the details of CRM_Core_Region. This will require sysadmins to perform an extra configuration step (i.e. specifying the "Extension Resource URL".)

For a description of how to work with resource files, see:

http://wiki.civicrm.org/confluence/display/CRMDOC42/Resources

For details on how this was implemented, the see "Activity" history of branches/v4.2.mixin:

https://fisheye2.atlassian.com/changelog/CiviCRM/branches/v4.2.mixin

[Luciano S.]

Hi,

I started to play with the "civix" extension creator  and looks promising.
I've created some demo pages with civix generate:page but what about forms? How can I create a Form, not a Page?
There i no <b>generate:form</b> or somthg similar yet

cheers!

[totten]

I think we'll get to documenting/generating form code at some point, but it's a deeper topic that will take more work (and is more likely to break in future releases).

For the moment, you might try this old document. There's a section called "Web Forms":

http://arms.dl.locker10.com/devel-doc/cheatsheet.html

It's a bit terse, but you may be able to use it if you've already played with "generate:page".

[mokfe]

Should add a mention of the minimum php version (cli 5.3?)

i am voting for it =)