JavaScriptEnabled

[Jacques Le Roux]

Hi,

What was the intial reason to introduce JavaScriptEnabled? Should we not rather rely on the browser setting to set it in user prefs?

Thanks

Jacques

[Adrian Crum-2]

How do we determine the user's browser setting?

-Adrian

--- On Sun, 1/16/11, Jacques Le Roux <[hidden email]> wrote:

> Hi,
>
> What was the intial reason to introduce JavaScriptEnabled?
> Should we not rather rely on the browser setting to set it
> in user prefs?
>
> Thanks
>
> Jacques
>
>

     

[Adrian Crum-2]

When the JavaScriptEnabled user setting was introduced, there was no way to determine if the browser had JavaScript enabled. I don't know if that has changed recently.

The only way to test for JavaScript being enabled is to include a small script in the login screen that adds the JavaScriptEnabled parameter to the login form. If the user has JavaScript enabled, then the parameter will be included in the login form, and ultimately in the login request URL.

I believe the setting is saved in user preferences, so it is persistent during the user's session.

If a user has JavaScript enabled when they log in, and then disable it, OFBiz won't know about the change - since it is updated only during login.

As long as users have the option to turn off JavaScript, then there will be the possibility that they will use OFBiz with it turned off. The OFBiz framework accommodates that: lookups are turned off and Ajax requests are converted to a page refresh. So, OFBiz still works with JavaScript turned off. In addition, the Flat Grey visual theme does not require JavaScript.

-Adrian

--- On Sun, 1/16/11, Jacques Le Roux <[hidden email]> wrote:

> Actually on the backend we already
> rely heavily on javascript enabled, try to disabled it when
> you launch initially with the default
> theme...
> That's why I asked this question. Moreover sometimes OFBIz
> reacts as if javascript was disabled when actually it's not
> (not sure why
> yet, but have a look at https://issues.apache.org/jira/browse/OFBIZ-2413)
>
> More to the point (your question actually): we could try to
> create a cookie using javascript at the beginning of the
> session
> (LoginWorker.login) and if it's not there we would know
> that somehow we can't use it.
> Because I have not digged deep but I can't understant why
> we use "Y".equals(request.getParameter("JavaScriptEnabled")
> there and rely
> on it further. It seems to me that it's not reliable.
>
> I think there is more to say about all that. Because if, by
> a way or another, we know that it's not usable, then we also
> know that
> some features are not active (again, for instance
> OFBIZ-2413) and we should mark them as disabled, which is
> obviously not done at
> the moment
>
> Jacques
>
> From: "Adrian Crum" <[hidden email]>
> > How do we determine the user's browser setting?
> >
> > -Adrian
> >
> > --- On Sun, 1/16/11, Jacques Le Roux <[hidden email]>
> wrote:
> >> Hi,
> >>
> >> What was the intial reason to introduce
> JavaScriptEnabled?
> >> Should we not rather rely on the browser setting
> to set it
> >> in user prefs?
> >>
> >> Thanks
> >>
> >> Jacques
> >>
> >>
> >
> >
> >
> >
>
>
>

     

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>
> When the JavaScriptEnabled user setting was introduced, there was no way to determine if the browser had JavaScript enabled. I
> don't know if that has changed recently.

We can use http://plugins.jquery.com/project/Cookie, it's already embeded in OFBiz.
1) We try to create a cookie using it
2) We test if the cookie has been just created
3) If yes we can use javascript else not

> The only way to test for JavaScript being enabled is to include a small script in the login screen that adds the JavaScriptEnabled
> parameter to the login form. If the user has JavaScript enabled, then the parameter will be included in the login form, and
> ultimately in the login request URL.

