Forum OpenACS Q&A: template::list::create adding a class to the <tr>

Request notifications

Is there a way within template::list::create to add a class to the <tr> tag? In the current call there is -class which gives access to the <table> tag class attribute and -main_class and -sub_class which gives access to the <td> tab class attribute but there does not seem to be a way to get access to the <tr> tag. Am I missing something. This has driven me crazy for years. I end up creating my own template and shoving my special case in.

If there isn't where is the best place to suggest a patch: the tip or bug tracker?

Thanks,

-Tony

Collapse
Posted by Antonio Pisano on
Hello Tony,

template::list doesn't enforce the use of an HTML table to represent the list graphically, because the actual tags used are decided by the adp template. For this reason, the options you mention don't address tr or td tags directly, but of course they could, if the list is built using a table in the end.

More specifically to your point, in a list we can agree there are at least 3 generic parts we could have displayed with a particular class: the list itself, the row and the column (note that I didn't mention any tag here). Ideally we would have 3 options, that could be 'class', 'row_class' and 'col_class'. template::list should just store their values and make them accessible in the template, as again their use will happen only in the adp.

I didn't check the actual use of the current class options in the vanilla adp OpenACS ships. One could tweak them to do what he wants (as you did) and decide one is for row and the other is for col, but if you read the docs looks like all the three class options are just meant for the list: one can specify the class the list is displayed with both directly ('class' option) or by joining 'main_class' and 'sub_class'. [1]

Personally I don't think other two options for the row and column class will hurt anybody, as long as they default to the current value when not specified, so I could suggest you to come out with your patch proposal, file a bug and attach it.

All the best
Antonio

[1] http://www.openacs.org/api-doc/proc-view?proc=template%3a%3alist%3a%3acreate&source_p=1

Collapse
Posted by Gustaf Neumann on
Keep in mind, that template::list is and should be logically independent from theming. One should specify in the template specification the "what" and in the templates the "how". So, when adding a new feature to template::list it should be clear, how this feature should interplay with the standard list templates (and custom templates).

My recommendation is to provide your own list template, because when it comes to styling, adding a single CSS class is barely sufficient. Have a look at the new openacs-bootstrap3-theme [1], which provides bootstrap-templates for template::list, template::forms, dimensionals, styling for display_templates, etc. A overview is given in [2]. One example of a new list template is the table-2third template of the bootstrap3-theme, which can be used e.g. with

<listtemplate name="subsites" style="table-2third"></listtemplate>. By defining custom templates, one can use different templates for the same list via the "style" attribute. By defining an custom theme package, one can overload also the standard theming templates without the need to alter openacs core packages.

-gn

[1] https://github.com/openacs/openacs-bootstrap3-theme
[2] http://openacs.org/xowiki/oacs-theming

Collapse
Posted by Brian Fenton on
Hi Tony

I can see why you would want this, and Antonio's proposal looks fine. I suppose the thinking at the time was that most people would just write their own ADP template (defined in the acs-templating DefaultListStyle parameter in my installation - it may have changed in more recent OpenACS versions).

regards
Brian

Collapse
Posted by Antonio Pisano on
Yep, in the end going with your custom template is already there and is the best way to go.

I thought we could let him do it because I understand that in Tony's use case he has an identical template where the only thing changing is the class, so for him it is natural to think to a row and column class option, but if you go that way many other options could come up to mind to the point things become chaotic.

Afterthinking, 'class' is an HTML concept, but nothing prevents you to build a template::list that is displayed using JSON or other non-markup syntax...

Collapse
Posted by Gustaf Neumann on
If one wants to provide styling just for <tr>, is there a reason one can't use a special CSS class on the <table> and use this for styling the <tr> with selectors like table.myclass tr {...}?

Maybe an more detailed description of the envisioned use cases helps.

Collapse
Posted by Antonio Pisano on
Another possibility could be to specify a different css page by page in the adp or by using template::head::add_css.

This way classes could stay the same and one will just switch formatting.

...many ways to achieve the result now that we think about it.

Collapse
Posted by Tony Kirkham on
I really appreciate all of the responses on this and I am thinking through each one considering the possibilities in order to come up with the best solution.

The truth is that I can always make my own template and do exactly what I want. With that said, I can do so much right now with the standard, or a standard, template that I like the simplicity. It just seems to be missing access into the row.

I do use the suggestion by Gustaf of classing the table to do things like attach drag and drop capability and to stripe using nth-child (in some of my custom templates I removed the odd-even standard classing because I need the dynamic striping in drag and drop scenarios.)

One use case I am working with is that I want to highlight each record / row (in whatever structure you can envision) with a color based on data for that record.

Another is that I want to add a custom attribute to the row (still, in whatever structure you can envision) so that I can grab that piece of data for the row and act on it via JavaScript.

I could place these kinds of things in a specific element/column via the html attribute of one of the list elements and then use JavaScript to place them where I want, but that defeats some of the benifits of what list builder does for me, get the html in a state that the browser can simply display it. No messing with the DOM. When this happens well even large amounts of data display lightening quick!

Thoughts?

-Tony

Collapse
Posted by Antonio Pisano on
Mmm, don't know if I understood correctly, but if I did you need to access each row in your template individually, so you can access its data and/or change some visual attributes.

For this you could decide for a nomenclature by which give a different id to each row, then build your list template so it assigns this id to each one of them. For example, you have a list called "invoices", each of your list row could have as id

invoices-row-(id of the record)

or

invoices-row-(num of the row)

This way you could access each one of them just by referring to its id. Of course you can navigate the dom on the fly to find it out, but by id it will be quicker.

Hope it helps

Collapse
Posted by Tony Kirkham on
Sorry, my question wasn't how to go about doing the id'ing, but rather what are the thoughts about is it worth adding a row accessor as a parameter to list builder verses leaving it as is and doing one of the many other work-arounds to get at the row.

Thanks,

-Tony

Collapse
Posted by Antonio Pisano on
Ok, if this is the case I don't think we need to add nothing in particular to the template::list procs (by this I mean from the data structure point of view). We could accommodate the vanilla templates so that this row id is generated and put in the markup, but for this we already have the necessary bits:
- list id
- elements names
- elements values
- possibility to specify a row key attribute for the list

This won't harm in my opinion and sounds like something useful in general. It will require the slight modification of every adp for displaying template::list currently in the platform (or at least every template building up HTML markup).

If you offer yourself, you could try to propose a patch! :-)