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().
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
>
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.
>