Tagbuilder - missing tags

philwareham · 2014-04-29 11:49:31

Stef and I are currently doing some changes to the tag builder (eventually it’ll hopefully not take up room in the source code editor pages), whilst doing that work I’ve audited what tags can be built with the system. Not all tags are included in tag builder – some of which make total sense because they would be to convoluted to include in the tag builder anyway – others probably could be included and useful. Here is a list of all tags not currently in the tag builder. Any thoughts on this?…

article_id
article_url_title
author_email
comment_anchor
comment_id
comments_count
comments_error
comments_help
custom_field
else
error_message
error_status
expires
file_download_author
file_download_id
hide
if_article_author
if_article_category
if_article_id
if_article_image
if_article_list
if_article_section
if_author
if_comments
if_comments_allowed
if_comments_disallowed
if_comments_error
if_comments_preview
if_custom_field
if_different
if_excerpt
if_expired
if_expires
if_first_article
if_first_category
if_first_section
if_individual_article
if_keywords
if_last_article
if_last_category
if_last_section
if_plugin
if_search
if_search_results
if_status
if_thumbnail
if_variable
image_author
image_date
image_display
image_index
image_info
image_url
images
keywords
link_author
link_id
link_url
meta_author
meta_keywords
modified
page_url
php
rsd
search_result_count
search_term
site_url
text
thumbnail
die
variable
yield

maruchan · 2014-04-30 00:25:32

How would a PHP tag builder work? That could be pretty cool.

Is there a way to know if anybody actually uses the tag builder? Genuinely curious. The output always seemed so unpredictable. I’d rather show TXP-using friends an AJAX front end to a TXP forum search, or a front end to a community snippet repository.

Winstontaneous · 2014-04-30 01:19:50

As a TXP beginner, I find the tag builder very helpful, kind of like training wheels when learning to ride a bike. I was actually wondering earlier today if there were plans to make more tags available, that would be great!

jstubbs · 2014-04-30 04:58:04

Tag builder is helpful from time to time so wouldn’t want to lose it. The list of options on the Page/Form tabs could be more consistent though as in, some options might be used for a Form or a Page, so personally I’d rather see one tag builder that was consistent across all tabs.

jpdupont · 2014-04-30 09:33:34

jstubbs wrote #280497:

Tag builder is helpful from time to time so wouldn’t want to lose it. The list of options on the Page/Form tabs could be more consistent though as in, some options might be used for a Form or a Page, so personally I’d rather see one tag builder that was consistent across all tabs.

+1 One tag builder is one of my favorite feature request.

philwareham · 2014-04-30 10:46:22

We are working on some layout changes and investigating a better way to house it on pages/forms pages so it doesn’t take up loads of screen estate. Improvements could be made to the functionality as well, which is why I’ve listed all the tags that the system doesn’t currently build.

Bloke · 2014-04-30 10:50:04

As Phil says, a bunch of the tags aren’t much use to model: I’m primarily thinking of else and the conditional tags here. Most of the other ones are doable and have probably been omitted simply because we forgot to add them when the tags were introduced.

Some of the ones that don’t take attributes, such as yield — and even body and site_name which are currently available in the builder — are of questionable value. My view would be the builder is only a tool for tags that take attributes. But maybe that’s too simplistic and the non-attribute tags are useful here? Anyone?

The other spanner is when tags can either be singles or containers. Can we cater for such use cases, or do we always assume they are singles?

Either way, I’ve started refactoring the code a little to try and reduce repetition and make it easier to update. During the process I began wondering if we could leverage the new tag registry better. The tags are all there, so if we could somehow interrogate each tag in the registry (similar to using Reflection) — or at worst case be able to define the attributes and types each tag takes in the registry — then we could automatically generate the tag builder functionality instead of having to manually keep it in sync with tag developments.

That could also open up the possibility of having plugin tags available in the builder, which could be handy. Especially with tags like smd_calendar :-)

Further to this, if we’re doing it properly. I’d like to see the following in the builder when you select a tag:

A brief tag overview description (pulled form the documentation somewhere).
A link to the full tag documentation on the wiki (or its local help file if we go that route instead).
A link to the individual tag attribute description (or local equivalent if we have that available) so people who are presented with a list of attributes can click ‘i’ nearby an attribute name to find out what it actually means. Again, if we built a suitable help API as part of the tag registration process, plugins coud register help intent and offer their own attribute descriptions if they differ from (or enhance) the built-in attributes.

Overall, it’s an interesting idea, but whether it’s practical I don’t know.

philwareham · 2014-04-30 11:15:44

All the core tag documentation is currently being rewritten and put on GitHub – primarily for the new documentation website, but obviously there is the option for it to be bundled into the core too. That was one of the driving forces behind dumping the wiki – reusable content.

Gocom · 2014-04-30 19:08:20

Bloke wrote #280504:

During the process I began wondering if we could leverage the new tag registry better. The tags are all there, so if we could somehow interrogate each tag in the registry (similar to using Reflection) — or at worst case be able to define the attributes and types each tag takes in the registry — then we could automatically generate the tag builder functionality instead of having to manually keep it in sync with tag developments.

You could, but you pretty much would have to rewrite the tag handler model to use objects rather than what-ever-goes callbacks. Tags would have to be able to announce their attributes. Rather than…

or at worst case be able to define the attributes and types each tag takes in the registry

…this messy tactic. I don’t want to see that mess as part of the core. It’s better to have the registry as separate than have that.

As minimum you would need a class interface representing:

A tag (few interface to present different types).
A tag attribute (the value is processed and validated in it too, e.g. escaped/encoded).
Iteratable registry.
Tag constructor (one that puts that all together and returns string presentation of a tag).

And all of this needs to be data, rather than action, based. There can be no executions done by the plugin itself involved when generating the tag snippet. A single tag would look something like:

class MyTag extends Textpattern_Tag_SingleTag
{
    public function getAttributes()
    {
        return array(
            new Textpattern_Tag_TagPlainStringAttribute('name'),
            new Textpattern_Tag_TagPlainStringAttribute('value'),
        );
    }
}

And the tags return value could be processed automatically too. This has the benefit that we can add some attributes that are provided by the core. E.g. wraptag, class, break, label and labeltag would work on any tag as those are handled by the parent Textpattern_Tag_TagInterface implementation. The bad thing is that it breaks backwards compatibility — maybe. We can turn all current tag handler functions into wrappers.

Last edited by Gocom (2014-04-30 19:15:25)

Textpattern CMS

Textpattern CMS support forum

#1 2014-04-29 11:49:31