RFC: core attributes

etc · 2016-11-03 09:13:15

NicolasGraph wrote #302594:

On my side I’d vote for the second meaning.

Me too, but the parser has no idea of what number or not:number means for each tag. It’s only the tag itself who knows what to do with number.

gaekwad · 2016-11-03 12:09:31

I’m not adding anything of value to this thread, but I’m really excited about the recent increase in activity with etc and makss getting more involved.

Sending appreciativeness via the intertubes, y’all.

etc · 2016-11-03 16:15:30

etc wrote #302597:

And what would we do with this default value? Pass it to both tags and the parser?

I’m dumb, we would pass wraptag="" to the tag and wraptag="p" to the parser. Just need to tell lAtts() not to complain about “unknown” core tags, but this should be easy. Thanks, Nicolas, great idea!

gaekwad wrote #302609:

I’m not adding anything of value to this thread, but I’m really excited about the recent increase in activity with etc and makss getting more involved.

Thanks, Pete, your excitement adds a real value to this thread. :-)

ruud · 2016-11-03 16:57:04

etc wrote #302560:

But if we had not attribute, it could be

<txp:if_individual_article #not>...

Or…

<txp:not:if_individual_article>...

colak · 2016-11-03 17:26:40

ruud wrote #302619:

Or…

<txp:not:if_individual_article>...

how would you do this though?

<txp:if_article_list>
<txp:if_section name="">
<!-- you are on the default section/front page -->
<txp:else />
<!-- you are on another section -->
<txp:if_category>
<!-- you are in a category with a list of articles -->
<txp:else />
<!-- you are on an individual article -->
</txp:if_category>
</txp:if_section>
</txp:if_article_list>

Untested but you get my drift.

etc · 2016-11-03 21:12:14

ruud wrote #302619:

Or…

<txp:not:if_individual_article>...

This is fine for binary attributes, but what if we need to set a value?

etc · 2016-11-09 11:55:20

Bump, we need a name! Or should we reserve few special attributes (wraptag, class, label, labeltag, not, ...) exclusively for core usage, hoping that there will be no clashes with plugins?

colak · 2016-11-09 12:18:58

etc wrote #302799:

Bump, we need a name! Or should we reserve few special attributes (wraptag, class, label, labeltag, not, ...) exclusively for core usage, hoping that there will be no clashes with plugins?

If i understand this correctly, reserving those attributes only for core usage will definitely break a number of plugins.

etc · 2016-11-09 12:29:42

colak wrote #302800:

If i understand this correctly, reserving those attributes only for core usage will definitely break a number of plugins.

I would be curious to see an example. The idea is to delegate wraptag="ul" (say) to core, and pass wraptag="" to plugins. If they interpret it as “no wrap”, it should be ok… unless there are also html_id, atts and other wrap attributes… which we could reserve for core too, but it becomes risky, right?

colak · 2016-11-09 13:57:50

Hi Oleg

smd_thumbnail for example makes use of the class attribute.

In the past there were a number of plugins which enhanced article_lists and they were using the wraptag and break attributes.

But as I said, I may not have fully understood.

etc · 2016-11-09 14:42:17

Thanks, Yiannis. Yes, many plugins accept wraptag attribute, but they all (or not?) use it in the same way: wrap the output in wraptag if given. But if you pass wraptag="" to smd_thumbnail, it does not wrap the output, right? My idea is the following: when you call <smd_thumbnail wraptag="p" break="br" class="thumb" ... />:

the parser detects wraptag="p" and class="thumb"
it keeps them for itself, calling <smd_thumbnail wraptag="" break="br" class="" ... /> instead (roughly speaking)
once smd_thumbnail returns its (unwrapped) output, the parser wraps it into <p class="thumb">...</p> block, as expected.

This way all tags (core and plugins) would automatically “accept” wraptag, without any change in their code. The question is whether all plugins already wraptag-aware treat wraptag="" as “no wrap”. Same for class and other potential core attributes.

Bloke · 2016-11-09 15:03:25

etc wrote #302803:

The question is whether all plugins already wraptag-aware treat wraptag="" as “no wrap”. Same for class and other potential core attributes.

A broad question!

For things like wraptag and class (and html_id, et al) that do something then I would expect most authors to handle empty cases the same way. But I know there are plugins I’ve written (zem_contact_reborn for example, although it’s not done on a potential ‘core’ attribute) where I deliberately set the default to null specifically so that I can detect if the user has supplied the attribute or not. That way I can take action in one of three ways:

User supplied a value: use it.
User supplied an empty value: a positive action on their behalf “I do not want this set”.
User did not supply the attribute at all: ignore the attribute entirely (if it was null) or apply the default if $atts had one.

For those reasons, when intercepting a global attribute at the parser level, I’d be inclined to pass wraptag=null class=null onto the plugin rather than wraptag="" class="" because then it’s as if the attributes don’t exist rather than “do exist but have been set empty”. I feel that might be more robust, but I can’t say for sure.

Does that make sense? Any downsides?

etc · 2016-11-09 15:32:34

Bloke wrote #302804:

… when intercepting a global attribute at the parser level, I’d be inclined to pass wraptag=null class=null onto the plugin rather than wraptag="" class="" because then it’s as if the attributes don’t exist rather than “do exist but have been set empty”. I feel that might be more robust, but I can’t say for sure.

Does that make sense? Any downsides?

It’s me, but when an attribute (say, wraptag) is not set by the user, I see it as “do what you deem appropriate with it”. And I can decide to wrap the output into something depending on context, other attributes, etc. But when I see wraptag="" it means the user expressly says “don’t wrap it!”

Bloke · 2016-11-09 15:36:41

etc wrote #302806:

when I see wraptag="" it means the user expressly says “don’t wrap it!”

Actually, you’re right. Ignore me. Passing "" makes way more sense.

etc · 2016-11-10 09:46:01

etc wrote #302799:

should we reserve few special attributes (wraptag, class, label, labeltag, not, ...) exclusively for core usage, hoping that there will be no clashes with plugins?

Ok, this will not work, unless we introduce tags attributes registration. Some plugin tags (like <txp:etc_search />) need wraptag and html_id to function. And if wraptag or html_id are empty or not set by the user, the tag generates them itself. The parser has no idea of what plugins need and can not do it for them.

Anyway, with <txp:evaluate />, wrapping will be easy:

<txp:evaluate test="wrapless_tag">
    <div id="some_id" class="some_class">
        <h3><txp:text item="some_label" /></h3>
        <txp:wrapless_tag />
    </div>
</txp:evaluate>

will output nothing if <txp:wrapless_tag /> is empty.

Textpattern CMS support forum

#16 2016-11-03 09:13:15

Re: RFC: core attributes

NicolasGraph wrote #302594:

#17 2016-11-03 12:09:31

Re: RFC: core attributes

#18 2016-11-03 16:15:30

Re: RFC: core attributes

etc wrote #302597:

gaekwad wrote #302609:

#19 2016-11-03 16:57:04

Re: RFC: core attributes

etc wrote #302560:

#20 2016-11-03 17:26:40

Re: RFC: core attributes

ruud wrote #302619:

#21 2016-11-03 21:12:14

Re: RFC: core attributes

ruud wrote #302619:

#22 2016-11-09 11:55:20

Re: RFC: core attributes

#23 2016-11-09 12:18:58

Re: RFC: core attributes

etc wrote #302799:

#24 2016-11-09 12:29:42

Re: RFC: core attributes

colak wrote #302800:

#25 2016-11-09 13:57:50

Re: RFC: core attributes

#26 2016-11-09 14:42:17

Re: RFC: core attributes

#27 2016-11-09 15:03:25

Re: RFC: core attributes

etc wrote #302803:

#28 2016-11-09 15:32:34

Re: RFC: core attributes

Bloke wrote #302804:

#29 2016-11-09 15:36:41

Re: RFC: core attributes

etc wrote #302806:

#30 2016-11-10 09:46:01

Re: RFC: core attributes

etc wrote #302799:

Board footer