Still a lot nicer than paying for complexity you don't need before the system has even proved useful.
i one time made a html version that takes a query. js finds the line matching the text then hides everything before the previous seperator and after the next one. if a key is pressed it seeks the next match, if there isnt a (next) match foo-07.html forwards the query to foo-08.html which might not exist (haha) it shouldn't be so hard to update the js with a max value or check if it exists first but without such luxury it worked amazingly well for the amount of code involved
So the "local application that generates static files" is the one used by employees of the restaurant when a customer makes an order? Or is that used just for maintenance purposes when changing formats of the orders customers can do. But what I was confused most about was what "polls for orders" meant in this context.
The other thing I was confused about was the generation of "static files for customer ordering". So the application generates these files, which are presumably an html form (and/or corresponding PHP script) and uploads them to the server. And the server's html static pages that are used to order are accessed either locally on the box itself or through another computer on the local network connection (since you mentioned that it can run even when internet is down). Is my understanding correct?
Polls for orders means it reads the json-file that is appended to via the php-script when a customer makes an order from the web interface and imports new orders into the local database.
The application generates json-files, which are then read by static html files. This makes it easier to test with stub data and allows shipping the html/css to a designer if/when they want something nicer looking.
The html files and generated json data is never used locally.
Instead of doing the obvious thing and build a database connected web application hosted in the cloud; I opted for a local application that generates static files for customer ordering, uploads them to a web server and polls for orders. On the server there's a simple PHP script that writes a chunk of JSON to a file when the order is created.
The main motivation was to allow them to continue taking orders in the restaurant and perform maintenance even if the internet connection isn't working. Generating files also simplifies the implementation of customer specific customizations.
And since the database isn't customer/web facing any more and therefore doesn't need to scale beyond a couple of simultaneous users, I opted for a simple file based solution.
The fact that the customer order part runs blazing fast is a nice bonus.