Yes instead of current "Y".equals(request.getParameter("JavaScriptEnabled") as I suggested below

> I believe the setting is saved in user preferences, so it is persistent during the user's session.

Yes it's is, just under the snippet above, in LoginWorker.login()[456]

> If a user has JavaScript enabled when they log in, and then disable it, OFBiz won't know about the change - since it is updated
> only during login.

This is user's problem; not OFBiz we can't take care of all subtilities. But we should explain this to users. We could add an
obivous (colored?) label  in the header (javascript enabled). Then they should be aware and it's their responsabilites. BTW I was
surprised that Ryan and you put the access to preferences and languages features in the footer. It's not always visible and seems a
bit weird to me

> As long as users have the option to turn off JavaScript, then there will be the possibility that they will use OFBiz with it
> turned off. The OFBiz framework accommodates that: lookups are turned off and Ajax requests are converted to a page refresh. So,
> OFBiz still works with JavaScript turned off. In addition, the Flat Grey visual theme does not require JavaScript.

Yes that a good point for this theme! But again, not all is now working (as it's still in R10.04, ie stable demo) see OFBIZ-2413 and
the collapse feature for instance. Also you can't use
* the quick access in Product main page  (- Product Jump -), and
* expand all
* no Lookups
* no calendars
I'm almost sure there are more...

Jacques

> -Adrian
>
> --- On Sun, 1/16/11, Jacques Le Roux <[hidden email]> wrote:
>> Actually on the backend we already
>> rely heavily on javascript enabled, try to disabled it when
>> you launch initially with the default
>> theme...
>> That's why I asked this question. Moreover sometimes OFBIz
>> reacts as if javascript was disabled when actually it's not
>> (not sure why
>> yet, but have a look at https://issues.apache.org/jira/browse/OFBIZ-2413)
>>
>> More to the point (your question actually): we could try to
>> create a cookie using javascript at the beginning of the
>> session
>> (LoginWorker.login) and if it's not there we would know
>> that somehow we can't use it.
>> Because I have not digged deep but I can't understant why
>> we use "Y".equals(request.getParameter("JavaScriptEnabled")
>> there and rely
>> on it further. It seems to me that it's not reliable.
>>
>> I think there is more to say about all that. Because if, by
>> a way or another, we know that it's not usable, then we also
>> know that
>> some features are not active (again, for instance
>> OFBIZ-2413) and we should mark them as disabled, which is
>> obviously not done at
>> the moment
>>
>> Jacques
>>
>> From: "Adrian Crum" <[hidden email]>
>> > How do we determine the user's browser setting?
>> >
>> > -Adrian
>> >
>> > --- On Sun, 1/16/11, Jacques Le Roux <[hidden email]>
>> wrote:
>> >> Hi,
>> >>
>> >> What was the intial reason to introduce
>> JavaScriptEnabled?
>> >> Should we not rather rely on the browser setting
>> to set it
>> >> in user prefs?
>> >>
>> >> Thanks
>> >>
>> >> Jacques
>> >>
>> >>
>> >
>> >
>> >
>> >
>>
>>
>>
>
>
>
>

[Jacques Le Roux]

>From: "Jacques Le Roux" <[hidden email]>
> From: "Adrian Crum" <[hidden email]>
>> When the JavaScriptEnabled user setting was introduced, there was no way to determine if the browser had JavaScript enabled. I
>> don't know if that has changed recently.
>
> We can use http://plugins.jquery.com/project/Cookie, it's already embeded in OFBiz.
> 1) We try to create a cookie using it
> 2) We test if the cookie has been just created
> 3) If yes we can use javascript else not
>
>> The only way to test for JavaScript being enabled is to include a small script in the login screen that adds the
>> JavaScriptEnabled
>> parameter to the login form. If the user has JavaScript enabled, then the parameter will be included in the login form, and
>> ultimately in the login request URL.
>
> Yes instead of current "Y".equals(request.getParameter("JavaScriptEnabled") as I suggested below
>
>> I believe the setting is saved in user preferences, so it is persistent during the user's session.
>
> Yes it's is, just under the snippet above, in LoginWorker.login()[456]
>
>> If a user has JavaScript enabled when they log in, and then disable it, OFBiz won't know about the change - since it is updated
>> only during login.
>
> This is user's problem; not OFBiz we can't take care of all subtilities. But we should explain this to users. We could add an
> obivous (colored?) label  in the header (javascript enabled). Then they should be aware and it's their responsabilites. BTW I was
> surprised that Ryan and you put the access to preferences and languages features in the footer. It's not always visible and seems
> a
> bit weird to me
>
>> As long as users have the option to turn off JavaScript, then there will be the possibility that they will use OFBiz with it
>> turned off. The OFBiz framework accommodates that: lookups are turned off and Ajax requests are converted to a page refresh. So,
>> OFBiz still works with JavaScript turned off. In addition, the Flat Grey visual theme does not require JavaScript.
>
> Yes that a good point for this theme! But again, not all is now working (as it's still in R10.04, ie stable demo) see OFBIZ-2413
> and
> the collapse feature for instance. Also you can't use
> * the quick access in Product main page  (- Product Jump -), and
> * expand all
> * no Lookups
> * no calendars
> I'm almost sure there are more...
>
> Jacques

BTW, what I'd suggest at this stage is to warn the user that it will miss a lot of things if javascript is disabled (even if OFBiz
should be still barely usable - not checked, no guarantee...)

Jacque

>> -Adrian
>>
>> --- On Sun, 1/16/11, Jacques Le Roux <[hidden email]> wrote:
>>> Actually on the backend we already
>>> rely heavily on javascript enabled, try to disabled it when
>>> you launch initially with the default
>>> theme...
>>> That's why I asked this question. Moreover sometimes OFBIz
>>> reacts as if javascript was disabled when actually it's not
>>> (not sure why
>>> yet, but have a look at https://issues.apache.org/jira/browse/OFBIZ-2413)
>>>
>>> More to the point (your question actually): we could try to
>>> create a cookie using javascript at the beginning of the
>>> session
>>> (LoginWorker.login) and if it's not there we would know
>>> that somehow we can't use it.
>>> Because I have not digged deep but I can't understant why
>>> we use "Y".equals(request.getParameter("JavaScriptEnabled")
>>> there and rely
>>> on it further. It seems to me that it's not reliable.
>>>
>>> I think there is more to say about all that. Because if, by
>>> a way or another, we know that it's not usable, then we also
>>> know that
>>> some features are not active (again, for instance
>>> OFBIZ-2413) and we should mark them as disabled, which is
>>> obviously not done at
>>> the moment
>>>
>>> Jacques
>>>
>>> From: "Adrian Crum" <[hidden email]>
>>> > How do we determine the user's browser setting?
>>> >
>>> > -Adrian
>>> >
>>> > --- On Sun, 1/16/11, Jacques Le Roux <[hidden email]>
>>> wrote:
>>> >> Hi,
>>> >>
>>> >> What was the intial reason to introduce
>>> JavaScriptEnabled?
>>> >> Should we not rather rely on the browser setting
>>> to set it
>>> >> in user prefs?
>>> >>
>>> >> Thanks
>>> >>
>>> >> Jacques
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>
>>
>>
>>
>
>

[Adrian Crum-2]

--- On Sun, 1/16/11, Jacques Le Roux <[hidden email]> wrote:
> BTW, what I'd suggest at this stage is to warn the user
> that it will miss a lot of things if javascript is disabled
> (even if OFBiz
> should be still barely usable - not checked, no
> guarantee...)

So, OFBiz was barely usable before the JavaScript enhancements were added? ;-)

-Adrian



     

[BJ Freeman]

<SCRIPT TYPE="text/javascript" LANGUAGE="JavaScript">
<!-- Begin
jsver = "1.0";
// End -->

</SCRIPT>
<SCRIPT TYPE="text/javascript" LANGUAGE="JavaScript1.1">
<!-- Begin
jsver = "1.1";
// End -->
</SCRIPT>
<SCRIPT TYPE="text/javascript" LANGUAGE="JavaScript1.2">
<!-- Begin
jsver = "1.2";
// End -->
</SCRIPT>
<SCRIPT TYPE="text/javascript" LANGUAGE="JavaScript1.3">
<!-- Begin
jsver = "1.3";
// End -->
</SCRIPT>


=========================
BJ Freeman
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


Adrian Crum sent the following on 1/16/2011 6:54 AM:

> How do we determine the user's browser setting?
>
> -Adrian
>
> --- On Sun, 1/16/11, Jacques Le Roux<[hidden email]>  wrote:
>> Hi,
>>
>> What was the intial reason to introduce JavaScriptEnabled?
>> Should we not rather rely on the browser setting to set it
>> in user prefs?
>>
>> Thanks
>>
>> Jacques
>>
>>
>
>
>
>

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>

> --- On Sun, 1/16/11, Jacques Le Roux <[hidden email]> wrote:
>> BTW, what I'd suggest at this stage is to warn the user
>> that it will miss a lot of things if javascript is disabled
>> (even if OFBiz
>> should be still barely usable - not checked, no
>> guarantee...)
>
> So, OFBiz was barely usable before the JavaScript enhancements were added? ;-)
>
> -Adrian

You could try with R4.0 without js. I have the feeling that at this moment there were less js dependent features. For the calendar
it was already true, same for the quick access in Product main page and the lookups (which were much much slower when alive), there
were no field groups but the collapsible stuff was working w/out js...

We have a concurrency out there we can't neglict. They also rely/use js, I will be curious to know if they have developed clean
degradable UIs. Is this really worth it for a backend, I don't think so... For a front end that's another story...

Jacques

[Adrian Crum-2]

--- On Sun, 1/16/11, Jacques Le Roux <[hidden email]> wrote:

> From: "Adrian Crum" <[hidden email]>
> > --- On Sun, 1/16/11, Jacques Le Roux <[hidden email]>
> wrote:
> >> BTW, what I'd suggest at this stage is to warn the
> user
> >> that it will miss a lot of things if javascript is
> disabled
> >> (even if OFBiz
> >> should be still barely usable - not checked, no
> >> guarantee...)
> >
> > So, OFBiz was barely usable before the JavaScript
> enhancements were added? ;-)
> >
> > -Adrian
>
> You could try with R4.0 without js. I have the feeling that
> at this moment there were less js dependent features. For
> the calendar it was already true, same for the quick access
> in Product main page and the lookups (which were much much
> slower when alive), there were no field groups but the
> collapsible stuff was working w/out js...
>
> We have a concurrency out there we can't neglict. They also
> rely/use js, I will be curious to know if they have
> developed clean degradable UIs. Is this really worth it for
> a backend, I don't think so... For a front end that's
> another story...

Is what really worth it? Like I said, the framework handles JavaScript/no JavaScript just fine.

I'm also not sure what you mean by it's not worth it for the backend. Not all OFBiz deployments are centered around eCommerce. Don't be so quick to throw the backend under the bus - some service providers depend on that business.

I'm not pushing for disabled-JavaScript support - I'm just saying as long as it's working there is no need to change it. Just because you're having difficulty solving one issue that may or may not have something to with JavaScript doesn't mean we should change things in a way that forces everyone to use it.

-Adrian



     

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>

> --- On Sun, 1/16/11, Jacques Le Roux <[hidden email]> wrote:
>> From: "Adrian Crum" <[hidden email]>
>> > --- On Sun, 1/16/11, Jacques Le Roux <[hidden email]>
>> wrote:
>> >> BTW, what I'd suggest at this stage is to warn the
>> user
>> >> that it will miss a lot of things if javascript is
>> disabled
>> >> (even if OFBiz
>> >> should be still barely usable - not checked, no
>> >> guarantee...)
>> >
>> > So, OFBiz was barely usable before the JavaScript
>> enhancements were added? ;-)
>> >
>> > -Adrian
>>
>> You could try with R4.0 without js. I have the feeling that
>> at this moment there were less js dependent features. For
>> the calendar it was already true, same for the quick access
>> in Product main page and the lookups (which were much much
>> slower when alive), there were no field groups but the
>> collapsible stuff was working w/out js...
>>
>> We have a concurrency out there we can't neglict. They also
>> rely/use js, I will be curious to know if they have
>> developed clean degradable UIs. Is this really worth it for
>> a backend, I don't think so... For a front end that's
>> another story...
>
> Is what really worth it? Like I said, the framework handles JavaScript/no JavaScript just fine.

