CiviCRM Community Forums (archive)

Yesterday i noticed something strange when trying to extend the EventInfo form in a civicrm extension.

I'm not sure if i'm doing something wrong, or how this should be improved, so i'm posting it here first for some discussion.

I tried to create an adjusted form for the eventinfo form. (In my use case to create specific event type add forms). So i created an extension in the namespace CRM_CustomEvent. There i started by creating a specific manageEvent class
class CRM_CustomEvent_Page_ManageCursus extends CRM_Event_Page_ManageEvent
to extend the Manage event (civicrm/event/manage) page. This works as expected. So i tried to do the same for the EventInfo form.
class CRM_CustomEvent_Form_ManageEvent_CursusInfo extends CRM_Event_Form_ManageEvent_EventInfo
This however fails. The reason is that this form has an addSelect form element, which automatically tries to detect the used entity.
(In the add Select declaration)
  function addSelect($name, $props = array(), $required = FALSE) {
    if (!isset($props['entity'])) {
      $props['entity'] = CRM_Utils_Api::getEntityName($this);
    }
...
This goes to the CRM_Utils_Api::getEntityName($this) function which tries to find the corresponding entity. This tries to use the parts of the class name, to find that entity. In the case of CRM_Event_Form_ManageEvent_EventInfo it finds it in the second part of the class name.
In my custom class however class CRM_CustomEvent_Form_ManageEvent_CursusInfo it doesn't and it crashes on the exception in  the CRM_Utils_Api::getEntityName($this) function.
The solution i use for now is to rename my class from class CRM_CustomEvent_Form_ManageEvent_CursusInfo to class CRM_Event_Form_ManageEvent_CursusInfo, however this sort of 'pollutes' the extension structure, and feels like a hack. So i actually want to remove this 'classnaming hack'.

If i don't call the form building method from the parent class, i can recreate it by giving explicitly the entity type to the addSelect methods, but i actually just want to extend the form, and adjust some of the elements, instead of completely recreating it.

Possible options, could be:

• Explicitly add the entity type in addSelect methods where the class name isn't the entity type, adn remove the other pattern matchings in static function getEntityName($classNameOrObject)
• Add the entity type as a class attribute, so we can explicitly set it when overriding this class
• ... Other suggestions welcome ;-) [/tt]
  

I'm not sure which option would be the best way to go. I'm willing to file an issue and PR, if i get some direction to know wich way is best.

That's indeed what i'm doing ;-)


class CRM_Event_Form_SearchCursus extends CRM_Event_Form_SearchEvent {

  /**
   * Build the form
   *
   * @access public
   *
   * @return void
   */
  public function buildQuickForm() {
    parent::buildQuickForm();

    $event_type = CRM_Core_OptionGroup::values('event_type', FALSE);

    foreach ($event_type as $eventId => $eventName) {
      // Remove bivak checkbox
      if($eventName == 'Bivak'){
        $this->removeElement("event_type_id[$eventId]");
      }
    }
  }
}


I'm adjusting the build form (in this case i remove one of the event types).  And the only way i'm able to do this is when i name this class CRM_Event_Form_SearchCursus, that's sort of the base of my 'problem'.

For point 2, my example isn't correct actually, since it should be about subclassing an Form which adds a select2 in its buildQuickForm Method. This could indeed done differently, with hook_civicrm_buildForm, but i wan't to keep the original form as well, and only access this on a other URL.

But to adress point 1, perhaps we could introduce this one bit at a time, and start by removing one special case of the CRM_Utils_Api::getEntityName($this); at a time, and add the property where we removed the special case.

Thanks for the reply.

The reasons for my approach are maintainability especially, i want to override the form on 3 different ways, depending on the url, and that makes it more difficult to do with the hooks. The hooks are especially great for making 'smaller' customizations to the form, that's why i'm going for the overriding approach.

I'm interested in the long running overhaul conversations, but as you state, since sitting in Hawaii, isn't exactly an option (sounds great though), the overhaul should best happen in smaller iterations. (Could be great to get consensus over an end-result however, so we can iterate towards it.). Especially for this change, the goal is clear. (Remove CRM_Utils_Api::getEntityName($this)). (And perhaps a further goal to overhaul addSelect even more). I'll try to drive this change further home with incremental changes.

To explain what Tim is alluding to, what we would really like to do is ditch QuickForm and Smarty completely, and build a shiny new flexible form system that does cool stuff like drag-n-drop fields, allowing you to override core forms and tweak them however you wish.
So whenever I make an improvement to CRM_Core_Form like the new addSelect and entityRef methods, it feels like a slightly hollow victory.
Holing ourselves up (a beach sounds nice but I wouldn't want to get sand in my keyboard) for a couple months to develop it as a skunkworks project would be awesome, but might not leave enough people home at the core team to keep the lights on.