> I have it working. Initially it was a bit of a pain as I needed to
> account non-existent keys. It _might_ (but I'm not sure) be useful to
> make the returned object have default empty values.
That makes sense. The reason they don't have empty values is that I
wanted the code to be able to extend gracefully to cover other types
of parsed relationship between tiddlers (not that I can think of any
besides "link" and "include"). The alternative would imply that the
parsing mechanism is aware of which relationship types are used by
macros, so that it can pre-create the fields of the "dependencies"
structure.
> In any case once I can that going and worked out how to effectively
> deal with the usual asynch whooha things seemed pretty okay. Couple of
> things noticed:
>
> * For now include and link mean the same thing to me as there's no way
> in TiddlyWeb to get a single tiddler without it's text, only with a
> collection. Changing this has been discussed in the past, so it might
> be time.
Right. Perhaps in this situation it would be convenient to be able to
retrieve the skinny JSON of a list of tiddlers enumerated by title?
> * When rendering a tiddler that uses the <<tiddler>> macro, whereas
> tiddler links in the outer tiddler are properly managed for resolution
> or missing, links in the inner tiddler are not. For example if both
> the inner and outer tiddler's reference "TiddlySpace" (and TiddlySpace
> exists in the context), then the outer tiddler will class the link "tw-
> tiddlylink-resolves" but the inner will class it "tw-tiddlylink-
> missing'. Is that something my code gets wrong, or something deeper?
Ouch. That sounds like a bug, I'll investigate.
> Still no clear picture on performace. At the moment the vast majority
> of time is spent satisfying the require statements, which is why my
> code moves all of those outside the Store constructor.
Yup, I've noticed that node.js stuff does end up having glacially slow
startup. A great nuisance when you're running lots of separate node
tasks in a shells script.
The interface to the dependency stuff is going to have to change a
little bit when I implement slices, sections and inter-space links.
I'll be parsing links into a structure something like:
{target: <title>, section: <section>, slice: <slice>, space: <space>}
It means that I'll no longer be able to use the link target as a
hashmap key, and probably will abandon the current approach of
counting references to each link destination.
Best wishes
Jeremy
>
> --
> 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.
>
--
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.