Try to use the backen without js, you will see the truth I explained above...

> I'm also not sure what you mean by it's not worth it for the backend. Not all OFBiz deployments are centered around eCommerce.
> Don't be so quick to throw the backend under the bus - some service providers depend on that business.

That's not what I mean. What I mean is for a backend you can advice people to have javascript enabled. Even in the SAAS case, it's
not the same audience than eCommerce: you have access to it. I don't mean to neglict graciously degradable UI. But if we want one we
have still a lot of work to do, and I'm not quite sure we can afford it, or rather that the community is not preferring other
choices since it's always choices...

> I'm not pushing for disabled-JavaScript support - I'm just saying as long as it's working there is no need to change it. Just
> because you're having difficulty solving one issue that may or may not have something to with JavaScript doesn't mean we should
> change things in a way that forces everyone to use it.

That's not what I meant. BTW I found the reason it was not working (OFBIZ-2413): I tried to pass JavaScriptEnabled=Y on an URL when
the session was already opened. You have to pass it at the beginning. This is something which is not clear if you don't digg into
this specific login code. And I think we should rather rely on a cookie test like the one I suggested. It sounds logical to me,
would you not agree about that? I find cumbersome to have to pass this parameter when opening a session!

Jacques

> -Adrian
>
>
>
>
>

