Display menuitems in sidebar based on "group title" or "user id"

[marcodings]

2nd time is a charm.. Display menuitems in sidebar based on "group title" or "user id". Extend the definition of meta metadata.xml, if no viewaccess is defined, item is shown. If viewmetadata is specified, current users settings are tested against it and only displayed if the user matches

<?xml version="1.0" encoding="utf-8"
<viewmetadata>
    <foflib>
        <ordering>99</ordering>
        <viewaccess>
            <!-- can have muliple entries for userid or groupname -->
            <userid>42</userid>
            <groupname>ViryaDevelopment</groupname>
        </viewaccess>
    </foflib>
</viewmetadata>

[nikosdion]

OK, this is promising but I need to shape it a bit better. I don't like uncached static methods because they ultimately make testing a pain in the rear. Next week I'm on vacation, but I'll try to get it merged before mid-August :)

[marcodings]

enjoy your vacation..

[nikosdion]

Hm, the more I'm looking at it the more issues with it I find.

Hard-coding user IDs and group names (or even view access levels) is very site-specific and has no place in the metadata.xml file. It makes more sense for such limits to be part of your component.

You can modify the sidebar menu on the fly, e.g. as we're doing in Akeeba Subs (if you ignore the tree structure we're basically telling FOF which views to render in the submenu). In your component's Toolbar you can simply override renderSubmenu, call getMyViews and then filter out the views you don't want. Or do a custom presentation of select views like we do in Akeeba Subs. Or even limit views by user ID, group, view access level etc. This is why Toolbar is overridable.

Furthermore, a few comments regarding coding issues and coding style I spotted:

• The conversion of group names to IDs is not a top level domain, or even a Utils helper. It would belong to the FOF30\Platform\PlatformInterface (declaration) and FOF30\Platform\Joomla\Platform(implementation), then accessed as $this->container->platform->....
• When you have invalid arguments passed to a method it's not a RuntimeException, it's a LogicException. Namely, an InvalidArgumentException. Use the SPL. There's a reason it exists ;)
• Avoid if-elseif blocks. You can write code elegantly without lots of else blocks. There was a fantastic presentation a few JaBs ago called Writing code that lasts by Rafael Dohms. It's fantastic and you should try following these rules. It will save your sanity. Case in point, I rewrite the first if-elseif-else block as

        if (!is_string($groupNames) && !is_array($groupNames))
        {
            throw new InvalidArgumentException('$groupNames should be passed as array or string');
        }

        $groupNamesArr = (array) $groupNames;

        if (is_string($groupNames))
        {
            // Convert a lone string into an array
            $groupNamesArr = empty($groupNames) ? array() : array($groupNames);
        }

• Do not put code after a throw. Execution terminates at throw. PHP does not offer a mechanism for resuming after an exception is thrown (and most developers agree this is a good thing, leading to much less sloppy code)

• You don't need to coalesce WHERE statements to join them by OR as long as all of your WHERE statements are going to be separated by ORs. Example

      $db    = JFactory::getDbo();
      $query = $db->getQuery(true);
      $query
          ->select($db->quoteName('id'))
          ->from($db->quoteName('#__usergroups'));
  
      foreach ($groupNamesArr as $name)
      {
          $query->where($db->qn('title') . ' LIKE ' . $db->q($name), 'OR');
      }

• Don't put documentation inline in a method. Either split that code into a different method (preferred) and use its docblock or submit the documentation in the body of your PR.

Overall I am not going to merge this PR since it's a feature that doesn't belong to the framework.