Skip to main content
O
osgood_
Legend
August 23, 2018
Question

Javascript Data Binding

  • August 23, 2018
  • 3 replies
  • 3967 views

Probably the wrong forum but I'm trying to get some views.

If we are to use these new data binding javacript frameworks are we supposed to forget any possibilty that javascript may just be turn off. (I'm really not that concerned as that will apply to a small minority)

But of particular interest, is server-side validation a thing of the past - we used to do both client-side validation (the pretty stuff) and then run it through the more robust server-side validation.

Is there still any point in using a fall back server-side validation solution if what we see on the front end (assuming someone has javascript turned off) is some kind of rubbish like the below where data should be bound:

{{ formSubHeading }}

{{ showError }}

{{ responseMessage }}

The problem gets even worse if one uses a button to submit because that wont work.

<button v-on:click="submitForm">Submit</button>

Any one got any views about it?

My thoughts are if we didnt use javascript data binding but just javascript - no binding the page would still look ok and no-one would notice any difference.......it degrades gracefully and the server-side validation is in place to take over, no weird shite gets written to the page.

Maybe there is a way of hiding the {{}} in such circumstances.

My real question - is client side validation now considered to be just as robust a solution as serve-side validation given that no one gives a toss about the minority that may not have javascript. Can I just move on and forget server-side validation or if not how are you guys that are using data-binding getiing around the possibility of this {{ blahblah }} stuff being plastered all over the page plus elements that are hidden/shown using true or false:

<div v-if="showError">This is and Error</div>?

showError: false;

Well its going to show if no javascript, that could apply to numerous elements - what's so good about these frameworks, the more I delve into them they seem to me to be a bit flawed. I think they are good BUT only if they are pretty water-tight which means they need to be reliable in 99% of situations, are they?

Os

    This topic has been closed for replies.

    3 replies

    B i r n o u
    B i r n o u
    Legend
    August 24, 2018

    I think that the question is itself truncated or misinterpreted... we're not talking about JS... as a language taken into account or not by the browser... we're talking about data-binding, we're talking about AJAX techniques, we're talking about advanced user interaction... we're just talking about web applications...

    When a developer develops an application that will be installed on a machine, does he wonder if this user has a machine that will be impacted by the lack of components needed to run the application??? no, I don't think so... so a simple NOSCRIPT tag displaying an alert message that says JS activation is necessary to use this service should be largely sufficient and understandable...

    I wanted to play on network but I disabled my internet connection and I couldn't play... uh... I got a message informing me that I needed to be connected in order to play on network... funny, ins't it;)

    O
    osgood_Author
    Legend
    August 24, 2018

    Its a fairly simple question but if you choose to make it complex then thats your choice. Perhaps that is what is wrong with web development in its current state, there are no finite answers which is why more and more, if you read the blogs and posts, are struggling in terms of what to use and what not to use, drowning in a murky sea of confusion as there is little to no clarity being offered, only personal opinions.

    B i r n o u
    B i r n o u
    Legend
    August 24, 2018

    osgood_  a écrit

    Its a fairly simple question but if you choose to make it complex then thats your choice. Perhaps that is what is wrong with web development in its current state, there are no finite answers which is why more and more, if you read the blogs and posts, are struggling in terms of what to use and what not to use, drowning in a murky sea of confusion as there is little to no clarity being offered, only personal opinions.

    youps, sorry I didn't think I answered in a complex way... I thought I was explicit enough...

    so said very succinctly...

    In the framework of my work, I do not create web site, only web applications........ that is to say that I rely heavily on data-binding, a real massive usage of AJAX, plus quite complex interfaces in components of all kinds... and for that if the user has disabled JS, he then receives a message informing him that to be able to execute this application it requires the activation of JS....

    so yes I use JS in web apps, yes I use the NOSCRIPT tag to inform user that JS is necessary, and ys that works like a charm... and every one is happy that way... either those that tunr JS off...

    is it clearer?

    B i r n o u
    B i r n o u
    Legend
    August 24, 2018

    Sorry to catch the train running...

    while reading this thread, I must confess that I have trouble understanding,

    in fact I can't grasp what the real substantive question is, let me reformulate because it seems to me that there are various questions that intersect?

    1 - must the sites rely on a server-side content generation (PHP) or on a client-side dynamic generation (JS)? Pros vs Cons?

    2 - then, if a client-side generation is used, what to do for users who disable javascript?

    3 - finally, is the use of the NOSCRIPT tag a must and an obligation?

    am I correct ?

    O
    osgood_Author
    Legend
    August 24, 2018

    https://forums.adobe.com/people/B+i+r+n+o+u  wrote

    Sorry to catch the train running...

    while reading this thread, I must confess that I have trouble understanding,

    in fact I can't grasp what the real substantive question is, let me reformulate because it seems to me that there are various questions that intersect?

    1 - must the sites rely on a server-side content generation (PHP) or on a client-side dynamic generation (JS)? Pros vs Cons?

    2 - then, if a client-side generation is used, what to do for users who disable javascript?

    3 - finally, is the use of the NOSCRIPT tag a must and an obligation?

    am I correct ?

    The real question is/was:

    Should we/I push ahead and use current workflows and ignore the small minority who possibily have javascript disabled.

    I'd possibly in the near future like to include some of the new data-binding workflows which can be found in frameworks such as vue.js BUT Im concerned about the page if js is disabled - should I be concerned and why?

    What is your opinion?

    If I start using the below workflow and js is disabled, nothing will appear on the page:

    <div v-for="(holiday, index) in holidays" >

    <h2>{{ holidays.destination }}</h2>

    <h4>{{ holiday.departure }}</h4>

    <p>{{ holiday.description }}</p>

    </div>

    if I use a php loop through, as I normally do, then its pretty stable.

    Am I just being a trendy git and stupid to use data-binding?

    B i r n o u
    B i r n o u
    Legend
    August 24, 2018

    thanks OS for your clarification, this helps me to better understand the basic subject

    it is also true that I should have read the object first, but well... discussions often get out of hand and sometimes we are far from the main topic

    so if we're talking about dynamic data management only, and only as far as I'm concerned... and I don't present that as THE solution, I personnaly use NodeJS.

    but that's only going backwards to jump better because one then have to move our point of view on two other important aspects...

    the first being that if we use JS to dynamically manage the data, it goes without saying that once the user will interact with these data, they will very often have to react accordingly and therefore shape themselves, even modify and therefore load new values... so even if NodeJS, like PHP, only returns data formatted HTML... it will be necessary to use JS again

    the second is implicit somewhere... because if we manage data dynamically, it goes without saying that the interfaces that host them are themselves dynamic and use interface components that are mostly managed by JS as well.

    so the question becomes unique... what do we do about users who disable JS?

    WolfShade
    WolfShade
    Legend
    August 23, 2018

    osgood_  wrote

    My real question - is client side validation now considered to be just as robust a solution as serve-side validation given that no one gives a toss about the minority that may not have javascript.

    IMHO, no, server-side validation should never be ignored.  Hackers and script-kiddies can do some pretty malicious stuff if you rely only on client-side.  Keep doing both, or if you're in a bind for time use only server-side.  Server-side also has the benefit of using masks and whatnot to make sure that user-submitted values are properly formatted, and if you're using something like ColdFusion (either ACF or Lucee) you can use canonicalize() to decrypt encoded input, and even throw an error if nested or multiple encoded input is submitted.  (VERY nice.)

    But definitely use oWasp ESAPI on your server for stuff like that.  I know that HTML5 introduced a lot of things like making fields required and default show an error if it isn't, or input type="phone" or type="date" and whatnot, but I don't rely on any of that.

    HTH,

    ^ _ ^

    O
    osgood_Author
    Legend
    August 23, 2018

    WolfShade  wrote

    osgood_   wrote

    My real question - is client side validation now considered to be just as robust a solution as serve-side validation given that no one gives a toss about the minority that may not have javascript.

    IMHO, no, server-side validation should never be ignored.  Hackers and script-kiddies can do some pretty malicious stuff if you rely only on client-side.  Keep doing both, or if you're in a bind for time use only server-side.  Server-side also has the benefit of using masks and whatnot to make sure that user-submitted values are properly formatted, and if you're using something like ColdFusion (either ACF or Lucee) you can use canonicalize() to decrypt encoded input, and even throw an error if nested or multiple encoded input is submitted.  (VERY nice.)

    But definitely use oWasp ESAPI on your server for stuff like that.  I know that HTML5 introduced a lot of things like making fields required and default show an error if it isn't, or input type="phone" or type="date" and whatnot, but I don't rely on any of that.

    HTH,

    ^ _ ^

    Yeah I was so consumed I forgot about those, was just editing my post when you posted:

    Edited. I guess I ought to include the serverside anyway just for bots/spammers (forgot about those) BUT is anyone really concerned about the page presentation or maybe not being able to click a button to submit........that's my real concern. I dont care about malicious attempts because I don't care what they see.?

    I guess for the few its just bad luck - gotta move on I guess and use current workflows.

    O
    osgood_Author
    Legend
    August 23, 2018

    osgood_  wrote

    WolfShade   wrote

    osgood_    wrote

    Keep doing both, or if you're in a bind for time use only server-side.  Server-side also has the benefit of using masks and whatnot to make sure that user-submitted values are properly formatted, and if you're using something like ColdFusion (either ACF or Lucee) you can use canonicalize() to decrypt encoded input, and even throw an error if nested or multiple encoded input is submitted.  (VERY nice.)

    I think its a case of igonring the possibilty of the minority who might not have javascript but still including server-side to prevent malicious attacks. If the page looks a mess to either so be it.........I guess.

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices