RFC: core attributes

etc · 2016-11-02 14:50:54

We are considering a possibility of universal “core” attributes in 4.7. This means they would be available and act identically for all tags. Few natural examples are wraptag, class, label and so on. Another (more technical) attributes might be not, parse, cache… We’ve got the technology, need names:

which attributes would you like to see in core
how to tell core attributes from proper tags attributes. We need some special symbol for this, say #attr, so it could look like

<txp:if_category #not name="cats,dogs" />

Please contribute :-)

colak · 2016-11-02 15:55:58

Hi Oleg,

Re the example:

would <txp:if_not_category name="cats,dogs" /> be more in line with txp tags?

I would love a <txp:cache> wraptag where we could use for articles. ie

<txp:cache>
<txp:title />
<txp:body />
</txp:cache>
<side><txp:article_custom sort="rand()" />

Another proposal re not could be the re-invention of <txp:if_article_id />

Currently we have

<txp:if_article_id id="20,30">
do something
<txp:else />
do something else
</txp:if_article_id>

which is slightly counter intuitive as the few wrap around the many.

I am wondering if

<txp:if_not_article_id id="20,30">
do something
<txp:else />
do something else
</txp:if_article_id>

would be maybe be more efficient.

A final idea re not could be

<txp:not section="about,contact">
...
</txp:not>

In short instead of creating attributes for not I would create new tags so as to keep the xml logic of txp consistent.

I would love to see what the community will suggest!

etc · 2016-11-02 16:39:02

Hi Yiannis,

I’d go the exact opposite way: reduce the number of tags, we’ve got already way too many. Why do you need if_article_list since you can use if_individual_article? Because

<txp:if_article_list>
    do something
</txp:if_article_list>

is easier to read/parse than

<txp:if_individual_article><txp:else />
    do something
</txp:if_individual_article>

But if we had not attribute, it could be

<txp:if_individual_article #not>
    do something
</txp:if_individual_article>

Last edited by etc (2016-11-02 16:40:01)

Bloke · 2016-11-02 17:30:12

etc wrote #302560:

reduce the number of tags, we’ve got already way too many.

Agreed! The number of conditional tags is ridiculous. And that’s without considering the daft comment tags, which have their own ‘not’ or negative logic variants. Yuk.

if we had not attribute, it could be <txp:if_individual_article #not>...

Yep. Or, to keep the amateurs out, and for seven characters less typing:

<txp:if_individual_article>
    do something
</txp:if_individual_article>

could become:

<txp:if_article_list #not>
    do something
</txp:if_article_list>

;-)

Oh this could open up a whole heap of trouble… but I kind of like it.

I’ve already touched upon various issues such as template readability, conditional tag overload, and handling global attributes in conditionals, so I’m not altogether sure we can pull this off intuitively without permitting some crazy constructs that make no sense and will tie the parser up in knots. But I like the flexibility it’ll give so I’m willing to explore it.

Gocom’s original suggestion reused the txp: prefix instead of introducing a new character. I’m not sure if that’s better (more obvious, less easy to miss) or worse (more typing, more ‘txp’ things floating around, so more difficult to quickly spot ‘real’ tags vs tag attributes in a sea of template code).

I’m inclined to think that a dedicated character or two might be better, but whether the # is the right tool for the job, I can’t say at this point. It’s been subverted by the hashtag generation, and traditionally means ‘comment’ in coding so I don’t know if it’s the logical choice. But I can’t think of anything better, short of using a simple colon.

<txp:if_category :not name="cats,dogs" />

Hmmm, not as easy to see. Are there any rumblings of stuff like this in other languages, or specs out there that we could learn from or mimic?

I’m also not sure how this’ll impact regular tags:

<txp:images #not category="marvel, dc" author="batman, spiderman" #wraptag="div" #class="imgWrap">
   // What images will I see here?
   // Ones that are NOT in categories dc or marvel AND not uploaded by author batman or spiderman?
</txp:images>

Isn’t this better, less ambiguous, and ultimately more flexible:

<txp:images category:not="marvel, dc" author:not="batman, spiderman" #wraptag="div" #class="imgWrap">
   // Now I know what I'm getting!
</txp:images>

or:

<txp:images category:not="marvel, dc" author="batman, spiderman" #wraptag="div" #class="imgWrap">
   // Crucially, the global attribute can be applied per attribute.
   // This shows all images that batman or spiderman have erroneously uploaded to categories outside their own domain!
</txp:images>

In other words, global attributes take a dedicated symbol and appear, separated by whitespace, distinct from other attributes. But the behaviour of an attribute itself can be “modified” by supplying some character and an operator immediately after the attribute itself, and it only applies to that attribute. So Oleg’s above example becomes:

<txp:if_category name:not="cats,dogs" />

or:

<txp:if_category name#not="cats,dogs" />

