Hi Dan,
thanks for your thorough evaluation.
I generally agree with everything you have described here with one
addition: standard functionality should detect that JavaScript is
disabled in the browser and render an appropriate message to the user,
that activating JavaScript is mandatory.
A very brief check shows that the flag is also uses for setting
UserPreferance; this is not clear to me. I would like to check in the
next days and also consult with the team to check if there are any more
aspects we have to take into account.
Best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 28.10.24 um 16:04 schrieb Daniel Watford:
Hi Jacques,
Before I could answer your message, I had to spend some time reviewing
every location that I could find JavaScriptEnabled in the code to ensure I
understood its purpose.
I now realise that it is used to detect whether the browser has JavaScript
enabled, often conveyed from the browser to the server through a hidden
form field.
OFBiz code has lots of branch conditions around the JavaScriptEnabled flag
so I believe that - assuming we are happy to have JavaScript as a
requirements to run OFBiz - we should remove (or atleast deprecate) the
flag with an assumption that JavaScript is always present. This might mean
that users without JavaScript enabled have a degraded experience for the
future 25.x OFBiz release. However, I doubt many of us in the developer
community habitually test OFBiz with javascript disabled to ensure that
experience remains the same.
I see the benefits of removing this flag as the opportunity to simplify
numerous examples of branching logic and removal of code.
I would like to see the v24.x release notes include a statement that future
major releases of OFBiz will require javascript to be enabled in the
browser for correct behaviour.
For the cases you highlighted - <"JavaScriptEnabled" value="N"> - does
anyone know the intention behind disabling javascript for the subsequent
form submission? For the Login.ftl cases, although the hidden
JavaScriptEnabled form input is set to 'N', javascript running on the page
later sets the value to 'Y'.
Thanks,
Dan.
On Mon, 28 Oct 2024 at 09:33, Jacques Le Roux <jacques.le.r...@les7arts.com>
wrote:
Le 27/10/2024 à 13:35, Jacques Le Roux a écrit :
Le 26/10/2024 à 13:01, Jacques Le Roux a écrit :
Hi,
Should we still keep JavaScriptEnabled in soon 2025, and if so why?
TIA
Jacques
Please forget this inappropriate question
Jacques
Hi,
My question was not well expressed, if not cryptic.
Here is hopefully a better formulated question with a bit of explanation.
We are in 2025 and obviously JavaScript is everywhere.
JavaScriptEnabled is an old concept of the pre Apache era, it has more
than 20 years!
Without it a lot of features, like form fields autocompleting, are
unavailable.
I propose to not change any code but to set JavaScriptEnabled to true when
the user is signing in.
Note that this is already automatically done when you put
JavaScriptEnabled=Y in the login URL
as in /control/login?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
Unfortunately, that's not an obvious feature and may depreciate OFBiz
value when evaluated without it.
There are few cases, in plugins and themes, where JavaScript is not
wanted, hence JavaScriptEnabled sets to false,
(look for <<"JavaScriptEnabled" value="N">>).
That's not a problem, because it's only in forms and does not change the
initial session value of JavaScriptEnabled.
So my question is do we need a vote to apply this change?
TIA for your participation
Jacques
