Automatic wrapper as standard

gomedia · 2010-06-28 04:47:00

All I want is a reliable and readable wrap tag mechanism!

Code using standard TXP tags:

<txp:variable name="output" value='<txp:maybe_some_output />' />
<txp:if_variable name="output" value="">
<txp:else />
<p><txp:variable name="output" /></p>
</txp:if_variable>

Code with txp:wrap tag:

<txp:wrap wraptag="p">
<txp:maybe_some_output />
</txp:wrap>

txp:wrap does what it says on the tin – and the source code makes it instantly obvious what is going on. Of course, I would like to see the full monty functionality of chh_if_data but the argument against it of the extra parsing steps doesn’t apply to adi_wrap. Obviously I have to call the parser in the plugin but this wouldn’t be the case in the core.

It is such a trivial piece of programming that provides an elegant solution to a common requirement that I still don’t understand how wraptag=" attributes are so readily accepted into the core but a wrapping tag isn’t.

This mantra of keeping the TXP core “lean & mean”, whilst admirable, sometimes seems to be a bit inflexible. Textpattern exists to create websites and it should provide the tools to do this efficiently.

ruud · 2010-06-28 16:58:37

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.

That’s an interesting idea.

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

I agree. All TXP core tags could be converted to core plugins. And with plugins you get plugin help, so the documentation for the core tags would be built-into TXP and set an example for other plugin authors.

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.

Perhaps there’s room for improvement there.

I don’t pretend to know how many sites use the wrap plugin, but if it were high (say > 50%), then we would be making a lot of people’s lives easier by including it.

It would be interesting to know which percentage of tags currently in core are used on average by users. I’d use that as a threshold for adding new tags.

gomedia wrote:

Obviously I have to call the parser in the plugin but this wouldn’t be the case in the core.

Why not? The enclosed tags still have to be parsed. In or outside core, that doesn’t matter.

JanDW · 2010-06-28 18:07:34

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.

+1 I’ve been hoping for something like this. I love TXP for keeping the core lean and clean, but I just about work up a sweat installing all the plugins I need to develop my sites. Core plugins could make life sweeter! What if “core plugins” could easily be installed via a tab in the admin interface, where the available plugins get listed, and when you select them, they download and install. Of course you can also see if there are available updates and install them with one click.

It would be great if really valuable txp plugins (MLP, ecommerce…)could make it in there too, so that they’re protected against ‘extinction’).

It would be nice if it were possible to establish some hard metrics around such things as percentage of sites using particular tags/plugins, and what percentage is high enough to warrant inclusion in core. I don’t pretend to know how many sites use the wrap plugin, but if it were high (say > 50%), then we would be making a lot of people’s lives easier by including it.

people might not use it because they don’t know it, and it needs promoting a bit. The people who are the most vocal on this forum, are, in response to Ruud, probably also the ones who work with txp the most…

Last edited by JanDW (2010-06-28 18:13:12)

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

#13 2010-06-28 04:47:00

Re: Automatic wrapper as standard

#14 2010-06-28 16:58:37

Re: Automatic wrapper as standard

#15 2010-06-28 18:07:34

Re: Automatic wrapper as standard

#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