Think about Loose Coupling | |
PerlMonks |
Re: Re: HTATR II: HTML table generation via DWIM tree rewritingby princepawn (Parson) |
on Oct 30, 2003 at 23:55 UTC ( [id://303453]=note: print w/replies, xml ) | Need Help?? |
When you unroll the tree, do you remove this attribute? This would be necessary to get valid XHTML, as no two nodes in an XHTML document can have the same id.Wow, I know nothing about XHTML, but you are right: this would be invalid XHTML for that reason... it's easy enough to tack on a counter to the id as I unroll it, if XHTML ever becomes pervasive enough for me to do so. The aggravating thing is that I did not see any examples in the XMLC docs for how they uniquify rows when unrolling tables. This leads to a more general question of attribute rewriting with this tree-based approach. I'm thinking specifically in terms of using a class attribute instead of putting in HTML-presentation based attributes like BGCOLOR.I'm not sure what you mean by "class attribute". I assume this has something to do with CSS? My HTML skillz are rather light --- just enough for rudimentary pages, nothing spectacular.
I assume it is done in a similar way to the content, in that you just repeat the row with another 'iteraten' id for each new attribute (easier for page designers, perhaps). The alternative is to have a single sample line, and programmatically replace the class value, as per the element content for each node. This approach has the obvious disadvantage that a designer would only see a table with one row.Because this paragraph follows of the discussion of "class attributes" from the previous paragraph, I am completely lost in this paragraph and cannot comment. One final thing to consider with the DWIM unrolling function: we often like to fill-out a table with a single row saying "No records returned" or similar when there are no records. This might be a useful extra argument to the DWIM function.That is true. In more user-friendly setups, where is not just dumping out data this would be a necessary thing. Now the implementation could follow two paths. The superduper table unroller come become even more flexible and accomodate such a message/table row OR we could have this:
I think just having a message row in the sample table and either detaching or displaying it is a more compact solution though. Thank you for the good ideas and discussion.
In Section
Meditations
|
|