Hi Devin I'm afraid the development documentation is still lacking somewhat, but there's also a few places where the APIs could be extended to provide a bit more sugar to make common tasks simpler.
Anyhow, did you find Chris Hunt's guide? It's quite old but still accurately describes the widget mechanism: http://cjhunt.github.io > I wrote an interactive map using canvas. It draws lines on the map. The map is a JPEG image that the JS reads via a data URI and draws it to the canvas. A table has click events attached to the cells to make the JS code draw arrows on the canvas. This all has four distinct files. Developing for TiddlyWiki is not like conventional jQuery development. It's more like Angular or Reactive. The core engine continuously rebuilds to the DOM tree to make it reflect the changing state of the tiddler store. Any changes to the UI must be achieved indirectly, by modifying the state of the tiddler store, triggering a refresh to reflect the new state. Any DOM nodes that you construct may be unceremoniously deleted due to a dependency change higher up in the render tree, and then you will be asked to recreate them when they move back into view. This is in stark opposition to the ordinary jQuery world where one routinely stores state data in the DOM. So, for an application like yours you need to break it down to understand how the state of your UI will be modelled as the values of tiddlers. Then you write widget render/refresh code that updates the DOM according to the tiddler state, and event handlers that modify the underlying tiddler state. Perhaps your mapping widget would have an attribute containing the title of the tiddler containing the map image, and another attribute containing the name of a tiddler containing the currently displayed arrows (maybe stored in JSON). Your widgets render function would create a canvas DOM element, draw the map and draw the arrows over the top. The refresh function would handle rerendering if either attribute or target tiddler has changed. It would also wire up event handlers in the DOM. > should be this instead: div.innerHTML = '<i class="foo">Foo</i> Bar'; The problem here is that when we render on the server we don't have a real DOM. Instead, in those situations we use $tw.fakeDocument, a simple JavaScript implementation of a minimal DOM api. It doesn't support innerHTML because that would involve parsing HTML, which is a bit ambitious (and slow). So, that's why any DOM elements built by widgets must be laboriously assembled with appendChild() etc. If you can make tomorrow's hangout ( https://plus.google.com/events/cved4m2k911ad40aqm76mvdgcs0) I'd be happy to answer any questions - or of course keep asking stuff here or on GitHub. Best wishes Jeremy On Sun, May 11, 2014 at 10:05 PM, Devin Weaver <[email protected]>wrote: > My confusion was two fold. First there isn't a lot of docs stepping a new > TW developer through writing a plugin especially for TW5. Also it seems by > looking at the many plugins in the core they don't reference their DOM > through another tiddler instead make their own DOM via JavaScript which is > barely documented (the TiddlyWiki way and $tw.utils). I think answer is to > write a widget plugin that will construct the needed HTML through > javascript code and not through an already defined tiddler. If that makes > any sense. > > A widget tiddler with > > <div class="myWidget"> > <i class="foo">Foo</i> Bar > </div> > > should be this instead: > > MyWidget.prototype.render = function() { > var div = this.document.createElement('div'); > div.classList.add('myWidget'); > div.innerHTML = '<i class="foo">Foo</i> Bar'; > // Do a LOT! of boilerplate copy/paste. There has got to be a more > modular way. > this.innerDomNode = div; > this.outerDomNode.appendChild(this.innerDomNode); > // Assign classes > this.outerDomNode.className = this["class"] || ""; > // Insert element > parent.insertBefore(this.outerDomNode,nextSibling); > this.renderChildren(this.innerDomNode,null); > this.domNodes.push(this.outerDomNode); > }; > > > Gosh the later seems kind of convoluted! Is there any better way?! > > Maybe this should be moved to TiddlyWikiDev (Can never get the two strait) > > On Sunday, May 11, 2014 9:56:44 AM UTC-4, Devin Weaver wrote: >> >> Many times I have the following thought process and I don't know how to >> bridge the gap from source code to TW5 plugin. I'll have a neat HTML/CSS/JS >> snippit working in jsbin.com or jsfiddle.net and wish to add it to a >> TiddlyWiki document. Because it is multi format (HTML, CSS, JS, maybe a >> data URI based image) this presents some complication making it a one off >> plugin. Here is an example use case and workflow I'm in now: >> >> I wrote an interactive map using canvas. It draws lines on the map. The >> map is a JPEG image that the JS reads via a data URI and draws it to the >> canvas. A table has click events attached to the cells to make the JS code >> draw arrows on the canvas. This all has four distinct files. >> >> So I thought this would be a great tiddler to add to a TiddlyWiki that I >> could have other documentation tiddler etc. Perfect for a one off >> documentation document I could pass around the office. Thing is, there is >> very little info on plugin writing for TW5. I realized that adding it to an >> empty TW was painful as the entire plugin needs to be packaged into a JSON >> object. So I had to start with >> >> tiddlywiki --init empty >> >> and start writing in a plugins folder. This handled the packaging but >> left me lost as what and where to place the pieces. And then how to >> integrate them into the TW system. At first I thought this could be a >> single tiddler but then I started to wonder if it should be a widget or >> maybe a macro. Not sure. >> >> Is there any guidance for writing plugins and the style / organization / >> conventions one should use? What exports are the plugins supposed to expose >> and how do you reference data like images to be read and managed via >> JavaScript (data URI possibly)? >> >> Any help pointing me into the right direction would be very appreciated. >> I'll happily take notes and maybe gather enough to write some tutorials. >> > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWiki" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/tiddlywiki. > For more options, visit https://groups.google.com/d/optout. > -- Jeremy Ruston mailto:[email protected] -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywiki. For more options, visit https://groups.google.com/d/optout.
