All, CC'ing TiddlyWikiDev (I hope) to bridge and continue the thread over there.
Tobias,
The title.replace(/'/g,"'") fixes the single quote problem that Morris found. The /'/g part is a regular expression to replace all instances of a single quote with "'" which is the javascript version of the HTML entity code %27 or a single quote. I think Eric was generating code quickly, on the fly and just missed putting the replace(...) code in for setValue, it is needed.
I did some work last night converting the plugin to use fields instead of <data> elements. Before doing a lot more, let me get that code and Tobias's contributions into TiddlySpot and pastebin. I'll have time this evening. As for SVN access, that's a big step isn't it? ;). I wouldn't want anyone to get the idea that I know what I'm doing...
Eric - As for why this, originally, used the DataTiddler plugin. I wanted to see if I could do this plugin using a form from Udo's FormTiddler plugin. From there it grew into an investigation of how to reference objects from various places within the document. Needless to say it got too complex and, being in the midst of it, I needed another mind to tell me that I was going down a needlessly complicated path.
Thanks! -Paul
On Jun 27, 1:12 pm, Tobias Beer <beertob...@googlemail.com> wrote:
> > 2) However... it isn't clear to me why you are using DataTiddlerPlugin to store the checkbox state information.
> I had the same thought, however I was not sure how field data getting > and setting was achieved, so I did not fiddle with that as well while > playing with Pauls code. Thanks for the reference on how this is done > with CheckboxPlugin. I guess looking at its code may be a good start > to understand how to use native tiddler fields instead of <data> > markup within a tiddlers content.
> What is -- title.replace(/'/g,"'") -- for and why is it only done > when getting but not when setting field data? Why not simply use > '+title+' as you did for setting?
> I believe you made a little mistake and forgot to reference to the > fieldname when setting, so that...> text+=" onchange='store.setValue("+title+",this.value)' ></html>|";
It took me a bit longer than expected, but version 0.0.3 is on
http://kronenpj.tiddlyspot.com/. I have not updated pastebin at this
point. This version uses fields rather than the DataTiddlerPlugin, so
tiddlers with previous data will not show up as expected.
Thanks to Tobias for working on this with me! Thanks Eric and Morris
for your input as well!
-Paul
On Jun 27, 2:30 pm, Paul Kronenwetter <krone...@gmail.com> wrote:
> All, CC'ing TiddlyWikiDev (I hope) to bridge and continue the thread
> over there.
> Tobias,
> The title.replace(/'/g,"'") fixes the single quote problem that
> Morris found. The /'/g part is a regular expression to replace all
> instances of a single quote with "'" which is the javascript
> version of the HTML entity code %27 or a single quote. I think Eric
> was generating code quickly, on the fly and just missed putting the
> replace(...) code in for setValue, it is needed.
> I did some work last night converting the plugin to use fields
> instead of <data> elements. Before doing a lot more, let me get that
> code and Tobias's contributions into TiddlySpot and pastebin. I'll
> have time this evening. As for SVN access, that's a big step isn't
> it? ;). I wouldn't want anyone to get the idea that I know what I'm
> doing...
> Eric - As for why this, originally, used the DataTiddler plugin. I
> wanted to see if I could do this plugin using a form from Udo's
> FormTiddler plugin. From there it grew into an investigation of how
> to reference objects from various places within the document.
> Needless to say it got too complex and, being in the midst of it, I
> needed another mind to tell me that I was going down a needlessly
> complicated path.
> Thanks!
> -Paul
> On Jun 27, 1:12 pm, Tobias Beer <beertob...@googlemail.com> wrote:
> > Hi Eric,
> > > 2) However... it isn't clear to me why you are using DataTiddlerPlugin to store the checkbox state information.
> > I had the same thought, however I was not sure how field data getting
> > and setting was achieved, so I did not fiddle with that as well while
> > playing with Pauls code. Thanks for the reference on how this is done
> > with CheckboxPlugin. I guess looking at its code may be a good start
> > to understand how to use native tiddler fields instead of <data>
> > markup within a tiddlers content.
> > What is -- title.replace(/'/g,"'") -- for and why is it only done
> > when getting but not when setting field data? Why not simply use
> > '+title+' as you did for setting?
> > I believe you made a little mistake and forgot to reference to the
> > fieldname when setting, so that...> text+=" onchange='store.setValue("+title+",this.value)' ></html>|";
Not really - it's essentially just storage with revision history, and not hard to get used to. If you're on Windows, TortoiseSVN integrates with Windows Explorer and makes it very easy to use Subversion.
Fred - Thanks for the voice of support. I think I'll wait a day or
two to see if anyone sees any problems with it. I'm about to start
actually trying to use it myself, so hopefully it'll cough up any
hairballs soon. :)
> > As for SVN access, that's a big step isn't it?
> Not really - it's essentially just storage with revision history, and
> not hard to get used to.
> If you're on Windows, TortoiseSVN integrates with Windows Explorer and
> makes it very easy to use Subversion.
Unfortunately there is no downward pointing equivalent to it ...like
there is when using the two named html entities:
∧ (∧) and ∨ (∨)
You might even want to check out these... though I have no idea which
ones are reliable across browsers:
˄ (#x2C4;) ˅ (#x2C5;)
↑ (#x2191;) ↓ (#x2193;)
▲ (#x25B2;) ▼ (#x25BC;)
▴ (#x25B4;) ▾ (#x25BE;)
2) If you wanted the table to be borderless as it is assigned through
the class "noBorder" in the code... you need to change the StyleSheet
tiddler, like I mentioned in the thread over at the TiddlyWiki group.
3) You might want to prefix any fields used with "tdp" or even "tdp_"
4) There shouldn't be any "dependencies" other than maybe the class
definition for "noBorder" in StyleSheet, is that correct?
Unfortunately... there is one major issue, I fear...
Using fields, the code now seems to run MUCH slower, especially when
increasing the number of tasks.
Here is what I guess would bring performance back to what it was:
Instead of using one field for each item/parameter that needs to be
saved... use one field for all TodoListParams and parse this field for
actual parameters as needed directly from within the code.
However - in a way - that would pretty much do what Udo's
DataTiddlerPlugin does which brings me to the idea of having an
adaptation of it to actually parse (maybe JSON formatted) data, not
from <data> markup within a tiddlers body but rather from any "named
field" that it is asked to process. I have no idea how big a change
that would be to Udo's plugin code. Has anyone else ever thought of a
"parser" (if that's the correct term) on data contained within ONE
field instead of many (hopefully&meaningfully) prefixed ones? Why
would I think that is a good idea... looks like performance is an
issue and it would reduce unnecessary "field-clutter" or even data
conflicts of plugins accidentally using the same fieldnames to store
values. As for that, I think it were a good idea to have everyone
using fields make a reference to their plugins which use them in a
list right here: http://www.tiddlywiki.org/wiki/Extended_Fields
> .. As for that, I think it were a good idea to have everyone
> using fields make a reference to their plugins which use them in a
> list right here:http://www.tiddlywiki.org/wiki/Extended_Fields
So that you don't have to wait til that happens, I made a quick
YourSearch on TiddlyVault - and it showed the following plugins have
to do with fields:
1. For me, the ∧ symbol appeared as a teeny circle, so I changed
it to something that at least pointed somewhere. I like the #25B2/
#25BC characters and have updated the tiddlyspot script with them.
2. I wanted a way to include the style within the output from the
script, but hadn't taken the time to adjust the "chrome" while the
functionality was broken. I've updated the TS script with a no-border
style sheet.
3. I've changed the field names to be prefixed with 'tdp' since that
seems to be a really good idea. Of course, existing tiddlers will
again be empty, except for N empty / undefined tasks with no
checkboxes ticked. Sorry.
4. This plugin uses both the CheckboxPlugin and InlineJavascriptPlugin
extensively, so they are truly dependencies. With the change in #2,
a changed stylesheet is not a dependency.
I haven't given the script enough data to see a performance problem,
either with fields or <data> elements. That could be a problem...
I'm sure a lot of the performance would be due to the script iterating
over the entire field set to display updates. Maybe better placement
of the refreshTiddler calls could be examined. Although, going back
to using DataTiddlerPlugin wouldn't be difficult as I still have the
code around... If it's truly faster, then it might be something to
consider.
-Paul
On Jun 30, 11:50 am, Tobias Beer <beertob...@googlemail.com> wrote:
> Unfortunately there is no downward pointing equivalent to it ...like
> there is when using the two named html entities:
> ∧ (∧) and ∨ (∨)
> You might even want to check out these... though I have no idea which
> ones are reliable across browsers:
> ˄ (#x2C4;) ˅ (#x2C5;)
> ↑ (#x2191;) ↓ (#x2193;)
> ▲ (#x25B2;) ▼ (#x25BC;)
> ▴ (#x25B4;) ▾ (#x25BE;)
> 2) If you wanted the table to be borderless as it is assigned through
> the class "noBorder" in the code... you need to change the StyleSheet
> tiddler, like I mentioned in the thread over at the TiddlyWiki group.
> 3) You might want to prefix any fields used with "tdp" or even "tdp_"
> 4) There shouldn't be any "dependencies" other than maybe the class
> definition for "noBorder" in StyleSheet, is that correct?
> Unfortunately... there is one major issue, I fear...
> Using fields, the code now seems to run MUCH slower, especially when
> increasing the number of tasks.
> Here is what I guess would bring performance back to what it was:
> Instead of using one field for each item/parameter that needs to be
> saved... use one field for all TodoListParams and parse this field for
> actual parameters as needed directly from within the code.
> However - in a way - that would pretty much do what Udo's
> DataTiddlerPlugin does which brings me to the idea of having an
> adaptation of it to actually parse (maybe JSON formatted) data, not
> from <data> markup within a tiddlers body but rather from any "named
> field" that it is asked to process. I have no idea how big a change
> that would be to Udo's plugin code. Has anyone else ever thought of a
> "parser" (if that's the correct term) on data contained within ONE
> field instead of many (hopefully&meaningfully) prefixed ones? Why
> would I think that is a good idea... looks like performance is an
> issue and it would reduce unnecessary "field-clutter" or even data
> conflicts of plugins accidentally using the same fieldnames to store
> values. As for that, I think it were a good idea to have everyone
> using fields make a reference to their plugins which use them in a
> list right here:http://www.tiddlywiki.org/wiki/Extended_Fields
I guess I was a bit quick about the cause of those performance
issues... it is not that there aren't any, but rather that they don't
seem to depend too much on whether you use fields or
DataTiddlerPlugin. Have you created a list with about 10 tasks and
tried to move those up and down or to add and remove items... for me
that's really quite slow @ 2GHz P4. Without wanting to complicate
things, but in order to change a task list efficiently the current
implementation doesn't seem to be all that performing. I am wondering
if it may be better to implement a dedicated "edit mode" - one that
doesn't refresh the tiddler display each time where changes are only
saved on a dedicated "commit" action. On the other hand... if it takes
ages to make changes - at a certain, rather quickly attained size of a
list - it might turn out to be more efficient doing good 'ol txt
editing a la copy&paste ;-)
I've just created a list of 16 items with the fields version.
Adding and moving each take maybe one second. Deleting takes several
seconds, probably because of all the swapping it's doing to move the
element to the bottom of the list.
So, moving an item added to the top of the list takes N seconds, and N
clicks / mouse movements. Deleting an item from the bottom of the
list takes about a second, and from the top perhaps N/2 seconds (mine
is ~6 seconds from a 16-element list). Still, not very scalable... :(
I have a thought for improving re-sorting and maybe deleting, but let
me think about that more. In a few seconds I've gone from "hey neat
idea" to "well, that may not really work too well." I'll see if I can
come up with a few more of the first type.
Other than performance, how is it working for you? It seems pretty
stable and consistent for me.
-Paul
PS: I'm also trying to keep the DataTiddler version (ToDoPluginDT)
functionality current with the fields version. I think in some
situations I may prefer to be able to edit <data> tags rather than
fiddle with fields.
On Jun 30, 4:45 pm, Tobias Beer <beertob...@googlemail.com> wrote:
> I guess I was a bit quick about the cause of those performance
> issues... it is not that there aren't any, but rather that they don't
> seem to depend too much on whether you use fields or
> DataTiddlerPlugin. Have you created a list with about 10 tasks and
> tried to move those up and down or to add and remove items... for me
> that's really quite slow @ 2GHz P4. Without wanting to complicate
> things, but in order to change a task list efficiently the current
> implementation doesn't seem to be all that performing. I am wondering
> if it may be better to implement a dedicated "edit mode" - one that
> doesn't refresh the tiddler display each time where changes are only
> saved on a dedicated "commit" action. On the other hand... if it takes
> ages to make changes - at a certain, rather quickly attained size of a
> list - it might turn out to be more efficient doing good 'ol txt
> editing a la copy&paste ;-)
The reason why removing a task from the top of the list takes longer
actually is due to swapping items... yet, it wouldn't take that long
if you'd remove refreshJs from swapJs and instead put it into each of
the commands that require refreshing the tiddler display.
