Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#1 2010-06-26 00:33:48
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Automatic wrapper as standard
I would like to propose that the functionality of adi_wrap be integrated into TXP core.
Just as the wraptag attribute has been added to many standard TXP tags, I believe that this functionality should be available for groups of tags as well.
I know I could use chh_if_data or txp:if_variable or smd_if but it just seems a bit arduous to force users to use if-then-else logic just to apply a wraptag.
In the specific scenario where a wrap tag is required, providing a simple TXP tag to do this automatically would make TXP source code more readable & quicker to write.
Offline
Re: Automatic wrapper as standard
Adi,
I would agree with that. <txp:wrap /> seems like a nice addition. :)
Although I’m still on the team that thinks the chh_if_data functionality should be core – for the shear simplicity and number of scenarios it solves.
Can we get both? </dreaming>
:)
—
T
Last edited by renobird (2010-06-26 01:27:22)
Offline
#3 2010-06-26 02:04:15
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: Automatic wrapper as standard
renobird wrote:
Although I’m still on the team that thinks the chh_if_data functionality should be core – for the shear simplicity and number of scenarios it solves.
“If you want a puppy for Christmas, start by asking for a horse” – that didn’t work, so I thought I’d try asking for a goldfish instead.
Offline
Re: Automatic wrapper as standard
gomedia wrote:
“If you want a puppy for Christmas, start by asking for a horse” – that didn’t work, so I thought I’d try asking for a goldfish instead.
Forgot all about that discussion. Yeah – I guess I already made my case there.
Stef/Robert – any chance you want to give us an early Christmas present? wink
A puppy <txp:if_data /> and a goldfish <txp:wrap /> would be great!
I promise to walk and feed the puppy. :P
—
Reno
Offline
Re: Automatic wrapper as standard
…actually – could you cover everything by giving <txp:if_data /> a wraptag attribute?
<txp:if_data wraptag="p" />
Last edited by renobird (2010-06-26 18:24:17)
Offline
Re: Automatic wrapper as standard
adi_wrap doesn’t duplicate any code. It doesn’t benefit from being in TXP core. And if it were in TXP core, shouldn’t then the wraptag attributes be removed from all tags?
Offline
Re: Automatic wrapper as standard
ruud wrote:
It doesn’t benefit from being in TXP core.
I think the more relevant question is whether the majority of the TXP user base would benefit from adding the tag to core – not whether the tag itself benefits.
ruud wrote:
And if it were in TXP core, shouldn’t then the wraptag attributes be removed from all tags?
I would actually approve of this change – if it weren’t for the massive backward compatibility problems it would likely cause.
Offline
Re: Automatic wrapper as standard
ruud wrote:
And if it were in TXP core, shouldn’t then the wraptag attributes be removed from all tags?
artagesw wrote:
I would actually approve of this change – if it weren’t for the massive backward compatibility problems it would likely cause.
I much prefer a wraptag attribute over a wrapping txp tag to add an HTML wraptag.
Speaking in code, I prefer
<txp:article wraptag="ul" />Over this unnecessary & ugly bloatedness:
<txp:wrap wraptag="ul">
<txp:article />
</txp:wrap>The wraptag attribute is, imho, a very helpful attribute to avoid empty/invalid markup (if, instead of being the value for wraptag attribute, the HTML tag would be hardcoded in the form/template), and wouldn’t like to see it removed in favor of an hypothetical txp:wrap tag.
On the other hand, I think that a <txp:wrap /> and wraptag="" attribute, although both provide similar/overlapping functionality, they aren’t exactly the same.
As the way it was proposed by Adi, a <txp:wrap /> tag could wrap a bunch of TXP tags, and only render the wrapping tag if any of the contained tags returns something.
Anyway, imo too, current adi_wrap implementation (which Adi suggests to make it to the core) lacks some features which wouldn’t make it a useful tool.
Particularly, Adi stated that “unlike chh_if_data, adi_wrap takes notice of static HTML within, so really only has a use when the contained code consists of only TXP or plugin tags”, which makes it a rather limited plugin.
Finally, I liked the <txp:if_data wraptag="ul"> idea proposed by renobird. Best of every world :) (particularly, if it also fixes some chh_if_data quirkiness, which, in my experience, some times returned “false positives”).
Last edited by maniqui (2010-06-26 19:30:27)
Offline
#9 2010-06-26 23:36:45
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: Automatic wrapper as standard
ruud wrote:
adi_wrap doesn’t duplicate any code. It doesn’t benefit from being in TXP core. And if it were in TXP core, shouldn’t then the wraptag attributes be removed from all tags?
The whole point of adi_wrap is to provide the wraptag attribute functionality to groups of tags. It would complement the wraptag attribute not replace it.
maniqui wrote:
The wraptag attribute is, imho, a very helpful attribute to avoid empty/invalid markup.
And adi_wrap is designed to address this same scenario for a code block. Just to be clear, let’s say you want a <div> around two lists of articles but you don’t know if either list will generate anything:
<txp:wrap wraptag="div">
<txp:article />
<txp:article />
</txp:wrap>If no articles are generated from either <txp:article/> tag then no <div> is output. Whereas, if you use:
<div>
<txp:article />
<txp:article />
</div>then the wrapping tag is always generated & there is a chance that an empty <div></div> will be output.
The only time you’d consider using <txp:adi_wrap> / <txp:wrap> around a single tag is if the enclosed tag didn’t have its own wraptag attribute.
Web pages are built with wrapping tags & if there was sufficient justification to provide wraptag attributes as standard, is there not the same justification to provide this reliable functionality to groups of tags? It seems ludicrous that we have to resort to if-then-else coding just to create a page that doesn’t have empty tags.
The ideal would be <txp:if_data>, but if not, then a simple <txp:wrap> would be a great improvement.
Offline
Re: Automatic wrapper as standard
maniqui wrote:
Finally, I liked the
<txp:if_data wraptag="ul">idea proposed by renobird. Best of every world :)
What about full wrap syntax? <txp:if_data wraptag="ul" class="someclass" id="someid">
Is it needed for what? It’s very poor and limited only wrap tag.
I like more powerful chh_if_data, but it have some bug and limitations too. :(
I want some this:
<txp:if_data> <div id="idd">Static text <txp:if_data_ignore> <h2><txp:category name="cat1" title="1" /></h2> </txp:if_data_ignore> <div class="qq"> <txp:article wraptag="ul" break="li" category="cat1"> ...contained statements... </txp:article> </div> <txp:if_data_ignore> Articles in <b><txp:category name="cat1" title="1" /></b> </txp:if_data_ignore> </div> <txp:else /> Not articles in <txp:category name="cat1" title="1" /> </txp:if_data>
Last edited by makss (2010-06-26 23:56:50)
aks_cron : Cron inside Textpattern | aks_article : extended article_custom tag
aks_cache : cache for TxP | aks_dragdrop : Drag&Drop categories (article, link, image, file)
Offline
Re: Automatic wrapper as standard
artagesw wrote:
I think the more relevant question is whether the majority of the TXP user base would benefit from adding the tag to core – not whether the tag itself benefits.
Including the plugin in TXP core, doesn’t reduce the amount of PHP code needed for this functionality, so the plugin doesn’t benefit from it being included in TXP core, but let’s look at the users…
Built into TXP core:
+ people who need it don’t have to install the plugin.
Outside of TXP core, in a plugin:
+ TXP core itself can stay small for people that don’t need the functionality.
+ The plugin can be developed independently from TXP core, so it’s possible to update it outside of the TXP release schedule.
When looking for a majority, one tends to find the vocal minority. It’s easier to find the people who’d like to have it included or at least don’t object to it, than it is to find people who will argue against inclusion.
I’m not saying the plugin isn’t useful (in case someone thought I was), just that the strength of TXP is it’s extensibility through the use of plugins. Having a tag in a plugin doesn’t make it a second class citizen, so why add them to TXP core if there’s no technical reason to do so?
Offline
Re: Automatic wrapper as standard
ruud wrote:
I’m not saying the plugin isn’t useful (in case someone thought I was), just that the strength of TXP is it’s extensibility through the use of plugins. Having a tag in a plugin doesn’t make it a second class citizen, so why add them to TXP core if there’s no technical reason to do so?
I would venture to say that there are many features in core that are not there for technical reasons. I agree with you regarding the TXP philosophy of keeping the core lean and mean. I also feel that ultimately, there are times when compromise makes sense.
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.
I think you somewhat understate the positives of having a widely used feature in core. Many users create and manage multiple sites with a whole bunch of plugins. 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. Plugins also create the potential for problems when upgrading core.
One compromise approach might be to classify plugins into two groups: core and contributed.
Contributed plugins are what you have today: created, distributed and maintained by their authors. Contributed plugins could one day grow up to be core plugins, if that makes sense. For example, if a widely used plugin becomes orphaned, it might become a candidate to become a core plugin.
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. This neatly addresses both your points in favor of keeping features out of core.
Offline