I don’t know the answer, just throwing out spanners…

Last edited by Bloke (2016-11-02 17:36:03)

Bloke · 2016-11-02 17:45:13

Another spanner, unless I’ve misunderstood the request and “global attribute-that-takes-a-value” is not the same as “global value-less-operator-that-does-something-to-the-overall-tag”: why do we need a dedicated prefix for global attributes? That kind of thing pushes the internal implementation of the parser onto end users.

Why does an end user need to remember “ah, yeah, this one is a global attribute so I need to prefix it before I can use it”?

Surely we can just introduce a set of global attributes that are merged into the $atts array at runtime so any tag that doesn’t have it, gets it automatically? That’s the approach that zem_contact_reborn v.4.5.0.0 takes. See the zem_contact_latts() function for rudimentary usage.

Last edited by Bloke (2016-11-02 18:05:04)

gomedia · 2016-11-02 17:51:04

<if_variable #trim name="xxx" value=" yyyyyy ">

Bloke · 2016-11-02 18:02:19

gomedia wrote #302568:

<if_variable #trim name="xxx" value=" yyyyyy ">

Hubba hubba…

etc · 2016-11-02 19:54:39

Nice ideas, thanks. I like not: syntax, eventually extendable to not:name and so on. There is, however, a huge difference between core not: attribute and tags not:name attribute:

not: will apply to any tag (core, plugin) at the parser level, without any modification in the tags code. It will just switch true and false parts of the tags content, that parser is aware of. This attribute is hence applicable to every tag.
not:name needs to be treated in tags code, since the parser has no idea of what name means for a given tag. And for most attributes not: is meaningless: what is not:break="br"?

Sorry, no hubba-hubba, trim: would apply to the tags output, not to value.

Bloke wrote #302566:

Another spanner, unless I’ve misunderstood the request and “global attribute-that-takes-a-value” is not the same as “global value-less-operator-that-does-something-to-the-overall-tag”: why do we need a dedicated prefix for global attributes? That kind of thing pushes the internal implementation of the parser onto end users.

Why does an end user need to remember “ah, yeah, this one is a global attribute so I need to prefix it before I can use it”?

Because they are global, i.e. universally applicable to any tag. Thus we have to avoid names collision. Ok, we could say wraptag is always doing the same thing, so we can delegate it to the parser and not to pass it to the tags. But what if some tag sets wraptag="p" by default? Then <txp:tag wraptag="span" /> will result in content, berk.

Bloke · 2016-11-02 20:06:56

etc wrote #302571:

There is, however, a huge difference between core not: attribute and tags not:name attribute:

Okay, it’s a conceptual difficulty in my brain then. I’ll lurk on the sidelines until I understand the difference!

And for most attributes not: is meaningless: what is not:break=“br”?…
what if some tag sets wraptag="p" by default?

Ah yeah, both valid concerns. This needs more thought…

michaelkpate · 2016-11-02 23:06:12

I posted this code block a couple of months on a different thread.

<txp:if_individual_article>
  <title><txp:title /> :: <txp:site_name /></title>
<txp:else />
  <txp:tru_tags_if_tag_search>
    <title>Tagged with <txp:tru_tags_tag_parameter /> :: <txp:site_name /></title>
  <txp:else />
    <txp:if_section name="">
      <title><txp:site_name /></title>
    <txp:else />
      <title><txp:section title="1" /> :: <txp:site_name /></title>
    </txp:if_section>
  </txp:tru_tags_if_tag_search>
</txp:if_individual_article>

I am not sure what could actually be proposed to make this more readable.

etc · 2016-11-02 23:27:43

Bloke wrote #302572:

Okay, it’s a conceptual difficulty in my brain then. I’ll lurk on the sidelines until I understand the difference!

It could be me not understanding as well :-) I mean, do you expect identical results for

<txp:if_article_category not:name="cats,dogs" number="2" />

and for

<txp:if_article_category name="cats,dogs" not:number="2" />

or they mean Category2 is neither 'cats' nor 'dogs' and Category1 is 'cats' or 'dogs', respectively?

NicolasGraph · 2016-11-03 08:56:12

etc wrote #302571:

Because they are global, i.e. universally applicable to any tag. Thus we have to avoid names collision. Ok, we could say wraptag is always doing the same thing, so we can delegate it to the parser and not to pass it to the tags. But what if some tag sets wraptag="p" by default? Then <txp:tag wraptag="span" /> will result in content, berk.

If it would be possible I would also like to avoid any extra character in fact. It would be more Txp:user friendly! ;-) Would it be that bad to do something like wraptag = wraptag ?: 'p' after attributes extraction to set the default value of these special attributes? Not ideal but it will maybe help to think about something better…

Textpattern CMS

Textpattern CMS support forum

#1 2016-11-02 14:50:54