|
_BS_ wrote: Why is that? (i.e. There's something very basic there about stylesheets that I don't understand - enlightenment would be appreciated.)
Great question on something I just moved past very early on. Certain stylesheets seem to do odd stuff - like simplstyler. And I haven't yet been able to work out why.
I went to the character by character control method because of this. This seemed to do what it is supposed to.
A similar issue was raised in this post. I have checked the code, and haven't been able to find any significant difference between stylesheets that apparently use the same code by output differently (e.g. ToDoListStyler vs Z_DetailedReport). I still intend to incrementally snip out pieces of code to try to find the offending bits...
ToDoList 6.8.2 Feature Release - An effective and flexible way to keep on top of your tasks[^]
|
|
|
|
|
.
I do not (yet) have an answer, but I do have a solution.
My guess is that a transform reads the .xml from top to bottom, spitting out xsl formatted output along the way. If it sees a tag, and has an xml:template for it, it uses it.
When it doesn't, it strips any tags, and dumps out the contents.
(If it has a 'handler', it uses it. If it doesn't it uses a default handler, dump.)
So:
(1) You need an xsl:template match=COMMENTS line somewhere. (With nothing in it / between the tags - causing the content to be swallowed.)
(2) Even if you call for the comments via xsl:value-of select="COMMENTS"
I got here by starting with an absolutely blank .xsl and building it up (towards SimpStyler, could have been anything).
I figured the above out when even a blank xsl got:
GroceriesHomeTravelWorkBobJaneMaryPete
Wha? Where did that come from?
At the bottom of Introduction.tdl is:
<CATEGORY>Groceries</CATEGORY>
<CATEGORY>Home</CATEGORY>
<CATEGORY>Travel</CATEGORY>
<CATEGORY>Work</CATEGORY>
<PERSON>Bob</PERSON>
<PERSON>Jane</PERSON>
<PERSON>Mary</PERSON>
<PERSON>Pete</PERSON>
So, a bare minimum stylesheet is:
(Dan - perhaps this would be a useful bit in Resources/Stylesheets - BlankStylesheet.xsl, providing people with a zero line.)
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:strip-space elements="*" />
<xsl:template match="TODOLIST">
<html>
<head>
<title>SAMPLE PAGE TITLE</title>
</head>
<body>
<h2>HELLO WORLD</h2>
<ul>
<xsl:apply-templates />
</ul>
</body>
</html>
</xsl:template>
<xsl:template match="TASK">
<p><xsl:value-of select="@TITLE" /></p>
<!-- <ul><xsl:value-of select="COMMENTS" /></ul> -->
</xsl:template>
<xsl:template match="COMMENTS"></xsl:template>
<xsl:template match="CUSTOMCOMMENTS"></xsl:template>
<xsl:template match="CATEGORY"></xsl:template>
<xsl:template match="CATEGORY"></xsl:template>
<xsl:template match="METADATA"></xsl:template>
</xsl:stylesheet>
Adding the CATEGORY and PERSON pairs made the unexpected output go away.
GroceriesHomeTravelWorkBobJaneMaryPete
Therefore, I assume, if you're seeing COMMENTS, an equivalent pair is missing in the stylesheet. (With @COMMENTS, this would never have been an issue.) If so, add the two lines, and get on with your day.
Comment out the @TITLE call to make it disappear too.
Uncomment the COMMENTS calls to add in comments. ONCE!
If any of my very uneducated guesses are incorrect here, I would appreciate a heads up. VERY MUCH!
.
modified 13-Dec-13 11:06am.
|
|
|
|
|
|
Got to say, some of the language leaves me a little lost as a non-programmer. As I understand it:
@COMMENTSTYPE="849cf988-79fe-418a-a40d-01fe3afcab2c" indicates rich text comment
@COMMENTSTYPE="PLAIN_TEXT" indicates simple text comment
@COMMENTSTYPE is an attribute of the TASK node, and appears whether there is a comment present or not.
COMMENTS is a sub-node of the TASK node that only appears if there is a comment present. It contains the Comment text of the task.
CUSTOMCOMMENTS is a sub-node of the TASK node that only appears if there is a comment present, and it is rich text. It contains the rich text formatting information (I think).
I have not come across CUSTOMCOMMENTSTYPE
HTMLCOMMENTS is a sub-node of the TASK node, but does not appear in the TDL file. It is generated upon the transformation of the file, from the COMMENTS and CUSTOMCOMMENTS information (I think).
Note: If you start TDL (6.7) with -g for logging, the temporary tasklists generated for the transform are saved to C:\Documents and Settings\your_user_name\Local Settings\Temp . Useful for inspection.
Note: Attributes are addressed by adding an @ in front of the name, while nodes and sub-nodes are not. For example @COMMENTSTYPE and COMMENTS.
zajchap
|
|
|
|
|
For what it is worth, all this discussion has prompted me to look into this a little more. I have come to realise why this has taken me quite a while to get my head around. The thing is, creating stylesheets actually involves knowledge and application of several languages(? - not sure if that is the right term).
- xml: the structure of the data - a tree, and the particular schema you are working with
- xsl: the commands to manipulate the XML - how to do the transformation
- xpath: the commands to navigate the xml tree - what to do the transformation on
- HTML: the display language for the output - the output of the stylesheet
- CCS: the language to apply formatting to the HTML
I made a comment about this a week or so ago, but didn't really fully put 2 and 2 together. The stylesheets pretty much all take selected data from an XML file structure and transform it into HTML for presentation purposes.
I didn't really fully realise that the stylesheet is actually creating HTML, and therefore has a lot of HTML and HTML structures in it. Seems obvious now
zajchap
|
|
|
|
|
@COMMENT -> COMMENT noted.
You left out .xsd for the schema.
These are indeed all languages.
xml is just a database. Somewhat uniquely, it is human readable. And, human mungeable - the cause of many problems. And open to much abuse for not requiring strict adherence to a dictionary. Sure, go ahead and throw that new field in, what could the harm be? As everything before and after breaks down, perhaps years later.
As languages, these are all (relatively) trivial.
Two or three things whack us:
- It is not enough to know the language, the languages use objects. And every object is different and has a learning curve. Although the language is the same everywhere, the objects used typically depend upon the particular environment in which they are used. For example, different browser interpretations of the same information.
- for each file beastie, there is something interpreting it. The editor, the character set, the dictionary, the data query, the transform, the style, the browser. Let alone the independently operating GUI. A sequence of independent programs (each with their own specs, inputs, and outputs) that have to work sufficiently well contiguously to be able to take your keystrokes and munge everything into something that hits your eyes (in a browser, typically).
- now add in different browsers, different operating systems, different spoken/written languages ...
The stylesheet is a transform (set of instructions). A black box. It takes input, chews on it, and produces output. It can produce text, html, pdf, or anything else desired.
FWIW.
|
|
|
|
|
Yep.
I agree that xsl is relatively trivial (as are the others). What made it hard for me was that there was all this other 'stuff' in the stylesheet that didn't appear to be related to the xsl commands. Since I had only really had a passing involvement with HTML in the past for instance, it took me a while to recognise what this other 'stuff' was. It is how all these languages come together in a stylesheet that is the challenge.
For example, the thing that confused me for a while was the 'element' instructions - where did you get 'div' or 'table' et from - what were the different types of element, and could you just make them up. But now I understand these are from HTML.
And to get a stylesheet to do something else, other then produce HTML, requires knowledge of the intended output.
Perhaps all this just shows the level of my ignorance...
|
|
|
|
|
Not to worry, it's not just you, it's everyone.
Everything is interconnected. The xsl is just a transform (*). Using one, there is an inherent assumption, transform to what?
If HTML, then you 'must' understand HTML to know what you're putting out. For a browser to then interpret.
Because you've been (presumably) staring at the printed word for, forever, outputting to text is a bit more intuitive. If harder to read.
.csv is 'just' (text) fields, separated by commas and delimited by double quotes.
- until you get to something like dates ... MDY? DMY? YMD?
- how will the interpreting program decipher it? Which program? Do competing programs decipher in the same way?
Everything is interconnected. And there are only so many hours in the day - not everyone can grok the entirety of every connection. (Not just the connections, but each object used within - not just xml through xsl to html, but the xsl: and xpath used in the middle. And every beastie has its own set of objects - thus my earlier point.)
Which is why we have programs and programmers, so not everyone has to deep dive on every interconnection - to get us over the fiddly bit humps into something commonly human readable and actionable.
(*) [Not that you don't already know this.] I'm not finding a good definition for transform. In some ways they're views. (Although views seem more commonly to mean subset.) Whether in TDL, a browser, a spreadsheet, or a pdf, they are all just different ways of looking at (views) of the same data. The transform (xsl) is just a black box that takes a common set of structured input data (xml), munges (chews on) it, and spits out the same data presented differently. Such as in a manner that a browser understands how to display, or an editor (text), or spreadsheet (csv), or pdf.
- problem is, as a stylesheet author, you're 'it'. You have to grok the incoming data, how/what form the other app needs to be able to understand and display that data, and you have to figure out how to get from here to there. So, you have to understand how to read the incoming data (xml), interpret it (xsd), extract it (xsl:/xpath), what is being produced (.html), and code between the two. (And you're a bit behind the 8-ball without a rigorously adhered to and documented xsd.)
= unlike a meat grinder, where stuff goes in, (apparently different) stuff comes out, and most don't care how it happens in between, or an e-mail - something comes in, the program chews on it, and displays the message on your screen. In this case, Tag ... you're the one it. (To care about what happens in between.)
|
|
|
|
|
These discussions and some recent reading have been helpful in improving my understanding on this topic. I have a bit more of the bigger picture, which is always useful (seeing the wall, not just the bricks).
I think your definition of transforms seems to work. You are taking data (usually a subset), and presenting it in a different way. Sometimes this is for us humans to more easily read it. Other times it is to extract / re-order for further processing (you can transform xml to xml - i.e. creating a different data tree).
Incidentally, by chance I ran in to a old acquaintance today who happens to be a web programmer by trade and who has experience with HTML CCS (obviously), and a bit of XML and XSL. I am hoping to pick his brains some time in the next few weeks. Will see what comes of it.
|
|
|
|
|
Cool. Good for you.
Note - you are NOT taking a subset of the data, you are taking the entire data. You are fed a file, what you do with it is up to you.
Typically, you early on say 'only show me {this} much of it'. But that's a choice you are given the opportunity to make.
Much like any data base. You can say 'select *', or 'select name, comments where comments !="" and (completion_date or (start_date and not end_date))'
(Assuming a sql syntax query expression [vaguely remembered], which is what odbc brings to the table [common query syntax regardless of back end], and I've no doubt xpath.)
Not that I've a clue how to express that in xsl. Yet.
But the entire database is open to you.
If you strip out much of the '<xsl:{stuff}', you are left with what is pretty common programming and/or sql query syntax. From what I've seen so far. Which is why it's rather easy for most to write it.
The objects, on the other hand, are a different beastie. So, I can write it, but apparently, so far, what I'm writing is gibberish.
|
|
|
|
|
Hey,
I come quite late into the topic, but i find no way to decode the base64 CUSTOMCOMMENTS when i get a rich text comment.
Have you finally succeeded to do that ? ( without logging temporary tasklists generated, but using directly the tdl file ).
Thank you,
Best,
RoD
|
|
|
|
|
The comments are compressed before base64 encoded.
|
|
|
|
|
Ok, thank you.
Could you give more information about the way the string has been compressed in order to reverse it ?
|
|
|
|
|
|
Found no way to succeed corectly to reverse it, decoding with base64 and using zlib libs... tried several java libs to decode and decompress.
So, i gave up and found nothing else than manually launching the export from ToDoList using the XSL i customised, even if that's quite annoying.
But, now i'm facing another problem, in the .tdl file when you get a custom field date, the XML generated looks like:
<CUSTOMATTRIB ID="CUST_TESTDATE" VALUE="41760.760660" DATESTRING="01/05/2014" />
But, in the XSL generated thanks to "TODOLIST":
<CUSTOMATTRIB ID="CUST_TESTDATE" VALUE="41760.760660"></CUSTOMATTRIB>
So you lose the @DATESTRING, and i have no clue how to convert it from this value. ( it seems not to be a timestamp one ).
Any help would be appreciated
|
|
|
|
|
RoD`_^ wrote: So you lose the @DATESTRING Thx, I can confirm this as a bug which I will fix in the upcoming 6.9 release.
|
|
|
|
|
I found the same kind of bug while exporting.
You don't get the good "background" color name.
For example, if you choose an orange or pink background, it will export as "background:red".
|
|
|
|
|
Hi All
Yesterday a tree in my neighbourhood came down onto power lines, and to fix it the electricity company presumably had to cut power to the whole area.
End result: a completely rooted XP install, can't even access my C: drive from recovery console, so it looks like a reinstall.
Mind you, once I've accepted that, it's not such a big deal. Probably only the 10th reinstall over a 12 year period.
|
|
|
|
|
Dan, I held on as long as I could, but I migrated from XP to W7 and now W8. It's not as bad as it seems.
If you feel that you've lost any data you can remove the HD and re-attach it as a secondary drive in a new system. Then you can access the file system and pull everything over. But I'm sure you're an old hand at that game by now too.
I used to get my XP registry trashed every few months by some blasted thing and had a pattern memorized for recovery. I'd boot into another partition, copy specific restore files which get saved every couple days in XP, overlay the registry files under the Windows tree, and I would always be able reboot - even when Windows itself couldn't figure out how to do that for me.
In any case, a new install is never as comfortable as an old one but don't things run so much faster when you get rid of the old "bit rot"?
Good luck.
|
|
|
|
|
> and now W8. It's not as bad as it seems.
It is so. Run away ... run away ... run very, very, VERY, far away.
(But 7 can be wrastled into submission, and brings some good things. Sadly, they didn't migrate the returned up arrow in win 8 explorer back to win 7!)
- in 7 UAC can really be turned off. In 8 is doesn't go all the way off - and causes untold grief.
I have vowed to never buy Windows again. If it's got 8, it's getting nuked, first thing. Any pain I experienced with Linux (Kubuntu == Windows) over several years does not equate to the pain I experienced with 8 in a few weeks.
> If you feel that you've lost any data you can remove the HD
I was going to reply the same at the time, however, assuming Dan to be an intelligent being, and after reading "can't even access my C: drive from recovery console," I didn't think I needed to tell him that. If the drive is gone, she's gone. Hopefully he's got good backups - restoring software and settings is such a PITA.
What I don't understand is ... XP has always been solid for me. Never had registry issues. Never been unable to at least boot. Lost umpteen other drives, but always been backups or replicas, so I replace the drive, resync, and get on with my day.
Can't say the same for win 7 or 8 or even Linux.
Puzzled. {It weren't broke ...}
- mind you, I keep OS on OS, data on data, and the twain do not meet. And I robocopy everything back and forth inside the house every night.
- and image the C: to D: before doing so. But have yet to need it.
Go figure, and YMMV.
|
|
|
|
|
Hello Dan,
Please bear with this ignorant question: would it be possible to make virtual tasks work across tasklists--i.e., to copy a task from TDL file 1, and then paste it as reference in TDL file 2?
Thank you,
NT
|
|
|
|
|
It's already implemented. Make sure you have File Link column selected. Rightclick on a task in say tasklist 1, choose Copy As-Task Link (full), then paste it into File Link field for your task in your tasklist 2. Done!
Alex
|
|
|
|
|
Hello Alex,
Thank you for the response.
By "virtual task" I was referring to task reference, or task sync, rather than task link. When a task is copied and pasted "as reference" in the same tasklist, it is synced with the original task--i.e., any changes made to it, such as task completion or editing, are reflected in its original, and vice versa. I was just wondering if it would be technically possible to implement this most useful function across tasklists, so that tasks copied from one tasklist might be pasted into a second tasklist as virtual tasks that could sync with their originals in the first tasklist.
NT
|
|
|
|
|
Sounds a bit complicated to me, never used such a feature ("virtual task") before so it's kind of difficult for me to imagine where I would possibly use it.. What is it for?
Alex
|
|
|
|
|
Same task, two different lists, one is the master, one is a link (ghost) to the other?
|
|
|
|
|