/*!
  \page ktexttemplate-generictypes
  \title Generic type and template support

  \section1 Generic type support

  KTextTemplate offers powerful support for using any type or container in a QVariant as part of the Context.
  Qt introspection based on \c Q_PROPERTY is the most convenient way to access properties on QObject derived type or types decorated with the \c Q_GADGET macro.

  However, sometimes it is necessary to use classes which do can't have \c Q_PROPERTY macros (perhaps because they are defined in third-party headers)
  and where it would not be practical to create QObject/Q_GADGET wrappers around all related classes.

  In such cases the metatype can be registered with KTextTemplate and an introspection method can be written.

  \code
    // Non-QObject
    class Person
    {
    public:
      Person() :age(0) {}
      Person(const QString &name, int age)
        : m_name(name), m_age(age)
      {
      }

      QString name() const
      {
        return m_name;
      }

      int age() const
      {
        return m_age;
      }

    private:
      QString m_name;
      int m_age;
    };

    // Make it possible to put Person in a QVariant.
    Q_DECLARE_METATYPE(Person)

    // Read-only introspection of Person object.
    KTEXTTEMPLATE_BEGIN_LOOKUP(Person)
      if ( property == "name" )
        return object.name();
      else if ( property == "age" )
        return object.age();
    KTEXTTEMPLATE_END_LOOKUP

    void someInitializer()
    {
      // Register the Person type with the %KTextTemplate introspection system.
      KTextTemplate::registerMetaType<Person>();
    }

    KTextTemplate::Context getContext()
    {
      KTextTemplate::Context c;
      Person leader("The Leader", 19);

      QList<Person> followers;
      for (int i = 0; i < 3; ++i)
      {
        Person follower("Follower" + QString::number(i), 18);
        people.append(follower);
      }

      c.insert("leader", QVariant::fromValue(leader));
      c.insert("followers", QVariant::fromValue(followers));
      return c;
    }

    QString createOutput()
    {
      Template t = m_engine->newTemplate(
        "<h1>{{ leader.name }}</h1>"
        "<ul>"
        "{% for person in followers %}"
          "<li>{{ person.name }}, {{ person.age }}</li>"
        "{% endfor %}"
        "</ul>"
        );

      Context c = getContext();

      return t->render(&c);
    }
  \endcode

  There are several necessary steps and consequences.
  \list
  \li The type must be registered as a QMetaType with \c Q_DECLARE_METATYPE. Note that this is not needed for QObject derived types.
  \li All containers are supported.
  \li The \c KTEXTTEMPLATE_BEGIN_LOOKU and \c KTEXTTEMPLATE_END_LOOKUP macros help to define the introspection of the type. Between them is the definition of a method with the signature \c {QVariant getProperty(const Type &object, const QString &property.
  \li KTextTemplate::registerMetaType must be called at some point in the program before attempting to use the type in a Context.
  \li The Context is created and used as normal.
  \endlist

  \section1 Generic container support

  KTextTemplate supports most Qt and STL containers by default if they are registered with the QMetaType system.
  Where a container does not have built in support it can easily be added.

  The following containers have built in support:
  \list
  \li QList<T>
  \li QList<T>
  \li QSet<T>
  \li QLinkedList<T>
  \li QStack<T>
  \li QQueue<T>
  \li std::vector<T>
  \li std::deque<T>
  \li std::list<T>
  \li QHash<QString, T>
  \li QHash<qint16, T>
  \li QHash<qint32, T>
  \li QHash<qint64, T>
  \li QHash<quint16, T>
  \li QHash<quint32, T>
  \li QHash<quint64, T>
  \li QMap<QString, T>
  \li QMap<qint16, T>
  \li QMap<qint32, T>
  \li QMap<qint64, T>
  \li QMap<quint16, T>
  \li QMap<quint32, T>
  \li QMap<quint64, T>
  \li std::map<QString, T>
  \li std::map<qint16, T>
  \li std::map<qint32, T>
  \li std::map<qint64, T>
  \li std::map<quint16, T>
  \li std::map<quint32, T>
  \li std::map<quint64, T>
  \endlist

  where T is one of

  \list
  \li bool
  \li qint16
  \li qint32
  \li qint64
  \li quint16
  \li quint32
  \li quint64
  \li float
  \li double
  \li QVariant
  \li QString
  \li QDateTime
  \li A pointer to a type which inherits QObject
  \li Any type registered with KTextTemplate::registerMetaType
  \li Any supported container
  \endlist

  Note that QSet<T> is an exception and will only work with types for which \c qHash(T) is defined. This means that QSet<QVariant>
  is not possible for example.

  Note also that containers of pointers to QObject derived types can be stored in containers, and they do not need to be explicitly
  registered with KTextTemplate. Where the class has sufficient \c {Q_PROPERTY}s defined, the introspection method described above with
  \c KTEXTTEMPLATE_BEGIN_LOOKUP and \c KTEXTTEMPLATE_END_LOOKUP is also not necessary. Note also that any type or container can be used through a \c Q_PROPERTY.

  \code
    class PersonObject : public QObject
    {
      Q_OBJECT
      Q_PROPERTY(QString name READ name)
      Q_PROPERTY(int age READ age)
    public:
      PersonObject(const QString &name, int age, QObject *parent = 0);

      QString name() const;
      int age() const;
    };

    class SportsClub : public QObject
    {
      Q_OBJECT
      Q_PROPERTY(QString name READ name)
      Q_PROPERTY(QString sport READ sport)
      Q_PROPERTY(std::vector<QObject*> members READ members)
    public:
      SportsClub(const QString &name, const QString &sport, QObject *parent = 0);

      QString name() const;
      QString sport() const;
      std::vector<QObject*> members() const;
      void setMembers(std::vector<QObject*> members);
    };

    void someInitializer()
    {
      // QObject* already has built in support. No need to register the types
      // with KTextTemplate::registerMetaType
    }

    KTextTemplate::Context SomeClass::getContext()
    {
      KTextTemplate::Context c;

      QSet<QObject*> clubs;
      {
        auto club = new SportsClub("Smithfield Tennis Club", "Tennis", this);

        std::vector<QObject*> members;
        {
          auto member = new PersonObject("Alice", 21, this);
          members.push_back(member);
        }
        {
          auto member = new PersonObject("Bob", 22, this);
          members.push_back(member);
        }
        club.setMembers(members);
      }

      // ... specify other clubs and members

      c.insert("sportsClubs", QVariant::fromValue(clubs));
      return c;
    }

    QString createOutput()
    {
      auto t = m_engine->newTemplate(
        "{% regroup sportsClubs by sport as groupedSports %}"
        "{% for groupedClub in groupedSports %}"
          "<h1>{{ groupedClub.grouper }}</h1>"
          "{% for club in groupedClub.list %}"
            "<h2>{{ club.name }}</h2>"
            "<ul>"
            "{% for member in club.members %}"
              "<li>{{ member.name, }}, {{ member.age }}"
            "{% endfor %}"
          "</ul>"
          "{% endfor %}"
        "{% endfor %}"
        );

      auto c = getContext();

      return t->render(&c);
    }
  \endcode

  See \l {http://docs.djangoproject.com/en/1.9/ref/templates/builtins/#regroup} {The regroup tag}

  The output would be something like

  \badcode
    <h1>Tennis</h1>
      <h2>Smithfield Tennis Club</h2>
      <ul>
        <li>Alice, 21</li>
        <li>Bob, 22</li>
      </ul>
      <h2>Greenore Lawn Tennis and Fitness Club</h2>
      <ul>
        <li>Charlie, 23</li>
        <li>David, 24</li>
        <li>Elaine, 25</li>
        <li>Frank, 26</li>
      </ul>
    <h1>Basketball</h1>
      <h2>Sandyford Basketball Club</h2>
      <ul>
        <li>Gilian, 27</li>
        <li>Henry, 28</li>
      </ul>
  \endcode

  Of course, it is possible to use containers of pointers to concrete QObject subclasses, such as \c QSet<PersonObject*> and \c std::vector<SportsClub*> too.

  Because any supported container can also be used as a contained type, nested containers such as \c QList<QList<PersonObject*>> are also supported.

  Note that if a type is registered with KTextTemplate::registerMetaType, built in containers of that type do not also need to be registered.
  Third party containers do need to be registered however

  \code
    Q_DECLARE_METATYPE(Person)

    void someInitializer()
    {
      KTextTemplate::registerMetaType<Person>();

      // Now any of the nested containers can be put 
      // in a Context and used in a Template.
    }
  \endcode

  \section1 Third party containers

  To support another, non-built in container it is necessary to use some macros to register it with KTextTemplate.

  For a sequential container, \c Q_DECLARE_SEQUENTIAL_CONTAINER_METATYPE,
  and \c Q_DECLARE_ASSOCIATIVE_CONTAINER_METATYPE are needed.

  \code
    #include <boost/circular_buffer>

    // Enable looping over the contents of the container
    Q_DECLARE_SEQUENTIAL_CONTAINER_METATYPE(boost::circular_buffer)

    Q_DECLARE_METATYPE(boost::circular_buffer<Person>)

    void someInitializer()
    {
      KTextTemplate::registerMetaType<Person>();
    }

    KTextTemplate::Context getContext()
    {
      KTextTemplate::Context c;

      boost::circular_buffer<Person> buffer(5);
      // loop
      {
        Person p("Grant", 21);
        b.push_back(p);
      }
      c.insert("people", QVariant::fromValue(buffer));
    }
  \endcode

  For associative containers \c Q_DECLARE_ASSOCIATIVE_CONTAINER_METATYPE is needed.

  \section1 Smart Pointers

  Shared pointer types containing a custom type should be introspected as normal using \c KTEXTTEMPLATE_BEGIN_LOOKUP and \c KTEXTTEMPLATE_END_LOOKUP

  \code
    Q_DECLARE_METATYPE(QSharedPointer<Person>)

    void someInitializer()
    {
      KTextTemplate::registerMetaType<QSharedPointer<Person> >();
    }

    KTEXTTEMPLATE_BEGIN_LOOKUP(QSharedPointer<Person>)
      if (property == "name")
        return object->name();
    KTEXTTEMPLATE_END_LOOKUP
  \endcode

  Note that if only shared pointers to the type is in your introspectable API you only need to define the property access for the
  shared pointer. In the case above, there is no need to use \c Q_DECLARE_METATYPE or \c KTEXTTEMPLATE_BEGIN_LOOKUP with \c Person or \c Person*.

  This is of course true of any smart pointer:

  \code
    Q_DECLARE_METATYPE(boost::shared_ptr<Person>)

    KTEXTTEMPLATE_BEGIN_LOOKUP(boost::shared_ptr<Person>)
      if (property == "name")
        return object->name();
    KTEXTTEMPLATE_END_LOOKUP
  \endcode

  QSharedPointers containing QObject derived types get special treatment.

  QObjects are automatically introspected for their Q_PROPERTYs.

  If you have QSharedPointer<PersonObject> where \c PersonObject is derived from QObject it will be automatically
  introspected just like a QObject* is without requiring the \c KTEXTTEMPLATE_BEGIN_LOOKUP and \c KTEXTTEMPLATE_END_LOOKUP macros,
  the \c Q_DECLARE_METATYPE macro, or registration with the KTextTemplate metatype system. All of the access registration
  is handled by Qt.

  \code
    void getContext()
    {
      KTextTemplate::Context c;
      auto p = QSharedPointer<PersonObject>::create();
      c.insert("person", QVariant::fromValue(p));
      return c;
    }

    QString createOutput()
    {
      // Uses Q_PROPERTYs defined on PersonObject for name and age
      auto t = m_engine->newTemplate( "{{ person.name }}, {{ person.age }}" );

      auto c = getContext();

      return t->render(&c);
    }
  \endcode

  The same technique can be used to support QObject derived types in third party shared pointers, but that requires
  an extra macro, \c Q_DECLARE_SMART_POINTER_METATYPE.

  \code
    Q_DECLARE_SMART_POINTER_METATYPE(boost::shared_ptr)

    void getContext()
    {
      KTextTemplate::Context c;
      boost::shared_ptr<PersonObject> p( new PersonObject );
      c.insert("person", QVariant::fromValue(p));
      return c;
    }
  \endcode

*/