4 ms·

I'd really like to know how to deal with users input, forms and other stuff without JS. Every tutorial we see today is like "throw tons of JS to this problem an

I'd really like to know how to deal with users input, forms and other stuff without JS. Every tutorial we see today is like "throw tons of JS to this problem and it shall work".

tsm 10y ago
Vanilla forms just GET or POST to some server endpoint with all of the <input>s passed in as query parameters. Frameworks (e.g., Rails) put some syntactic sugar on it, but that's really all that's happening. If the form submission contains invalid input, it's customary to return to the form page (with all the values already filled out) and show a server-generated message about what went wrong. JS is absolutely not required for any of it.
- GoodbyeEarl 10y ago
  Thank you! it is actually enlightening :) I think it's a little bit awkward to not use put, patch, delete... I wonder however if my server must follow the same technique, if not how to wire a delete endpoint to handle a form post and so on. I'll try to handle a form using only get and post sometime just to see how it works. Thank you!
  - flukus 10y ago
    Well you just made me feel old. For put/patch/delete you can just as easily wire different options to different URL's. We had URL's like /Foo/Delete?43. It may be awkward in a particular framework but it's about as simple as things get. I've always hated put/patch/delete because it tends to result in data centric UI's instead of workflow centric ones.
    - GoodbyeEarl 10y ago
      Hmm now that you mentioned I realized I've seen this pattern before but I've never given it a thought. I'll definitely try it sometime, it seems to work pretty well. BTW sorry for make you feel old, it was not my intention haha
    - GoodbyeEarl 10y ago
      Here it is https://github.com/viniciusCamargo/express-crud-barebone https://github.com/viniciusCamargo/express-crud-barebone here is my try on this approach to server requests. Any suggestion would be welcome! :)
- dzonga 10y ago
  I would really want to know more about this too, built a simple site without all that JS bloat
  - GoodbyeEarl 10y ago
    I'm glad for not being alone here :) I wish things were simpler...
  - GoodbyeEarl 10y ago
    I'm thinking about push some code to github this afternoon using these techniques with nodejs, if you want to I can send you a link to the repo ;)
CaptSpify 10y ago
Is this what you mean: https://www.w3schools.com/html/html_forms.asp https://www.w3schools.com/html/html_forms.asp ?
- teddyh 10y ago
  Please don’t ever link to w3schools. https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms https://www.w3.org/TR/html51/sec-forms.html#sec-forms https://www.w3.org/TR/html51/sec-forms.html#sec-forms http://caniuse.com/#feat=forms http://caniuse.com/#feat=forms
  - CaptSpify 10y ago
    Sorry, but why not?
    - gspetr 10y ago
      http://www.w3fools.com/ http://www.w3fools.com/
      - digler999 10y ago
        all that link says is that w3c is "not reputable". no evidence. For learning the basics in webdev (coming from C/C++) I've never had a problem with w3c.
        teddyh 10y ago
        It used to have more detail: https://web.archive.org/web/20110117085131/http://w3fools.com/ https://web.archive.org/web/20110117085131/http://w3fools.co... Even if they have fixed all these instances since then, that all those errors were ever produced is a bad sign, especially when there were better alternatives even then.
  - GoodbyeEarl 10y ago
    Hmm I've been using w3schools for quite some time now but I ALWAYS double check it with a third source, often MDN. I really like their straight to the point approach and I think they've been fixing some of the odd stuff lately. I don't really think it's really that bad if you already have some previous experience, it can work OK as a quick reference.
fl0wenol 10y ago
Are you being facetious? Otherwise I feel old. When I learned HTML4 forms and CGI, javascript was solely the domain of input validation if it was available. Okay I definitely feel old.
- GoodbyeEarl 10y ago
  lol sorry, but I was serious :P
quasse 10y ago
Where is your user input going in the end? If it's going to a server, I sure hope you're validating it there. Anything you do on the client side via JavaScript can be bypassed by the end user and provides no guarantees about the input you receive.
- appleiigs 10y ago
  Same with HTML. Need validation server side no matter what.
