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

Collapse
Posted by Gustaf Neumann on
If one wants to provide styling just for &lt;tr&gt;, is there a reason one can't use a special CSS class on the &lt;table&gt; and use this for styling the &lt;tr&gt; 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! 😊