Attribute names in plugin tags

jsoo · 2009-01-29 22:04:16

Philosophical question:

I’m working on a plugin that will have HTML table output as an option. I will not be using doWrap(), and the behavior will be slightly different from what users might expect from wraptag and break. Is it better to use the standard attribute name anyway, or to introduce a new name (I was thinking of “format”).

Trying to balance consistency of behavior with using standard names whenever possible. Thoughts?

Bloke · 2009-01-30 09:26:01

jsoo wrote:

Is it better to use the standard attribute name anyway, or to introduce a new name.

I came across this same issue when I was writing smd_tags. The tag output was tabular and complicated by the fact I wanted to offer the ability to display the data by a given number of rows or columns. I ummed and arred about it for ages and then decided that wraptag="table" was the way forward (and ignoring break) for one reason: if someone specifies a table output, it is not possible to use any other break tag — or anything else for that matter — inside a table, apart from <tr> and <td>. So having a dedicated attribute just for tables seemed over-confusing (since it would be technically feasible to use wraptag and some new table-only attribute in tandem).

So I simply detected if wraptag was set to table and, if it was, applied the usual class attributes to whatever I could, then hard-coded tr() and td() calls where appropriate. This kind of maintained naming conventions, with the caveat that break would not function if using tables.

At the time I think I chose (wrongly with hindsight) to be able to modify the wraptag by specifying how you wanted the data laid out. What I should have done was use the now redundant break for this purpose. So, for example:

<txp:my_widget wraptag="table" break="byrow" size="5" />

(or perhaps break="byrow 5" ?)
Would display:

1  2  3  4  5
6  7  8  9  ...

and:

<txp:my_widget wraptag="table" break="bycol" size="5" />

Would display:

But if you find an alternative way of approaching tables I’d be very interested in seeing how you do it because it may well open up some better functionality in future plugin revisions.

Last edited by Bloke (2009-01-30 09:29:10)

jsoo · 2009-01-30 11:29:09

Excellent reply, and you’ve convinced me to stick with wraptag for table output.

Interesting you would bring up an example of a widget where you want to allow the user to break the table into rows of arbitrary length — I may be offering that with this tag too. On first thought my inclination is not to use break for this. It works semantically, but is just too different from standard use of break, which is to stick something between or around every item.

So, again just first thought, I am thinking about row_length.

Bloke · 2009-01-30 12:37:28

jsoo wrote:

Interesting you would bring up an example of a widget where you want to allow the user to break the table into rows of arbitrary length — I may be offering that with this tag too. On first thought my inclination is not to use break for this.

I agree, it’s not a “clean” use of the break tag. I just figured since we are telling the table to “break” at a specific point, i.e. “wrap” to the next row it kind of fits, but I think you are right, it is too different.

That may have been my thinking when I used this (awkward, but optional) syntax in smd_tags: wraptag="table:bycol:5" / wraptag="table:byrow:5". But I can’t remember why I chose that over adding a new set of attributes. Probably stupidity!

I did have a special case, because I needed to allow you to specify that you only wanted to see N rows of data that could stretch out to the right as many columns as necessary until the data was exhausted. For most cases, rows (i.e. a fixed column count) are the only consideration.

So, again just first thought, I am thinking about row_length.

That works, yes. Good idea. As long as people know that it only makes sense if you use wraptag="table" and it gets initialized to some sensible default, then it’ll work rather well. Of course, if you decide that you want to allow someone to specify a fixed number of rows as well, then you would need an equivalent ‘column’ attribute, or some way of naming a generic attribute so it could apply to both rows and cols (e.g. size or something, though that’s not very descriptive).

Last edited by Bloke (2009-01-30 12:39:30)

jsoo · 2009-01-30 18:01:17

As much as I prefer to let users pick the formatting, at some level of complexity it is probably better just to dump out a pre-formatted widget. Or think if there’s a simpler way of accomplishing something similar enough. A table with arbitrary row length isn’t really a table in the purist sense, it’s probably just a formatting convenience. And for lining up boxes to fit a certain space, there’s a lot you can do with CSS on a plain string of inline elements, such as spans or anchors.

As for restrictive uses of break, I don’t mind given that Txp already has some such restrictions. Semantic restrictions, anyway: I’m thinking of something like wraptag="ul" break="td". You just wouldn’t do it.

Bloke · 2009-01-30 20:06:34

jsoo wrote:

As much as I prefer to let users pick the formatting, at some level of complexity it is probably better just to dump out a pre-formatted widget.

Definitely. As you say, a modicum of intelligence is assumed when using the wraptag/break pairs already, so any syntax screwups in the output are a case of RTFineM :-)

smd_tags was a special case I wouldn’t wish upon anybody! It was just due to the nature of trying to show nested lists in an otherwise tabular format. For example, if you had very regimented tags that all had a parent and 4 children, a conventional table could be told to display them like this if using a row_length of 5:

parent -child -child -child -child
parent -child -child -child -child
...

but it’s perhaps more intuitive to view them:

parent   parent  ...
-child   -child
-child   -child
-child   -child
-child   -child

Those people that don’t use nested tags can of course leave everything at the default and it’ll fill up a row-by-row table in the conventional sense.

Luckily, I don’t expose the API of the function that creates the table to users — it’s all governed by plugin preferences on the Extensions tab! The code is surprisingly inelegent for such a simple concept, when you take into account that HTML always renders tables by row…

Last edited by Bloke (2009-01-30 20:11:38)

Textpattern CMS

Textpattern CMS support forum

#1 2009-01-29 22:04:16

Attribute names in plugin tags

#2 2009-01-30 09:26:01

Re: Attribute names in plugin tags

#3 2009-01-30 11:29:09

Re: Attribute names in plugin tags

#4 2009-01-30 12:37:28

Re: Attribute names in plugin tags

#5 2009-01-30 18:01:17

Re: Attribute names in plugin tags

#6 2009-01-30 20:06:34

Re: Attribute names in plugin tags

Board footer