|
zajchapp wrote: Have a look around the 5 minute mark - they have a type of 'day view'. Ho, ho, ho.
Your remark sounds correct, but let me say this: There is a little difference between an additional view (that fits visually to the other views and therefore doesn't change the whole look&feel of ToDoList) and some attempts to change the GUI of ToDoList. Right?
Jochen
|
|
|
|
|
TCP_JM wrote: There is a little difference between an additional view (that fits visually to the other views and therefore doesn't change the whole look&feel of ToDoList) and some attempts to change the GUI of ToDoList. Right?
Absolutely. Was a 'hey look at this' - not really anything to do with the topic of the thread.
|
|
|
|
|
|
Thx Armando, those were very useful images, although _I_ found the main interface more overwhelming that TDL
However, there are some good ideas that I will look at some more.
ps. Is there a page of other screenshots that you can point me to?
|
|
|
|
|
|
One comment I would have is that pop out pages for data entry might look good but they are really inefficient. I strongly support the TDL approach of being able to have everything on a single screen even if it does make the interface look busy.
|
|
|
|
|
Reposting Re: How to hide the task ID in print outs using a x.aspx
Apologies if this is a faux paus - seems to me responses to old threads stay deeply buried with their threads; so nobody sees the question to answer if they know.
verithin wrote: ... Anyway, I managed to amend the TodoListStyler_v1.5s.xls file that comes with TDL to my needs, except that if I use this stylesheet for printing, it always prints the task ID (which is undesired).
If I use the same stylesheet for 'Due Task Notification', it works perfectly.
After having searched for this problem, I learnt that the task ID is always printed, unless a specific 'Hide' command is used to avoid this.
Could anyone let me know this specific command line to use it in the above-said stylesheet?
Later in the thread, it is suggested to comment out the call to task id in that stylesheet.
In my case, I'm beating up SimpStyler, which has no such call to comment out.
What is the nature of the 'hide' command referred to?
Neither <span hidden> nor <span style="display:none"> is doing it. (The markup is correct / accurate in the file itself - I can put test bits within the span and those bits are correctly not displayed.)
[Was hoping that by specifically calling (and hiding) it it wouldn't come out elsewhere by itself.]
The stylesheet correctly does not display the task id when called outside of TDL - task id is only diplaying when the stylesheet is called within TDL itself. (Print preview, print, or transform.)
|
|
|
|
|
Because without the task ID, a tasklist is virtually useless, I always add it even if the user did not ask for it.
However, if they did not ask for it then I add the HIDE tag, which is referred to by verithin.
So I'm guessing that it must be possible to test for this tag...
|
|
|
|
|
"Because without the task ID, a tasklist is virtually useless, I always add it even if the user did not ask for it." - to the code, maybe. Maybe not for a user with a small enough list. They'll likely be looking by position or name. Especially if the task id column is not visible.
"However, if they did not ask for it then I add the HIDE tag, which is referred to by verithin.
So I'm guessing that it must be possible to test for this tag..."
Which is what we're asking. We haven't come across the 'hide' tag you're referring to. Not saying it's not there, merely that we don't see it / don't understand, to comprehend what you're talking about and make use of your answer.
I don't doubt it's possible to test for the tag. I've tried. It's not working for me. I'm obviously trying the wrong thing and have asked what the right thing to try is.
Could you give an example? (Bit of code?) e.g. <xsl:if test="@ID"><span hidden><xsl:select @ID></span>
doesn't do it. (Apologies for incorrect syntax, going by very poor memory.)
|
|
|
|
|
|
(1) Now I'm confused:
"I always add it even if the user did not ask for it."
"However, if they did not ask for it then I add the HIDE tag"
Huh? OH, OK ...
I guess my question is then, what do you mean by a 'HIDE tag'
(2) This is wiggy ...
Just noticed ... if I export visible columns, I get task ids. If I export all columns, I don't. Wha?
(Whatever. I'll just use all columns - it's up to the style sheet to pull the columns it wants.)
(3) I think the issue is less that the task ids come out, than it is they come out in undesirable places. e.g. On a line by themselves in some cases, in others just before the comments, with no spacing afterwards. (IIRC.)
Which is to say, not under stylesheet control / where desired / formatted to fit in with the rest of the stylesheet determined positioning.
- if they came out, instead, in brackets or something, immediately after the title, I expect this would be less of an issue. As it stands now, placement is rather in your face noticeably out of place
(4) However ...
For reasons I can't fathom, comments always come out.
I would like to explain the difference in output for task ids between all columns and not - it feels like if that can be explained, then I suspect the cause of comments always coming out will also be explained.
Dan - if you are doing something special/different for task ids, all columns or visible only, could you please confirm the same (treatment) is happening for comments too?
- otherwise, I'm at a loss as to how to stop comments from coming out. (My stylesheet puts them in, in a controlled / suitable spot, but they're coming out on their own a 2nd time too. Which is baffling.)
|
|
|
|
|
Consider the SimpStyler sample xsl.
In there it calls for the field @TITLE, and like you would expect, prints the title.
There are lots of @{fields} that aren't called for and don't come out - which is a good thing.
Nowhere does it call for the comments, yet the comments come out.
Why is that? (i.e. There's something very basic there about stylesheets that I don't understand - enlightenment would be appreciated.)
How do I stop the comments from coming out?
(I want the comments, just under my control / formatting - not auto-magically appended. e.g. If I put the comment fields in, I get the comments twice. Under my control, and not.)
[Seems there's a different approach used in most of the other stylesheets, character by character control of -everything-. e.g. programmatically outputting all the html elements as objects, with css/style properties settings. Trying to avoid that level of 'indepth' programming Granted - absolute control, but also a LOT of work.)
It's not just a matter of turning comments off - Dan has indicated the way to do batch processing is via msxsl - there is no GUI at that point, and so no checkbox to uncheck. The stylesheet has to handle it and/or not have uncontrolled text coming out by itself.
|
|
|
|
|
_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 ?
|
|
|
|
|