* Initial Commit
* Add note to preview build
* Fix whitespace and indenting
Thanks @pmario
* Fix crash with unset $tiddler attribute on <$data> widget
Thanks @CodaCodr
* Don't duplicate "description" field in test cases
* Use different background colours for nested testcase widgets
* Extend the testcase widget to run tests
* Add testcases to control panel
* Add a view template body template to render testcase tiddlers
* Test edition should display testcases
* Whitespace fixes
* Make testcase tiddler tempalte link to itself
* Styling tweaks
* Docs improvements
* Styling tweaks
* Run the new tw5.com testcases in the test edition
* Update data widget to display its content in JSON
* Add testcase convenience procedure
* Clearer testcases for data widget, and docs tweaks
* Don't expect our intentionally failing test to pass
* Extend testcase default template so that the display format can be chosen
It is selected by setting the variable "displayFormat"
* DataWidget docs typo
* Fix data widget not refreshing
* Links in testcase output switch to the tab containing that tiddler
Thanks to @btheado for the suggestion
* Docs update for 648855e8a5
* Wording tweak
* Add support for narrative tiddlers in test cases
* Documentation improvements
* Cleanup comments
* Remove obsolete code comments
* Simplify template
* Docs update
* Rename $:/core/ui/testcases/DefaultTemplate/SourceTabs from $:/core/ui/testcases/DefaultTemplate/Source
* Use the view template body for failing tests
* Don't reference the geospatial plugin
* "Test case" should be two words
* Fix handling of currentTiddler variable
Fixes problem reported by @btheado in https://github.com/Jermolene/TiddlyWiki5/pull/7817#issuecomment-2103704468
* Prepare for merging
We create a system bag to contain each plugin/theme/language. It seems wasteful because it results in lots of bags, but the semantics are exactly right and so it seems like the right approach
Thank you @PotOfCoffee2Go I ended up taking some of your code from #8101 to get this up and running. There's still some stuff missing (like the tests!) but it gets things moving.
human readable in preparation to add data-title=<<listItem>>
for better UX defining a "read only" theme
Changes to be committed:
modified: core/ui/EditTemplate/controls.tid
modified: core/ui/PageControls.tid
modified: core/ui/PageControls/more-page-actions.tid
modified: core/ui/ViewTemplate/title.tid
modified: core/ui/ViewToolbar/more-tiddler-actions.tid
modified: plugins/tiddlywiki/menubar/items/pagecontrols.tid
* Fix a few typos
The "database instead of store" change isn't a typo fix, per se, but
these tests are testing the lower-level database layer, and I'm about
to introduce some tests for the higher-level store layer, so I want to
avoid any confusion in the test names
* Start on SQL store-level tests
* Add some tests for createBag
* Add test for getBagTiddler and getBagTiddlers
* Add basic recipe tests
* Add a test for saving a tiddler within a recipe
* Add store test for deleteTiddler
…otherwise we may end up in a situation where we're always stuck in an
"already in a transaction" state and often neglect to actually enter a
real transaction!
* Switch from better-sqlite3 to node-sqlite3-wasm
Seems to be slower, but might make cloud deployments easier by not having any binary dependencies
* More logging
* Temporarily use a memory database
We will make this configurable
* Revert "More logging"
* Resume loading demo tiddlers
* Cache prepared statements
Gives a 20% reduction in startup time on my machine
* Some more logging
* Update package-lock
* More logging
* Route regexps should allow for proxies that automatically decode URLs
Astonishingly, Azure does this
* Go back to a file-based database
* Less logging
* Update package-lock.json
* Simplify startup by not loading the docs edition
* Tiddler database layer should mark statements as having been removed
* Re-introduce better-sqlite3
* Make the SQLite provider be switchable
* Support switchable SQL engines
I am not intending to make this a long term feature. We will choose one engine and stick with it until we choose to change to another.
* Adjust dependency versions
* Setting up default engine
* Make transaction handling compatible with node-sqlite3-wasm
https://github.com/tndrle/node-sqlite3-wasm doesn't have transaction support so I've tried to implement it using SQL statements directly.
@hoelzro do you think this is right? Should we be rolling back the transaction in the finally clause? It would be nice to have tests in this area...
I looked at better-sqlite3's implementation - https://github.com/WiseLibs/better-sqlite3/blob/master/lib/methods/transaction.js
* Default to better-sqlite3 for compatibility after merging
* Use transactions when modifying multiple resources
This prevents partial changes from entering the database, and also
nets a nice speed-up.
* Keep track of transaction depth
…so we could someday potentially leverage SQL implementations that don't
implement nested transactions
