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
