"It seems to me that this requires using *some* kind
of string matching (e.g. indexOf(), regexp, etc.) to locate those
"appropriate" places, so it really doesn't mitigate the text matching
concerns that David initially raised... it just matches a different
piece of text from a different kind of file format."
Your absolutely correct, it does match a different piece of text.
However it matches against a small template file which is written
concurrently with the plugin so it can be guaranteed that there are no
text matching problems.
"... and there *are* definitely cross-platform differences in the
innerHTML handling... subtle things like collapsing whitespace
(outside of PRE elements), merging ('normalization') of large #text
nodes, retaining vs. omitting comment elements, use of TBODY in
tables, etc. "
True, but innerHTML is *only* used for extracting the javascript code
from the <script> area in the DOM
"Also, I still have concerns that..."
So do I. That's why the plugin is still in my experimental directory
on subversion, it hasn't even made it into my standard plugins
directory. I mainly wrote the plugin to satisfy my intellectual
curiosity, and to see if it could be done.
Martin
On 6 Jan, 17:45, Eric Shulman <[email protected]> wrote:
> > i) get a string that is a template for the TiddlyWiki file
> > ii) get the javascript from the DOM and put it in the appropriate
> > place in the template
> > iii) get the tiddler content and put it in the appropriate place in
> > the template
> > iv) put in the various other miscellaneous items that TiddlyWiki uses
> > v) save the file
>
> How do you locate the "appropriate place in the template" in steps
> (ii) and (iii)? It seems to me that this requires using *some* kind
> of string matching (e.g. indexOf(), regexp, etc.) to locate those
> "appropriate" places, so it really doesn't mitigate the text matching
> concerns that David initially raised... it just matches a different
> piece of text from a different kind of file format.
>
> ... and there *are* definitely cross-platform differences in the
> innerHTML handling... subtle things like collapsing whitespace
> (outside of PRE elements), merging ('normalization') of large #text
> nodes, retaining vs. omitting comment elements, use of TBODY in
> tables, etc.
>
> Also, I still have concerns that even if we ignore the formatting
> changes and loss of comments, the round-trip through innerHTML might
> corrupt the core code in some way that might not be immediately fatal,
> but would instead have the potential to damage or lose tiddler data
> when those mangled bits of code are actually invoked after reloading
> the document. Depending upon the specific code involved, that damage/
> loss could occur without any error or notice and be unknowingly saved
> back to the file... which would be very bad.
>
> It just seems to me that trying to use innerHTML for file saving
> purposes is fraught with special cases and cross-platform issues.
> Normally, I go for the more efficient, flexible, 'elegant'
> solutions... however, when considering the critical nature of a "file
> save" activity, *rock solid reliability* beats elegant every time.
>
> -e
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/TiddlyWikiDev?hl=en
-~----------~----~----~----~------~----~------~--~---
