search

projectEndings / staticSearch

A codebase to support a pure JSON search engine requiring no backend for any XHTML5 document collection
https://endings.uvic.ca/staticSearch/docs/index.html
Mozilla Public License 2.0
50 stars 22 forks source link

search-debug.html does not work; and we need a third test page too #234

Closed martindholmes closed 1 year ago

martindholmes commented 2 years ago

Although search-debug.html is created simply by copying the search.html page and replacing the link to ssSearch.js with ssSearch-debug.js, when search-debug.html is opened, the tests fail. That makes it useless for its intended purpose (debugging the test set). Additionally, because both of these search pages have automated tests embedded in them, they're extremely inconvenient for doing other types of test manually, so we should really have a third page using the same index and the ssSearch-debug.js file so that manual testing can easily be done.

martindholmes commented 2 years ago

Working on this in branch issue-234-testPages.

martindholmes commented 2 years ago

The first problem (broken debug page) turns out to be caused by the fact that the target to generate that page was not being called from most of our targets, including the default one. Fixed that in commit #e495ccc, and also decided that we might as well create this page for end-user builds too, because that provides an instant debug environment for the end-user, or for us if we're asked for help. @joeytakeda do you agree, or should we not do that in this case?

martindholmes commented 2 years ago

Pull request ready.

joeytakeda commented 2 years ago

First, totally agree that the staticSearch test build should have another page that contains none of the testing scripts, since the test scripts make ad-hoc testing quite difficult.

On creating the debug page for end-users: I'm less inclined to do that since it creates an extra page on their site without the project explicitly asking for it; of course, they could delete it afterwards, but needing to use the debug page seems fairly edge-case to me rather than something that should be turned on by default.

If the search-debug page is there purely to make debugging in the browser easier (rather than testing whether the Closure compiler works), then we might be better off simply providing the sourcemap, if the Closure Compiler in Java is able to create one properly: https://github.com/google/closure-compiler/wiki/Source-Maps. In my experience, the sourcemaps produced by sass, webpack, etc all work perfectly in Chrome and Firefox, but we would have to test to see if Closure does make useful sourcemaps.

martindholmes commented 2 years ago

Agreed on the source-maps; they work nicely for SASS, but I haven't tried any JS sourcemaps. But we definitely needed an additional page unencumbered by the test run. If you'd like to roll back the inclusion of the search-debug.html page in the non-test targets in the branch, please go ahead.

joeytakeda commented 2 years ago

Will do--and I'll open up a ticket for sourcemaps once I've rolled that back and merged, since that solves this immediate issue.

martindholmes commented 1 year ago

This appears to be complete; there is now a page called search-manual-debug.html which provides what we need.