Menu Sign In Contact FAQ
Banner
Welcome to our forums

Looking for someone who can do PHP / JS

Nobody has volunteered to input on the above so I have another challenge to people who want to help on EuroGA:

The two text boxes in the new entry form (restaurant comments and general comments) both work fully but there is a subtle issue with pasting in text.

That issue seems to be mainly that the length of the pasted-in block is being wrongly computed so the cursor gets placed in the wrong place afterwards. It gets placed much further forward than the correct place which is after the last char of the pasted-in block, and often it ends up at the start of the text box. Not a problem really; just inconvenient – even if most people will never encounter it. Due to cost, I have now given up getting the dev to spend even more time on this. A really clever JS person might be able to find the problem.

I should mention that the code strips off formatting e.g. text copied from some website, a word doc, etc, always contains a font spec etc and this gets stripped off with some custom code. I think this is what makes the length calculation nontrivial.

The JS is visible in the client browser.

It’s been suggested that one should chuck away the current editor and use another one, but the next one might have some other bug which will cost a packet to put right… or it could have a problem with some specific browser like Safari v13.1.2.3 or whatever. Open source software is great until the author gets himself a girlfriend

Administrator
Shoreham EGKA, United Kingdom

What I find strange is that there is so much online – example – which practically tells you how to do this, yet there seem to be browser variations in practice.

Using a file picker “should” be possible to do in a totally browser type independent manner, surely? But maybe not drag/drop…

Administrator
Shoreham EGKA, United Kingdom

Peter wrote:

Is anyone here familiar with JS to upload files using a browser?

I’ve done it once… AFAIU it is an HTML 5 feature that should work the same on different browsers. The tricky bit is that upload is asynchronous.

Calling the JS function readfile will open a dialog box and read a text file selected by the user.

I’m sure more experienced JS developers will cringe. :-)


<input type="file" id="infile" accept="text/*" style="display:none" onchange="readfile2()">

<script>
function readfile() {
  document.getElementById("infile").click();
};

function readfile2() {
  document.getElementById("infile").value = "";
  var file = document.getElementById("infile").files[0];
  if (file) {
      var reader = new FileReader();
      reader.onload = function (evt) {
         // Get here when upload complete. The contents of the file is in evt.target.result
      };
      reader.onerror = function (evt) {
        alert("An error ocurred reading the file");
      };
      reader.readAsText(file, "UTF-8");
   };
};
</script>
Last Edited by Airborne_Again at 20 Jun 14:51
ESKC (Uppsala/Sundbro), Sweden

Is anyone here familiar with JS to upload files using a browser?

The airports database could have used something like Dropzone but instead the dev did it using very simple JS, which works with Chrome and in a slightly modded version with Firefox

document.body.ondragover = document.body.ondragenter = function(evt)
{
evt.preventDefault();
};

document.body.ondrop = function(evt)
{
fileInput.files = evt.dataTransfer.files;
handleFileSelect(evt);
evt.preventDefault();
};

But Safari does it differently… and each version does it differently. V13 does it differently from the previous versions, but we don’t need to support previous versions because probably everybody is updating to the latest one. There is a lot of stuff out there on google but I wonder if anyone here knows it.

Specifically you can just go to the new entry page and without entering anything else you can either use the file picker or drag/drop and see why it isn’t working. It is all client-side JS. It apparently works ok on Safari on IOS, and the d&d works when the device is in split screen. Under MacOS there are some confusing issues although the basic upload does seem to happen.

If this can be fixed it will save the cost of integrating some huge library like Dropzone, which may or may not follow browser versions anyway.

Administrator
Shoreham EGKA, United Kingdom

It depends how you move it out, and whether you configured the camera capture to “high efficiency” or “most compatible”.

With “high efficiency”, the local storage is HEIC. I you use “share” then select an app (that does not explicitly advertise HEIC compatibility?), you get JPEG. If you use “save to files” you get HEIC.

ELLX

This says that anytime you move an heic image out of an ios device it gets converted to jpeg automatically. Is this correct? If so then a lot of money got wasted

Administrator
Shoreham EGKA, United Kingdom

I wonder if there is anybody clever with JS who knows about this sort of thing.

Administrator
Shoreham EGKA, United Kingdom

Sure; this is why e.g. base64 uses a big character set. But it is still dumb to mix case in URLs in general use

Especially if one takes some care to make URLs descriptive, which is what most people do.

Youtube doesn’t have to do this case mixing and never did. Vimeo uses a simple number, for example. But anyway I have put in an input to the airport site mod list to specifically extract YT URLs (which is easy) and treat them separately.

The rest of the great unwashed, faced with remaining “edge cases”, will just have to do the really hard thing and swipe the URL first

Administrator
Shoreham EGKA, United Kingdom

Peter wrote:

Why Youtube does this mixed-case thing I don’t know but presumably it works for them because nobody actually reads those URLs.

That part of the URL is the internal video number, which is internally in the system probably just a 64 bit integer. The string you see is probably just an encoding of that URL in something resembling (but not exactly) base64. Using both lower and upper case allows the encoding of the number to be a shorter string, and makes the URL shorter. With only lower case, you’d do something like base32, and you would need 13 characters instead of 11 :)

There is a very complete explanation of this at https://webapps.stackexchange.com/a/101153

ELLX

most URLs are case sensitive

Of course, I know URLs are case sensitive after the domain name (not least because in most cases the subdomain is just a directory on a unix server, and unix is case sensitive) but that doesn’t mean it is a smart thing to use. It confuses the hell out of people to mix case in a URL. Those who are literate tend to go for lowercase, those who are illiterate tend to go for uppercase (which works for the basic domain) and you just end up with hassle. Why Youtube does this mixed-case thing I don’t know but presumably it works for them because nobody actually reads those URLs.

As I wrote earlier, I doubt one can do a reliable auto detect on this without at least doing a DNS on the candidate URL.

a browser based interface is a lot less efficient and takes many more instructions to display.

Sure; there are reasons why the modern version of the universe needs so much CPU power. There is indirection everywhere, and interpreted languages everywhere. And a lot of bloated code…

I did a bit of code quite similar to that map in around 1984 and it was just as fast. Hand coded of course, with DMA, etc. One wasn’t running PHP, JS and CSS on the Z80

Administrator
Shoreham EGKA, United Kingdom
61 Posts
Sign in to add your message

Back to Top