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

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 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! :-)