My drag and drop widget / example / coming client-side JavaScript library.
Directions / user info: Drag and drop the arrows to change the order of the letters. The order is being saved, but note there is some chance that someone else is changing the order at the same time. That is, I did not protect this with a cookie or session. Thus, if you refresh, you won't necessarily get the order you saved.
Also, saving the order will eventually break because the ordering floating point numbers will eventually underflow the smallest possible size. For my main use case, I am fine with this because the chance of an underflow I put at around 0.01% over the next few years of use. In this use case, I can live with those odds. The project's budget is not high enough to worry about such things.
To solve the problem, the server could check for a certain size, lock a resource lock / semaphore / mutex, and then multiply all the relevant rows (documents) by a billion or more, then release the lock.
I think the PHP language is the weakest link for an underflow. Client-size JavaScript says it can handle 5e-324, which is a mind-bogglingly small number. I'm not sure what MongoDB can handle. PHP can handle about 14 significant digits.
After I wrote the above, I increased the default base number in the example by several orders of magnitude. It will still break eventually. I'll leave that experimentation, research, and math to the reader.
This is one of my series of front end / client-side JavaScript examples.
As of July 11, the in-development version of my client's system has been using this for quite a few days. It seems to work.
On June 25, 2022, at 21:53, I plan to resync my site, reset the database, and then see how well the class works on my client's system.
I'm trying to create a drag and drop client-side JavaScript library with the following features:
It appears that I can abstract the library so that it will work in many instances. I won't know how well the abstraction works until I try it in a second instance. I plan to do this late on June 25, 2022, or soon after.
Early on June 23, 2022, I was working on my main client's application. To go back a few years, in 2017, he asked for a drag and drop feature on one of the pages. (Specifying the page possibly is a secret.) Once that was working, he wanted the drag motion to indicate where the row would go if it were dropped in that position. That's where I get this version's dashed, 4px wide border. A year ago, I added another drag feature. That one isn't a secret. There are account numbers associated with one or more court docket numbers. He wanted to be able to drag the account number to specify which one would be billed--the one on top.
For the last 7 months or so I've been reworking the whole application to free it from Drupal. When I was reworking the original drag and drop page, I decided to rework a number of points beyond escaping Drupal. On the "secret" page, a drop can cause a few dozen fields to recalculate. Previously, I was saving all those fields, and I had to make sure that the saves didn't get out of order in terms of which got to the server first. I realized a few weeks ago that I only need to save the order and one other field. I don't need to save those fields on the back end because based on one field and order, the rest of the fields are derivable. I don't have to worry about network order because I disable drag until the server returns "OK."
The other night I was reworking the account number drag feature, and I decided to change it to work the same way with an order number. I decided to stop the billing clock and create a public library, then use that library for the new account number feature. I won't know how abstract the library is until I try to use it in my client's application.