Saq, Just a heads up that this should no longer be an issue as of TW 5.2.0 for > most use cases. The refresh handling is more specific and checks for > changes in the transcluded field before triggering a re-rendering. So > changes to field "myfield" of tiddler A, wont cause a refresh for any > transclusions of the "text" field (or any field other than "myfield") for > tiddler A. >
This is awfully exciting and will make the use of forms and custom views of tiddlers much easier. This limitation has always felt like unnecessary complexity for users, not withstanding the technical reasons, I hope this will inspire more solutions, however the truth is this constraint has taken me down some interesting paths. So it does demonstrate how constraints can cause innovation. However it seems to me the ability to readily (as opposed to with difficulty) construct forms for the editing of tiddlers will unleash the possibilities and encourage more users. Once again I can see value in providing the tools through de facto standards will help, these include; - The way to implement modes eg view and edit - ie toggle a form to accept input or simply display. - Using a field to indicate an "object type" so tiddlers can identify the relevant form to present. - A suit of tools to populate a fields value from existing values, set lists and other lookups, or add a new value when permitted. - Additional field definition and field-type handling tools. Finally, a default form that allows editing of all existing fields from which the designer can rearrange and customise a form would be a good start. Regards Tones -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/ad1f62cd-d378-4cd9-bc3d-41a115be7392n%40googlegroups.com.
