Hey, Jeremy —

OK, good to know this stuff is on your radar.  For the time being, my 
plugin is functional (just less convenient than it could be).

My inclination would be to stand by for any future developments in 
TiddlyWiki's import workflow, and jump in and upgrade the plugin if and 
when those should occur.  I'm happy to participate in any conversations 
about the design of this system.

On Wednesday, 20 December 2017 16:59:57 UTC-6, Jeremy Ruston wrote:
>
> Hi Evan
>
> I'm working on this CSV "unpacker" plugin:  
> http://evanbalster.com/tiddlywiki/csv_unpack.html
>
>
> Good stuff.
>
> The introduction of deserializer modules, which I only discovered half-way 
> through the process, made things a lot easier.  But I'm a bit troubled at 
> the lack of a good mechanism for reporting errors in the import, or 
> allowing the user to customize the re-formatting of the data.
>
>
> The deserializer modules were originally primarily used in the boot 
> process where there is no possibility of showing a UI. (Similarly, they are 
> constrained to being synchronous because that's convenient for the boot 
> process).
>
> For the things I've built, I've used a few different workarounds:
>
> * For the xlsx plugin, there is a UI in the control panel, and the 
> deserialiser then refers to the tiddlers managed by that UI. That means 
> that the UI is separate to the import process
> * For the latest release of the text-slicer plugin, the functionality is 
> implemented as a toolbar button (and widget message under the covers), and 
> a modal dialogue is presented before the operation is performed
>
> None of them are particularly satisfactory. I think we need to:
>
> * extend the spec for deserializers to allow them to be asynchronous and 
> to present a UI
> * enhance the import mechanism to present a UI for selecting/overriding 
> the deserializer, and for interacting with the chosen deserializer
>
> There are some other enhancements that are overdue for the import 
> mechanism: diffs, and better handling of overwriting.
>
> There are a few scenarios I'm thinking about:
>
>    - The CSV can't be parsed due to some error.
>       - The wiki opens a tiddler describing the error, in addition to the 
>       $:/Import tiddler.
>       - OR:  The wiki displays error information in the $:/import tiddler.
>       
>       - The CSV is parsed successfully and the user needs to map CSV 
>    columns to field names in the wiki, previewing their effects.
>       - A configuration tiddler appears alongside $:/Import and allows 
>       the user to modify the imported data before finalizing the import.
>       - OR:  A "wizard" appears in the $:/Import tiddler and the user 
>       configures the import before proceeding to preview the tiddlers.
>    
> Indeed, that's a good summary of what is needed.
>
> So, my questions:
>
>    - Is it bad practice to create and/or display tiddlers from a 
>    deserializer?
>
> Deserializers shouldn't have any side effects besides converting their 
> block of text to an array of tiddlers.
>
>
>    - Is it possible to incorporate this sort of functionality (wizard 
>    steps and error reporting) into the import mechanism in current or future 
>    versions of TiddlyWiki?
>    
> It would need some reengineering to make it possible, covering both the 
> deserializers and the wider import mechanism. Detailed discussion about the 
> code might be better at GitHub; if you're interested in exploring it I'd 
> recommend digging into the existing implementation first.
>
> Currently my plugin requires all setup to be performed in advance, using 
> the plugin's settings.  I notice that one of the built-in deserializers 
> displays import errors by creating an imported tiddler to act as an error 
> message; I might adopt this "hack" in lieu of something better.
>
>
> Both those techniques are useful.
>
> Best wishes
>
> Jeremy.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "TiddlyWikiDev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to tiddlywikide...@googlegroups.com <javascript:>.
> To post to this group, send email to tiddly...@googlegroups.com 
> <javascript:>.
> Visit this group at https://groups.google.com/group/tiddlywikidev.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/tiddlywikidev/e1dd0adf-d80c-450e-91bb-3b6c8d20fdbe%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/tiddlywikidev/e1dd0adf-d80c-450e-91bb-3b6c8d20fdbe%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To post to this group, send email to tiddlywikidev@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/30cb2a83-d1d0-4be0-b67c-9ed6f8409385%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to