[Jacques Le Roux]

From: "Jacques Le Roux" <[hidden email]>

> From: "Adrian Crum" <[hidden email]>
>> --- On Sun, 1/16/11, Jacques Le Roux <[hidden email]> wrote:
>>> From: "Adrian Crum" <[hidden email]>
>>> > --- On Sun, 1/16/11, Jacques Le Roux <[hidden email]>
>>> wrote:
>>> >> BTW, what I'd suggest at this stage is to warn the
>>> user
>>> >> that it will miss a lot of things if javascript is
>>> disabled
>>> >> (even if OFBiz
>>> >> should be still barely usable - not checked, no
>>> >> guarantee...)
>>> >
>>> > So, OFBiz was barely usable before the JavaScript
>>> enhancements were added? ;-)
>>> >
>>> > -Adrian
>>>
>>> You could try with R4.0 without js. I have the feeling that
>>> at this moment there were less js dependent features. For
>>> the calendar it was already true, same for the quick access
>>> in Product main page and the lookups (which were much much
>>> slower when alive), there were no field groups but the
>>> collapsible stuff was working w/out js...
>>>
>>> We have a concurrency out there we can't neglict. They also
>>> rely/use js, I will be curious to know if they have
>>> developed clean degradable UIs. Is this really worth it for
>>> a backend, I don't think so... For a front end that's
>>> another story...
>>
>> Is what really worth it? Like I said, the framework handles JavaScript/no JavaScript just fine.
>
> Try to use the backen without js, you will see the truth I explained above...
>
>> I'm also not sure what you mean by it's not worth it for the backend. Not all OFBiz deployments are centered around eCommerce.
>> Don't be so quick to throw the backend under the bus - some service providers depend on that business.
>
> That's not what I mean. What I mean is for a backend you can advice people to have javascript enabled. Even in the SAAS case, it's
> not the same audience than eCommerce: you have access to it. I don't mean to neglict graciously degradable UI. But if we want one
> we have still a lot of work to do, and I'm not quite sure we can afford it, or rather that the community is not preferring other
> choices since it's always choices...
>
>> I'm not pushing for disabled-JavaScript support - I'm just saying as long as it's working there is no need to change it. Just
>> because you're having difficulty solving one issue that may or may not have something to with JavaScript doesn't mean we should
>> change things in a way that forces everyone to use it.
>
> That's not what I meant. BTW I found the reason it was not working (OFBIZ-2413): I tried to pass JavaScriptEnabled=Y on an URL
> when the session was already opened. You have to pass it at the beginning. This is something which is not clear if you don't digg
> into this specific login code. And I think we should rather rely on a cookie test like the one I suggested. It sounds logical to
> me, would you not agree about that? I find cumbersome to have to pass this parameter when opening a session!
>
> Jacques
>
>> -Adrian

