Automatic wrapper as standard

Bloke · 2010-06-28 18:16:09

artagesw wrote:

Core plugins are maintained and distributed as part of the TXP core release, perhaps even installed by default (but not enabled?). These plugins are maintained by core devs. They can easily be disabled (or uninstalled) by users who don’t need them, and they can be bug-fixed or enhanced separately from the core code.

Sounds like Crockery Elements to me :-)

I would venture to say that there are many features in core that are not there for technical reasons.

Yes. I’m guilty of adding stuff that’s probably not exactly ‘mainstream’. But I’ve got a little while yet to take it all out if anybody complains…

The extra work of installing, tracking and updating even a single plugin across multiple clients and sites increases the user’s workload in a not insignificant way.

At the moment yes. For the record I’ve already put in place a system on the currently-being-revamped textpattern.org that allows the core to notify users of updated plugins. It will not be in TXP 4.3.0 because I doubt textpattern.org will be done in time (too many other things to do…) but once it’s more thoroughly tested and bulletproofed will likely be in the early stages of the SVN towards TXP 5.

The update notifications and a whole slew of other planned goodness for textpattern.org will hopefully make the repository a) far more useful (in terms of searchability), b) far smoother for plugin authors to maintain their entries, c) far easier for end users to find and update plugins. Once the site is in some sort of usable shape I’ll be posting updates/screenies on the forum and weblog about it all, and inviting comment from heavy plugin users/authors.

ruud wrote

All TXP core tags could be converted to core plugins

Interesting idea… would like to bat this around a bit in future.

Aaaaaanyway, back on topic: adi’s wrapper. I’ve no objection to it if the consensus is that it’s truly a time saver for multiple wrap scenarios. What I don’t particularly relish though is untold confusion because we have individual wraptag attributes (which I personally really like) and a <txp:wrap /> tag. Mind you, it can’t be any more confusing than the masses of comments tags we have… and a load of those aren’t even proper tags!

The wraptag attributes will stay. I feel that chh_if_data, while novel and probably useful, is better as a plugin (and I know that makes me wildly unpopular). I’ve not installed it since TXP 4.0.7 came to market and I do some pretty crazy site mods and convoluted things with the core tags.

The ability to detect if something has arbitrary output is probably always going to require two calls or some clever cacheing of the first call. The good thing about the relevant TXP conditionals is the fact that, because they have one specific role, they can query the various global variables directly on the page and alleviate a DB call. chh_if_data cannot do that because of its general purpose nature. The txp:variable approach can’t do that either, and I suspect adi_wrap is the same (I’ve not looked at the code yet, sorry Adi). I guess it’s, like, 5 lines though, yeah? ;-)

I’d be very happy if we could somehow specify a not attribute to the if_variable tag so we wouldn’t have to keep having an empty <txp:else/> dangling with nothing inside it. That in itself would mean less typing to achieve something useful. But can I make it work without giving myself brain freeze? No…

There is, however, something elegant and TXPish about a tag that you can just wrap around a bunch of other tags instead of having to explain to people that they need to perform the action first, store the value and then detect if it contained anything before outputting it.

I’m sooo torn.

Last edited by Bloke (2010-06-28 18:18:49)

gomedia · 2010-06-28 22:12:27

Stef, welcome to the melee!

Bloke wrote:

Aaaaaanyway, back on topic: adi’s wrapper. I’ve no objection to it if the consensus is that it’s truly a time saver for multiple wrap scenarios. What I don’t particularly relish though is untold confusion because we have individual wraptag attributes (which I personally really like) and a <txp:wrap /> tag.

I can’t imagine that there’d be any confusion – wraptag="" is for single tags, <txp:wrap> for groups of tags.

The ability to detect if something has arbitrary output is probably always going to require two calls or some clever cacheing of the first call. The good thing about the relevant TXP conditionals is the fact that, because they have one specific role, they can query the various global variables directly on the page and alleviate a DB call. chh_if_data cannot do that because of its general purpose nature. The txp:variable approach can’t do that either, and I suspect adi_wrap is the same (I’ve not looked at the code yet, sorry Adi). I guess it’s, like, 5 lines though, yeah? ;-)

txp:if_variable will always be essential but it doesn’t help with source code readability when you’re using it to test if any markup has been generated. And 3 of the lines of adi_wrap are probably plugin admin!

I’d be very happy if we could somehow specify a not attribute to the if_variable tag so we wouldn’t have to keep having an empty <txp:else/> dangling with nothing inside it. That in itself would mean less typing to achieve something useful. But can I make it work without giving myself brain freeze? No…

Me too. I’ve argued this before (& got nowhere) but txp:if_variable_not or txp:if_variable not="1" or txp:wot_no_variable would bring a little more sense into the world & take the pressure of keyboards everywhere.

There is, however, something elegant and TXPish about a tag that you can just wrap around a bunch of other tags instead of having to explain to people that they need to perform the action first, store the value and then detect if it contained anything before outputting it.

I’m sooo torn.

… but you’re tempted!

Textpattern CMS

Textpattern CMS support forum

#16 2010-06-28 18:16:09

Re: Automatic wrapper as standard

#17 2010-06-28 22:12:27

Re: Automatic wrapper as standard

Board footer