Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Tagbuilder - missing tags
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
Offline
Re: Tagbuilder - missing tags
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.
Offline
#3 2014-04-30 01:19:50
- Winstontaneous
- New Member
- From: California
- Registered: 2012-03-28
- Posts: 8
Re: Tagbuilder - missing tags
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!
Offline
Re: Tagbuilder - missing tags
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.
Offline
#5 2014-04-30 09:33:34
- jpdupont
- Member
- Registered: 2004-10-01
- Posts: 752
Re: Tagbuilder - missing tags
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.
Offline
Re: Tagbuilder - missing tags
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.
Offline
Re: Tagbuilder - missing tags
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.
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
Re: Tagbuilder - missing tags
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.
Offline
Re: Tagbuilder - missing tags
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)
Offline