Quote:(I should just note here that critiquing someone else's work is much easier than creating the document in the first place. It's kind of Marcelo to share with us.)
* I think people in this community are smart enough to appreciate the intention and value of a thoughtful critique, especially coming from you, Mark.
Quote:'Usage' note, 'Shortcomings' section. I'd rename 'Shortcomings' as 'Tinderbox/checkVist format compatibility issues' and then have
1. Although 'entries' can be converted into 'notes' and vice-versa within Tinderbox, checkVist does not allow notes to be containers. Therefore it is best to follow suit within Tinderbox.
2. In checkVist string values like "ASAP" are allowed. However, the Tinderbox attribute used to populate checkvist ($due) is Date-type and so only accepts dates (though Tinderbox's built-in date shortcuts work fine).
* Agreed. Changed.
Quote:'Usage' note, 'Quickstamps' section. The stamps don't change the background colours, they only populate data that will do so in checkVist. However, you could easily do this in Tinderbox by expanding the code to set either/both $TextBackgroundColor or $OutlineBackgroundColor. In either case you might want to use a tint of the colour - especially for text background so that the text/title remains readable.
* Thanks, I'll work on it later. For now, the colored badges stand for background color in Checkvist.
Quote:ASAP dates. Assuming checkVist stores & imports/exports ASAP due dates as a string "ASAP" you could simulate this in TB and export it. Make a Boolean $IsASAP and add it to the *entry prototype. To make a date ASAP for checkVist, set $due to "never" and tick $IsASAP. In your export template you then check for items where $due is "never" AND that $IsASAP is 'true' (ticked). For such items, insert "ASAP" instead of a date string for the 'due' OPML attribute. Unfortunately there's no way to capture ASAP state coming back from OPML import as the 'due' OPML attribute will map to TB's $due and non-date values will be ignored.
(continued...) Not tested, but if you made a $due String attribute, you could then add action code to populate a TB Date-type attribute (if even required) so the latter could do date arithmetic in setting $due whilst not squishing "ASAP" assignments. Unless you used this interchange a lot, that would probably be overkill. Indeed if you want to do a lot of interchange, checkVist has an API - which might be a better way of synching data (though requiring more formal coding skills - it's certainly not my area of expertise).
* sorry, man, but I do find this overkill. I think users can do without the "ASAP" tag (it's the only problematic string).
Quote:Testing due dates. You've hit the dates-in-demo problem in that the user actually needs to reset $due for (some of) the tests. You might want to address that in your instructions. Latter sort of issue and providing workarounds/explanation is part of why writing demos for other less familiar users is more work than assumed!
* Could you help me write the instruction? I don't really know how to make this point clear.
** better still: is there a dedicated topic on how to configure dates in tbx demos? If not, how about one?
Quote:Styling of checkVist attribute names. It might be worth an explicit mention in your instructions as to why we've so many user attributes that don't use TB's normal naming style ($due vs. $Due, etc.). I assume they are there to match checkVist OPML data import defaults. Given your possible code typo $text/$Text (in my last post above) there is all the more reason to explain why you're using potentially confusing attribute names.
* OK. Adding a caveat.
Quote:'item' export template. Assuming the attribute order within OPML tags doesn't matter (pretty sure that's true) then you can shift the 'user' and '_user_id' to the front of the output before you test the $Prototype value as these two OPML attributes are written regardless of whether a TB note is an checkVist entry or a checkVist note.
* OK, done.
Quote:'item' export template. Current usage for ^if()^ queries is to use $ prefixes for attribute names. For now, legacy support stops old usage failing but at some future point it won't. It's better to start out using current syntax. Therefore, in the template correct the following:
^if(Prototype=="*note")^ --> ^if($Prototype=="*note")^
^if(due!="never")^ --> ^if($due!="never")^
^if(tags)^ --> ^if($tags)^
^if(color)^ --> ^if($color)^
^if(bgColor)^ --> ^if($bgColor)^
^if(ChildCount==0)^ --> ^if($ChildCount==0)^
* Done! However, I took that from OPML built-in template itself:
Quote:^if(ChildCount)^^indent("\t",^value($OutlineDepth(parent)-1))^<outline^if(Text)^ text="^value(attributeEncode($Name))^" _note="^value(attributeEncode($Text))^"^else^ text="^value(attributeEncode($Name))^"^endIf^^if($Checked)^ _status="checked"^endIf^>
^children(/Templates/OPML/OPML item)^^indent("\t",^value($OutlineDepth(parent)-1))^</outline>
^else^^indent("\t",^value($OutlineDepth(parent)-1))^<outline^if(Text)^ text="^value(attributeEncode($Name))^" _note="^value(attributeEncode($Text))^"^else^ text="^value(attributeEncode($Name))^"^endIf^^if($Checked)^ _status="checked"^endIf^/>
^endIf^
Note that some attributes don't have "$".