deleted 10y ago
[deleted]

I'd really like to know how to deal with users input, forms and other stuff without JS. Every tutorial we see today is like "throw tons of JS to this problem and it shall work".

tsm 10y ago

Vanilla forms just GET or POST to some server endpoint with all of the <input>s passed in as query parameters. Frameworks (e.g., Rails) put some syntactic sugar on it, but that's really all that's happening. If the form submission contains invalid input, it's customary to return to the form page (with all the values already filled out) and show a server-generated message about what went wrong. JS is absolutely not required for any of it.

GoodbyeEarl 10y ago
Thank you! it is actually enlightening :) I think it's a little bit awkward to not use put, patch, delete... I wonder however if my server must follow the same technique, if not how to wire a delete endpoint to handle a form post and so on. I'll try to handle a form using only get and post sometime just to see how it works. Thank you!
- flukus 10y ago
  Well you just made me feel old. For put/patch/delete you can just as easily wire different options to different URL's. We had URL's like /Foo/Delete?43. It may be awkward in a particular framework but it's about as simple as things get. I've always hated put/patch/delete because it tends to result in data centric UI's instead of workflow centric ones.
  - GoodbyeEarl 10y ago
    Hmm now that you mentioned I realized I've seen this pattern before but I've never given it a thought. I'll definitely try it sometime, it seems to work pretty well. BTW sorry for make you feel old, it was not my intention haha
  - GoodbyeEarl 10y ago
    Here it is https://github.com/viniciusCamargo/express-crud-barebone https://github.com/viniciusCamargo/express-crud-barebone here is my try on this approach to server requests. Any suggestion would be welcome! :)
dzonga 10y ago
I would really want to know more about this too, built a simple site without all that JS bloat
- GoodbyeEarl 10y ago
  I'm glad for not being alone here :) I wish things were simpler...
- GoodbyeEarl 10y ago
  I'm thinking about push some code to github this afternoon using these techniques with nodejs, if you want to I can send you a link to the repo ;)

CaptSpify 10y ago

Is this what you mean: https://www.w3schools.com/html/html_forms.asp https://www.w3schools.com/html/html_forms.asp ?

teddyh 10y ago
Please don’t ever link to w3schools. https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms https://www.w3.org/TR/html51/sec-forms.html#sec-forms https://www.w3.org/TR/html51/sec-forms.html#sec-forms http://caniuse.com/#feat=forms http://caniuse.com/#feat=forms
- CaptSpify 10y ago
  Sorry, but why not?
  - gspetr 10y ago
    http://www.w3fools.com/ http://www.w3fools.com/
    - digler999 10y ago
      all that link says is that w3c is "not reputable". no evidence. For learning the basics in webdev (coming from C/C++) I've never had a problem with w3c.
      - teddyh 10y ago
        It used to have more detail: https://web.archive.org/web/20110117085131/http://w3fools.com/ https://web.archive.org/web/20110117085131/http://w3fools.co... Even if they have fixed all these instances since then, that all those errors were ever produced is a bad sign, especially when there were better alternatives even then.
- GoodbyeEarl 10y ago
  Hmm I've been using w3schools for quite some time now but I ALWAYS double check it with a third source, often MDN. I really like their straight to the point approach and I think they've been fixing some of the odd stuff lately. I don't really think it's really that bad if you already have some previous experience, it can work OK as a quick reference.

fl0wenol 10y ago

Are you being facetious? Otherwise I feel old. When I learned HTML4 forms and CGI, javascript was solely the domain of input validation if it was available. Okay I definitely feel old.

GoodbyeEarl 10y ago
lol sorry, but I was serious :P

quasse 10y ago

Where is your user input going in the end? If it's going to a server, I sure hope you're validating it there. Anything you do on the client side via JavaScript can be bypassed by the end user and provides no guarantees about the input you receive.

appleiigs 10y ago
Same with HTML. Need validation server side no matter what.

deleted 10y ago

[deleted]