[geeklog-devel] PLG_itemDisplay?

[Oliver Spiesshofer]

Step1:
So you would check the data in the array and eventually change it and 
assign the template variable again with the updated data?
Step2:
Well the $type is the plugin-id anyhow, so there should not be any 
discussion
Step3:
I see how this could help but I think it is enough if the plugin can 
freely manipulate all template variables before they are displayed.

I would support this approach. Anyone else?

Oliver

Joe Mucchiello wrote:

> There are currently dozens of suggestions regarding this. I'll go with 

> the ones I feel have the path of least resistance:

>

>

> STEP 1: Expand the PLG_templateSetVars function so it is more 

> informative.

>

> function PLG_templateSetVars($templateName, $templateclass, $type= '', 

> $data =Array())

> function plugin_templatesetvars_$plugin($templateName, $templateclass, 

> $type, $data)

>

> This change is the most transparent. The caller of PLG_templateSetVars 

> tells the plugins who he is ($type) and providing a database row 

> associated with the object ($data) if there is one. So existing calls 

> would expand to something like:

>

>    PLG_templateSetVars('featuredstory', $T, 'article', $A);

>    PLG_templateSetVars('header', $header, 'siteHeader');  // leave the 

> array blank on the header, footer, newuserform, and submitstory

>

> Where $A is the result from the DB_fetchArray() for the story.

>

> There are only 10 calls to PLG_templateSetVars in CVS so it shouldn't 

> take long to do this. (I've added the call to the calendar plugin as 

> part of the bounty.)

>

> Line numbers may be off, I haven't refreshed in a week or two:

> public_html\lib-common.php(1151):     PLG_templateSetVars( 'header', 

> $header, 'siteHeader' );

> public_html\lib-common.php(1320):     PLG_templateSetVars( 'footer', 

> $footer, 'siteFooter' );

> public_html\profiles.php(227):             PLG_templateSetVars 

> ('contact', $mail_template, 'email');

> public_html\profiles.php(401):     PLG_templateSetVars ('emailstory', 

> $mail_template, 'email');

> public_html\submit.php(207):         PLG_templateSetVars ('story', 

> $storyform, 'submitform');

> public_html\users.php(692):     PLG_templateSetVars ('registration', 

> $user_templates, 'submitform');

> system\lib-comment.php(799):                 PLG_templateSetVars 

> ('comment', $comment_template, 'submitform');

> system\lib-story.php(497):         PLG_templateSetVars( 

> 'featuredstorytext', $article, 'article', $story );

> system\lib-story.php(503):         PLG_templateSetVars( 

> 'archivestorytext', $article, 'article', $story );

> system\lib-story.php(509):         PLG_templateSetVars( 'storytext', 

> $article, 'article', $story );

>

> Of note here, the PLG_templateSetVars in comments is on the submission 

> form but not on the display. That needs remedy.

>

>

> STEP 2: More than just stories needs to call PLG_itemSaved()

>

> Not much to add here. Understood should be that the $type in 

> PLG_itemSaved($id, $type) needs to be the same a the $type in 

> PLG_templateSetVars for sanity sake.

>

>

> STEP 3: This part isn't necessary but it would certainly help plugin 

> development.

>

> Add an extra variable to any templates expressly for the use of 

> unknown plugins: {extensions}

> Plugins use the append mode of set_var() so they don't overwrite some 

> other plugin's use of the {extension} variable:

>

> function plugin_templatesetvars_$plugin($templateName, $T, $type, $A)

> {

>     if ($type == 'block' AND $A['name'] = 'user_block') {

>         $T->set_var('extensions', extendUserBlock($A), true);

>     }

> }

>

> Some templates might include more than one {extensions} variables. For 

> example, Stories might have an {extend_after} and {extend_buttons} so 

> you could add button where the edit button goes. But that is beyond 

> the scope of this task.

>

>

>

> At 10:56 AM 10/8/2007, Oliver Spiesshofer wrote:

>> I remember now I introduced that function myself but due to the 

>> upcoming discussion it was never used.

>> The reason was that plugins should be able to modify or analyze 

>> information before display if desired.

>> Simply adding a template variable with plugin_templatesetvars_xxx  

>> would require that the plugin is installed together with a template 

>> using the variable, and the actual content of the item cannot be seen 

>> by the plugin then anyhow. It would be great if the function could be 

>> called in the plugin api instead so that the plugin could read the 

>> variables of the template out, modify them and then send them back 

>> for further processing. I guess that would cover most of the items 

>> needed.

>>

>> any thoughts on this?

>>

>> Oliver

>>

>>> >At 06:50 AM 1/9/2007, Dirk Haun wrote:

>>> >Oliver,

>>> >

>>> >>Ok, rewriting the plugin engine was not the original scope of the

>>> >>tagging plugin :), but this can certainly be done.

>>> >>A PLG_itemDisplay('story') could call all plugins and see if they 

>>> have

>>> >>anything to add to the story display.

>>> >

>>> >Could you slow down a bit, please?

>>> >

>>> >Do we even need such an API? We already have something similar in 

>>> the form of

>>> >plugin_templatesetvars_xxx

>>> >

>>> >bye, Dirk

>>

>> _______________________________________________

>> geeklog-devel mailing list

>> geeklog-devel at lists.geeklog.net

>> http://eight.pairlist.net/mailman/listinfo/geeklog-devel

>

> ----

> Joe Mucchiello

> Throwing Dice Games

> http://www.throwingdice.com

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://eight.pairlist.net/mailman/listinfo/geeklog-devel

>

>