Skip to main content
O
osgood_
Legend
August 23, 2018
質問

Javascript Data Binding

  • August 23, 2018
  • 返信数 3.
  • 3990 ビュー

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

    このトピックへの返信は締め切られました。

    返信数 3

    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_作成者
    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_作成者
    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_作成者
    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.

    WolfShade
    WolfShade
    Legend
    August 23, 2018

    pziecina  wrote

    I've not used vue so cannot say anything about it. For me all these new js frameworks bring nothing to the table that we do not already have, which is why I think they are primarily for js coders, they solve no problems but only add to them.

    Problems dam right there...........I think web-developers don't really feel fulfilled unless they are solving problems, mostly those of their own making

    pziecina  wrote

    The main difference between a spec such as flexbox not being supported and js being turned off, is that fallback for a w3c spec, (none js api) is not a 'show stopper', but js being turned off would be for a js framework if it is used for layout, styling and functionality on the client side.

    Well it could be a right mess.......even more so using data-binding and that's my real concern BUT I think its only a concern because there are workflows which can avoid the possibilty BUT how great is that possibily, pretty slim but its still a nagging doubt for me currently.


    I also prefer to use JS to actually submit the form, avoiding the input type="submit" in favor of using <button></button> with an onClick set to a function that will validate the data, then use document.formName.submit() if everything passes muster.  This way, if someone DOES have JS disabled, the form won't submit.

    HTH,

    ^ _ ^

    契約条件Accessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices