Extra args for template tag functions

Logoleptic · 2008-01-01 23:20:01

My most recently-released plugin uses two template tags: a tag for generating output and a conditional container tag. The conditional tag calls the output tag’s function to get the information it needs for comparisons.

I’d like to make some enhancements to the conditional tag while retaining the code reuse that I’ve got going in the current version. Doing this will require the output function to be aware of whether or not it was called by the conditional function. Using debug_backtrace for something so simple seems like massive overkill, so I’m thinking of using an optional boolean argument instead. Can template tag functions take other arguments besides $atts and $thing?

Mary · 2008-01-01 23:38:52

Not built-in ones, no.

ruud · 2008-01-01 23:42:33

I’d add it as an undocumented attribute in $atts. Or put the output tag’s code in a new function that can accept a third argument.

Logoleptic · 2008-01-02 00:51:22

Mary wrote

Not built-in ones, no.

If you mean the functions built into the core, then I might not have been clear enough. My aam_if_scf function calls aam_split_custom_field, which is the function I’m looking to add an argument to.

ruud wrote:

I’d add it as an undocumented attribute in $atts.

I considered this, but there are a couple of reasons I’d rather not go that route:

When this attribute/argument is set to true, the output function will return a raw array instead of anything suitable for rendering on a web page. I’d rather not expose that option to the user, even in an undocumented way.
Mixing up user-specified options with internal context tracking rubs me the wrong way. The aforementioned issue of the returned data type is part of that, but it also makes the function’s behavior less immediately obvious to me when I return to this code several weeks or months from now.

So, just to clarify, this won’t work?

function aam_split_custom_field( $atts, is_conditional = false )
{
    // code goes here
}

Or put the output tag’s code in a new function that can accept a third argument.

So this would be a third function, called by both the conditional and output functions? That’s more revision than I’d hoped to do, but I can see how it would work (and, ultimately, be cleaner than the alternatives).

That brings me to another question that’s bothered me for a while now: what keeps a user from trying to use any plugin function as a tag? Will it only work if the function has an argument called $atts, or is any function in a public-side plugin (type 0) fair game?

Mary · 2008-01-02 01:05:54

My aam_if_scf function calls aam_split_custom_field, which is the function I’m looking to add an argument to.

So, just to clarify, this won’t work?

Nope, you can do that, but I would do:

function aam_split_custom_field($atts, $thing = null, $is_conditional = false)

That will ensure your users won’t try and use that in a way you don’t want (just pretend like $thing isn’t there).

That brings me to another question that’s bothered me for a while now: what keeps a user from trying to use any plugin function as a tag? Will it only work if the function has an argument called $atts, or is any function in a public-side plugin (type 0) fair game?

Technically, any could be, which has it’s pros and cons. This is something I have pondered on before. One possible solution would be to move towards having all tag function be prefixed with tag_ or something, and have the tag parser only allow calls to those functions. I think we could only do something like that in crockery, since it means renaming a lot of functions, both built-in and plugins.

Logoleptic · 2008-01-02 01:31:39

Mary wrote:

Nope, you can do that, but I would do:

[code]

That will ensure your users won’t try and use that in a way you don’t want (just pretend like $thing isn’t there).

Doh! Thanks for the reminder

Technically, any could be, which has it’s pros and cons. This is something I have pondered on before. One possible solution would be to move towards having all tag function be prefixed with tag_ or something, and have the tag parser only allow calls to those functions. I think we could only do something like that in crockery, since it means renaming a lot of functions, both built-in and plugins.

That would also make for some pretty long function names, if the current practice of author-based prefixes is maintained. I had an idea about this some time ago, but I don’t know how practical it is. Since PHP 4 is dead as of yesterday, Txp 4.1 (5?) could justifiably be made a PHP 5 application. Each plugin could then consist of an author-prefixed class, with public methods that represent tags and private methods for internal use only. How possible is something like that?

Mary · 2008-01-02 01:42:40

Classes are another possibility, yes. I really couldn’t say how likely a PHP5-only Txp would be at this point. While I personally like the idea, lots of folks are still on PHP4, don’t even have default mofules installed.

But, we could do a PHP4 friendly version using classes.

We start with a base tag class which a plugin author extends to add their tags.
They could then have a second class which contains all their “private” functions, but without using that PHP5-only restriction.
The parser can only call methods that are children of the base tag class.

Bloke · 2008-01-02 02:07:32

Logoleptic wrote:

Since PHP 4 is dead as of yesterday, Txp 4.1 (5?) could justifiably be made a PHP 5 application.

I too like the class idea and would welcome PHP5; mmmmm, try-catch.

But like Mary said some hosts still use PHP4. For instance, one of the places I work at uses a hoster that’s on MYSQL 4.1.22, PHP 4.4.4 and Apache 1.3.39. Their official excuse is that “PHP5 requires Apache2 which has security and stability issues”. Seriously.

Reading between the lines I suspect they simply can’t be arsed ;-)

Logoleptic · 2008-01-02 02:09:39

My knowledge of PHP 4 OOP techniques is sadly lacking, so I didn’t know if what I was suggesting could be done with backward-compatibility. I like your approach, though; it seems like it would solve the problems without introducing any major new ones.

Logoleptic · 2008-01-02 02:11:45

Bloke wrote:

I too like the class idea and would welcome PHP5; mmmmm, try-catch.

Yeah, there’s that too. :-)

But like Mary said some hosts still use PHP4. For instance, one of the places I work at uses a hoster that’s on MYSQL 4.1.22, PHP 4.4.4 and Apache 1.3.39. Their official excuse is that “PHP5 requires Apache2 which has security and stability issues”. Seriously.

Reading between the lines I suspect they simply can’t be arsed ;-)

These people should be beaten. Beaten, I say!

Mary · 2008-01-02 02:32:18

Of course, you can use classes to get around this right now: put all your private functions inside a class. That’ll make them methods and invisible to the current parser.

Logoleptic · 2008-01-02 02:49:55

Mary wrote:

Of course, you can use classes to get around this right now: put all your private functions inside a class. That’ll make them methods and invisible to the current parser.

Good point. It’d be nice to see it made “official,” but that’s a nice work-around for now.

Textpattern CMS

Textpattern CMS support forum

#1 2008-01-01 23:20:01

Extra args for template tag functions

#2 2008-01-01 23:38:52

Re: Extra args for template tag functions

#3 2008-01-01 23:42:33

Re: Extra args for template tag functions

#4 2008-01-02 00:51:22

Re: Extra args for template tag functions

#5 2008-01-02 01:05:54

Re: Extra args for template tag functions

#6 2008-01-02 01:31:39

Re: Extra args for template tag functions

#7 2008-01-02 01:42:40

Re: Extra args for template tag functions

#8 2008-01-02 02:07:32

Re: Extra args for template tag functions

#9 2008-01-02 02:09:39

Re: Extra args for template tag functions

#10 2008-01-02 02:11:45

Re: Extra args for template tag functions

#11 2008-01-02 02:32:18

Re: Extra args for template tag functions

#12 2008-01-02 02:49:55

Re: Extra args for template tag functions

Board footer