Also, with last Hans's change on Catalog main page, if you disable javascript you don't have access to Catalogs/Categories tree.
It's typically a case were we could degrade gracefully (just have to use the old way), but anyway who's care :/

Jacques

[BJ Freeman]

If i remember correctly we were going to have a tree widget.
so I don't see this correct.
more it is what people perceive

what happen to making ofbiz stand out with its own UI.

=========================
BJ Freeman
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


Jacques Le Roux sent the following on 1/16/2011 3:10 PM:
> Also, with last Hans's change on Catalog main page, if you disable
> javascript you don't have access to Catalogs/Categories tree. It's
> typically a case were we could degrade gracefully (just have to use the
> old way), but anyway who's care :/

[Jacques Le Roux]

I'm speaking about http://svn.apache.org/viewvc?rev=1055790&view=rev

You may have a look at https://issues.apache.org/jira/browse/OFBIZ-4120 and especially
https://issues.apache.org/jira/browse/OFBIZ-4124 if you are really interested

Jacques

BJ Freeman wrote:

> If i remember correctly we were going to have a tree widget.
> so I don't see this correct.
> more it is what people perceive
>
> what happen to making ofbiz stand out with its own UI.
>
> =========================
> BJ Freeman
> Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com  <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
>
> Chat  Y! messenger: bjfr33man
>
>
> Jacques Le Roux sent the following on 1/16/2011 3:10 PM:
>> Also, with last Hans's change on Catalog main page, if you disable
>> javascript you don't have access to Catalogs/Categories tree. It's
>> typically a case were we could degrade gracefully (just have to use the
>> old way), but anyway who's care :/

[Jacques Le Roux]

Hi Adrian,

If you are interested I'm filling https://issues.apache.org/jira/browse/OFBIZ-4120

One thing came into my mind: for security reasons we have heavily introduced use of javascript (see
https://issues.apache.org/jira/browse/OFBIZ-2330 and maybe even https://issues.apache.org/jira/browse/OFBIZ-1525) all those cases
are not barely usable w/out js but unusable...

So I wonder now if OFBIZ-4120 has even any sense. We rely on js and OFBIZ-2330 is really showing it!

Jacques

From: "Adrian Crum" <[hidden email]>

> --- On Sun, 1/16/11, Jacques Le Roux <[hidden email]> wrote:
>> BTW, what I'd suggest at this stage is to warn the user
>> that it will miss a lot of things if javascript is disabled
>> (even if OFBiz
>> should be still barely usable - not checked, no
>> guarantee...)
>
> So, OFBiz was barely usable before the JavaScript enhancements were added? ;-)
>
> -Adrian
>
>
>
>
>