Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

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?…

  1. article_id
  2. article_url_title
  3. author_email
  4. comment_anchor
  5. comment_id
  6. comments_count
  7. comments_error
  8. comments_help
  9. custom_field
  10. else
  11. error_message
  12. error_status
  13. expires
  14. file_download_author
  15. file_download_id
  16. hide
  17. if_article_author
  18. if_article_category
  19. if_article_id
  20. if_article_image
  21. if_article_list
  22. if_article_section
  23. if_author
  24. if_comments
  25. if_comments_allowed
  26. if_comments_disallowed
  27. if_comments_error
  28. if_comments_preview
  29. if_custom_field
  30. if_different
  31. if_excerpt
  32. if_expired
  33. if_expires
  34. if_first_article
  35. if_first_category
  36. if_first_section
  37. if_individual_article
  38. if_keywords
  39. if_last_article
  40. if_last_category
  41. if_last_section
  42. if_plugin
  43. if_search
  44. if_search_results
  45. if_status
  46. if_thumbnail
  47. if_variable
  48. image_author
  49. image_date
  50. image_display
  51. image_index
  52. image_info
  53. image_url
  54. images
  55. keywords
  56. link_author
  57. link_id
  58. link_url
  59. meta_author
  60. meta_keywords
  61. modified
  62. page_url
  63. php
  64. rsd
  65. search_result_count
  66. search_term
  67. site_url
  68. text
  69. thumbnail
  70. die
  71. variable
  72. yield

Offline

#2 2014-04-30 00:25:32

maruchan
Member
From: Ukiah, California
Registered: 2010-06-12
Posts: 590
Website

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!


When all is said and done, there’s nothing left to say or do.

My tunes videos blog

Offline

#4 2014-04-30 04:58:04

jstubbs
Moderator
From: Hong Kong
Registered: 2004-12-13
Posts: 2,395
Website

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

#6 2014-04-30 10:46:22

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

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

#7 2014-04-30 10:50:04

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

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:

  1. A brief tag overview description (pulled form the documentation somewhere).
  2. A link to the full tag documentation on the wiki (or its local help file if we go that route instead).
  3. 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

#8 2014-04-30 11:15:44

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

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

#9 2014-04-30 19:08:20

Gocom
Developer Emeritus
From: Helsinki, Finland
Registered: 2006-07-14
Posts: 4,533
Website

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

Board footer

Powered by FluxBB