[campsite-dev] plugin API
  • Hi,

    I am not clear about the tempalate sysntax to handle poll plugin. Here some
    ideas/questions.


    A) Print a list of available Polls

    Polls can be assigned to publication|issue|section|article. Those relations
    are stored in each table for each type, like:
    +-------------------+------------------+------+-----+---------+-------+
    | Field | Type | Null | Key | Default | Extra |
    +-------------------+------------------+------+-----+---------+-------+
    | fk_poll_id | int(10) unsigned | NO | PRI | 0 | |
    | fk_language_id | int(10) unsigned | NO | PRI | 0 | |
    | fk_publication_id | int(10) unsigned | NO | PRI | 0 | |
    +-------------------+------------------+------+-----+---------+-------+


    I see 2 possibilities to handle this on creating poll lists:

    1. The type of assignent is given as constraint:
    {{ local }}
    {{ set_publication id=1 }) /* set the publication */
    {{ list_polls constraints="assigned to publication"}} /* only publication
    matters '/
    {{ /local }}
    This would need an own contraint parser, or the current one must allow
    overloading some of it's properties/methods.


    2. Assigments could also be handled by setting the enviroment this way:
    {{ local }}
    {{ set_publication id=1 }) /* set the publication */
    {{ unset_issue }} /* other parameters off */
    {{ unset_section }}
    {{ unset_article}}
    {{ list_polls }} /* only list polls assigned to publication
    id 1 */
    {{ /local }}



    B) Print a single Poll

    1. Also I am not clear how to print a single poll, e.g. this one currently
    assigned to the current publication.
    At first thought I would suggest to have a special property "plugins" on
    each campsite object. Like:
    {{ $publication->plugins->poll->name }} would print the name of poll
    assigned to current publication.
    The campsite (Meta)Classes could automatically load wanted plugin using
    __get().

    What you think about this?


    Thanks,
    Sebastian
  • 3 Comments sorted by
  • Hi Sebastian,

    I think you should use a syntax like:

    {{ list_polls item="...." }}
    {{ /list_polls }}

    where item may have one of the following values:
    - publication
    - language
    - issue
    - section
    - article

    If one of the needed parameters was not set (e.g. section was not set for a
    section poll) it should generate an error (see
    CampTemplate::trigger_error()).

    Regarding the poll properties there are two ways we can implement this:
    1. through the campsite context object: $campsite->plugins->poll->property
    2. simpler, just register the poll object in smarty: $poll->property

    Hope this helps,
    Mugur

    On 9/10/07, Sebastian Goebel wrote:
    >
    > Hi,
    >
    > I am not clear about the tempalate sysntax to handle poll plugin. Here
    > some ideas/questions.
    >
    >
    > *A) Print a list of available Polls*
    >
    > Polls can be assigned to publication|issue|section|article. Those
    > relations are stored in each table for each type, like:
    > +-------------------+------------------+------+-----+---------+-------+
    > | Field | Type | Null | Key | Default | Extra |
    > +-------------------+------------------+------+-----+---------+-------+
    > | fk_poll_id | int(10) unsigned | NO | PRI | 0 | |
    > | fk_language_id | int(10) unsigned | NO | PRI | 0 | |
    > | fk_publication_id | int(10) unsigned | NO | PRI | 0 | |
    > +-------------------+------------------+------+-----+---------+-------+
    >
    >
    > I see 2 possibilities to handle this on creating poll lists:
    >
    > 1. The type of assignent is given as constraint:
    > {{ local }}
    > {{ set_publication id=1 }) /* set the publication */
    > {{ list_polls constraints="assigned to publication"}} /* only
    > publication matters '/
    > {{ /local }}
    > This would need an own contraint parser, or the current one must allow
    > overloading some of it's properties/methods.
    >
    >
    > 2. Assigments could also be handled by setting the enviroment this way:
    > {{ local }}
    > {{ set_publication id=1 }) /* set the publication */
    > {{ unset_issue }} /* other parameters off */
    > {{ unset_section }}
    > {{ unset_article}}
    > {{ list_polls }} /* only list polls assigned to publication
    > id 1 */
    > {{ /local }}
    >
    >
    >
    > *B) Print a single Poll*
    >
    > 1. Also I am not clear how to print a single poll, e.g. this one currently
    > assigned to the current publication.
    > At first thought I would suggest to have a special property "plugins" on
    > each campsite object. Like:
    > {{ $publication->plugins->poll->name }} would print the name of poll
    > assigned to current publication.
    > The campsite (Meta)Classes could automatically load wanted plugin using
    > __get().
    >
    > What you think about this?
    >
    >
    > Thanks,
    > Sebastian
    >
  • Hi,

    I wrote some plugin API code, and admin interface page to manage plugins.

    The ticket is here:

    http://code.campware.org/projects/campsite/ticket/2579#preview



    The code i already implemented you can find here:

    http://code.campware.org/projects/campsite/changeset/8101



    And see it in work here:

    http://interview.edge.campware.org

    (I had to overwrite user tables, so just admin with known password exists)



    General changes:

    Each plugin have an %pluginname.info.php file in it's base folder, which descripes a list of items:

    Hi Sebastian,

    Before committing your work to the trunk please update your local repository
    because I made some changes since then.

    Also, I have some requests for you:

    - please rename static methods to start with big letters
    - update the database upgrade scripts to add the plugin_manager rights
    for the existing admin users (let me know if you need help)
    - custom value 'current' makes no sense for MetaInteger; please handle it
    outside the MetaInteger class
    - in ComparisonOperation::getRightOperand() read the custom date/time
    values from the system (PHP functions), not from the database
    - make CampContext::registerObjectType() and
    CampContext::registerListObject() methods private and call them from the
    CampContext constructor for each plugin

    Regarding the plugin install please implement your proposal.

    Let me know if you need help with these changes. Also, please let me know
    how soon can you implement them.

    Thank you for your good work,
    Mugur

    On Mon, Jun 16, 2008 at 7:19 PM, Sebastian Goebel
    wrote:

    > Hi,
    >
    > I wrote some plugin API code, and admin interface page to manage plugins.
    >
    > The ticket is here:
    >
    > http://code.campware.org/projects/campsite/ticket/2579#preview
    >
    >
    >
    > The code i already implemented you can find here:
    >
    > http://code.campware.org/projects/campsite/changeset/8101
    >
    >
    >
    > And see it in work here:
    >
    > http://interview.edge.campware.org
    >
    > (I had to overwrite user tables, so just admin with known passwordexists)
    >
    >
    >
    >
    > *General changes:*
    >
    > Each plugin have an %pluginname.info.php file in it's base folder, which
    > descripes a list of items:
    >
    >
    > http://code.campware.org/projects/campsite/browser/branches/CAMPSITE_3_0_BRANCH/plugins/interview/campsite/implementation/site/plugins/interview/interview.info.php?rev=8101
    >
    >
    > * name, version, label, description
    >
    > * menu: extentions to the admin menu
    >
    > * userDefaultConfig: userright names for liveuser
    >
    > * permissions: for the admin users
    >
    > * no_menu_scripts: those admin pages which don't need the menu (like in
    > admin.php, may should replaced by using an post/get parameter)
    >
    > * template_engine: to init the template engine
    >
    > Reading those files, the CampPlugin class will handle plugins in an
    > variable way.
    >
    > Let me know what you think, and what you miss.
    >
    > Next point: an uploder for plugins on the plugin managment page. My
    > propose:
    >
    > * using an package format to upload just one file, which will extracted to
    > an tree
    >
    > * adding 'install' section to the info.php file, which will do the install
    > process: coping files, adding tables etc.
    >