Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Pages: 1
Tag-level events
Continuing from here.
Walker wrote:
I created something on the github fork I pulled from the unofficial mirror of the textpattern dev4.0 repo.
Read about it here: http://signalfade.com/487/new-textpattern-callback-event
Tag-level events are an interesting area which we’ve been scratching on the surface lately.
Like Manfre’s comment on your site implies, I’d also like to have a more orthogonal general-purpose method of conveying the “payload” from the individual core tag handler to the chain of plugins. Not all plugin results are created as strings, for instance. Some tags might require the concatenation of the plugin chain’s results, while others need some boolean yes/no decision collected from the associated plugins.
Image a not-yet-existing tag <txp:if_frontpage />. The core cannot determine exactly if the current presentation state is the “real” frontpage at all, despite an absence of $s, $q, $c, ($pg or $pg==1) etc pp because of plugins which might also modify the frontpage presentation depending on whatever. This boils down to the need for a communication channel between the core and plugins on a tag level, most desirably by using events and callbacks. But in this case, any plugin in the chain should have the opportunity to cast an instant veto and short-circuit the whole action.
Possible processes are:
- core tag handler invokes the plugin chain to acquire a surrogate result for its default output before it generates its own output.
- core tag handler invokes the plugin chain to acquire a boolean “vote”, with both possible cases: first vote counts / any vote counts, before it generates its own output.
- core tag handler pipes its own output into the plugin chain to acquire a (modified) output, and subsequently prints it onto the page.
- core tag hander sends a tag level event as a notification, plugins aren’t meant to affect the output.
Additional prerequisite: I’d love to keep this on a simple level – no 20-page RFC;-)
During a private conversation regarding that is topic, Ruud expressed his concerns that the potential outcome of tag level events is unpredictable as plugins will introduce random side effects, and that this concept would just work in a controlled environment but not on a platform like Textpattern with several third-party contributors.
He also suggests to use solutions which rely on conditional tags and other well-established methods instead of adding a channel like that method sketched above.
Last edited by wet (2008-12-12 11:06:50)
Offline
Re: Tag-level events
You forget to mention all the objections I raised to tag level events privately…
Offline
Re: Tag-level events
I added a part covering your concern.
Offline
Re: Tag-level events
I think the conditional tags are a possible option, but that the channel could work and would certainly be much more convenient for most plugin developers.
Also, as with any current plugins, it would really be up to each plugin developer to write their plugin in a such a manner that it would function correctly and work within the pre-defined system. I know that allowing the plugin developers to access and modify core tag output can open a can of worms compared to merely generating their own tags. I think, though, that we will see many good things coming out of such a feature.
Offline
Re: Tag-level events
I’m on the fence for a change :-)
I can see what ruud means about predictability. If plugin (a) modifies the payload and plugin (b) expects something to be in said payload that is now not present after plugin (a)’s meddling, things might get very tricky to debug. Plugin load order might help get a handle on things, but it feels icky as a debugging tool.
I know what we’re talking about here is client-side tags but this does (kind of) touch on the Admin Skins system I put together. I’ve discussed with wet and others how to de-yuckify the process. Currently a hunk of the PHP code is copied into someone’s skin directory (if they wish to override the default behaviour — otherwise, the default code is always used). They can thus alter the layout of the admin-side to a degree. They may also write functions in this file called skin_tabber() or skin_areatab() to override the default tabber() and areatab() functions. The existing functions simply look out for the existence of said functions and use the custom ones instead of their own output.
That is plain horrible in implementation terms but sheer wonderfulness in functionality. Somewhere it would be cool to have some kind of event triggered on each of those functions that effectively goes “anyone need me? anyone? no, ok, I’ll use my own code then”. But if the reply comes back “hang on, yup, I’m interested” then control is passed to that callback. Potentially more than one I suppose.
Extrapolating this to tags, I dunno, it could get very messy. Most of the time you only want to add or inject new stuff into the payload but sometimes you want to remove things (ied_hide_in_admin or sed_section_fields spring to mind, again on the admin side). If you’re only adding stuff then it works like a conventional callback, right? Something is called and — short of an exit() — control will return to TXP once the plugin is done.
Thinking out loud, what if there was some signalling mechanism to determine the type or severity of request? Like, a plugin could ask for a function-level callback but specify it is only going to add stuff to the payload. Thus TXP knows that everything afterwards is OK and the default function can run as normal. But if a plugin indicates “I wanna potentially replace you with something entirely different” then the original function backs off and doesn’t run.
Under the latter circumstance of course, all bets are off for anything that comes afterwards in the chain. And it might kind of open the floodgates for completely weird behaviour: similar to the reason I hate C++ with a passion, because someone can overload the + operator and make it perform subtraction if they want to. Madness!
So I’d be cautious of doing anything like this, but clearly there are advantages. Perhaps it’ll work if somewhere along the chain — if a plugin has indicated it intends to alter anything — the output is marked as “dirty” so other plugins may later bail out more gracefully.
Last edited by Bloke (2008-12-18 14:55:57)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Pages: 1