[geeklog-devel] PLG_itemDisplay?

Joe Mucchiello joe at ThrowingDice.com
Tue Oct 9 01:15:04 EDT 2007 

At 08:58 PM 10/8/2007, Oliver Spiesshofer wrote:
>Step1:
>So you would check the data in the array and eventually change it 
>and assign the template variable again with the updated data?

I suspect, for the most part, the only thing in the array needed is 
the object's primary key: $data['sid'] for articles but some objects 
you might require more: $data['sid'] and $data['type'] for comments. 
Why have the plugin_templatesetvar_$plugin function hit the database 
to get the information when that info is probably already in a 
variable held by the caller to PLG_templateSetVars?

Usually, when you are hooking a template, your output is dependent on 
the specific article/comment/whatever at hand. Currently, you can 
fake this with $T->get_var('sid') IF and only IF that variable is set 
by the code. Adding the variable to the call to PLG_templateSetVars 
means you can't forget to set the variable.

Modifying existing data is one possibility but, as I say in step 3, 
my guess is most uses of PLG_templateSetVars is to add 
controls/output to a screen. The ratings plugin is the perfect 
example of a plugin that adds things to existing objects.

>Step2:
>Well the $type is the plugin-id anyhow, so there should not be any discussion

Yes, I was referring to internal geeklog objects. Is it "article" or 
"story"? In the submit.php file, it is "story". But the call to 
PLG_itemSaved uses "article". That kind of stuff needs to be made consistent.

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

More importantly, do you see where it can hurt? I think have a 
specific variable designed for plugins which can be manipulated by 
the theme makers is important. In professional, you might piggy-back 
your output on one variable. But in another theme it doesn't look 
right because they've changed the placement of that variable relative 
to some other variable. Having an independent variable simplifies the 
theme maker's job. Now, you might argue that {extensions} is not the 
right word to choose. I can't think of anything better but I'm not 
satisfied with {extension} either.

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

More information about the geeklog-devel mailing list