I know this is difficult to explain, but history of project has prooved that maintaining this option, forcing developer to never shake server and customer code, and allowing me to see how code behaviour is when option is on just by reading the code that is or not seeing option saved us a lot of time and errors. Removing var will just means it will no more be possible to "see" what is code purely dedicated to manage client code and the rest. And i need this for quality analysis.
2015-01-19 3:33 GMT+01:00 Marcos García <marcos...@gmail.com>: > I can't agree... > > Blind users that use Dolibarr in a text browser has nothing to do with JS. > I am not saying that JS must be enabled by default but that HTML and JS are > prepared for this situation and there is no need to do a server check. > > E.g.: a form that has an input button which triggers a function that > checks if every field is filled. > 1. With JS, the submit action would be stopped and the check will be made. > 2. Without JS, the submit action would fire and the server will return > back a reply (saying that there are empty mandatory fields) > > Maybe we can't just remove the variable from the code, but... what about > progressively remove it after checking that it is working properly? Also we > could use Selenium in order to test that. > > Regards, > > > *Marcos García* > > marcos...@gmail.com > > > 2015-01-18 23:28 GMT+01:00 Laurent Destailleur (aka Eldy) < > e...@destailleur.fr>: > >> This option is really not to "use or not javascript" for common end user. >> But >> >> 1) to allow to make test to be sure that there is a good separation >> between code on browser and code on server. >> There is often code that make thing on server side (open a <td> or set a >> var) and finish on client side (close html tag or edit the var. With this >> option, it is easier to guarantee the code is clean for this. >> Because of this option we were able to move from a server solution for >> building graph into a js solution, with no impact of code and there is a >> lot of example. It guarantees a better architecture/coding, even if it need >> more works. >> >> 2) Also, we (I) are aware of blind people that uses dolibarr in text only >> browser and it is a strong voluntee to keep this. They does not use js. We >> cant' let browser decide. Because if js is disabled, by browser, we must >> provide same feature or at least a minimal feature to keep dolibarr usable >> but from php solution so from server code. Browser can't always provide >> alternative if js is disabled. >> >> A good example is the confirmation box but there is a lot of others. >> >> >> 2015-01-18 16:50 GMT+01:00 Marcos García <marcos...@gmail.com>: >> >>> Hi all, >>> >>> I was thinking about having this constant in Dolibarr and I can't really >>> fin a reason. It is the browser which decides to load Javascript or not and >>> our job as developers to ensure that Dolibarr is working with JS enabled >>> and disabled. There is no need to use a configuration entry. >>> >>> What do you think? >>> >>> Regards, >>> >>> >>> *Marcos García* >>> >>> marcos...@gmail.com >>> >>> >>> _______________________________________________ >>> Dolibarr-dev mailing list >>> Dolibarr-dev@nongnu.org >>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >>> >>> >> >> _______________________________________________ >> Dolibarr-dev mailing list >> Dolibarr-dev@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> >> > > _______________________________________________ > Dolibarr-dev mailing list > Dolibarr-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > >
_______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
