[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
>
>