ajaxEnabled inside form widget

[twosolution]

Hi,

how to disabled the ajaxEnabled

i cannot see the ajaxEnabled entries inside the widget-form xsd

and i trace it to htmlFormMacroLibrary.ftl
and it depend to javascriptEnabled

i wonder , Is it the design wise not to include the ajaxEnabled entries
inside widget-form xsd ?

--
Disclaimer : This E-mail is intended only for the use of the individual or
entity named above and may contain information that is confidential. If you
are not the intended recipients, please immediately notify us by return
email and delete it from your system. Any unauthorised dissemination,
distribution or copying of this email is strictly prohibited. Thank You.

[Adrian Crum-3]

Making Ajax optional would be a nice feature to have. Please create a
Jira issue and include a patch if you have one.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 2/26/2014 2:25 AM, Jen Sing Choe wrote:

> Hi,
>
> how to disabled the ajaxEnabled
>
> i cannot see the ajaxEnabled entries inside the widget-form xsd
>
> and i trace it to htmlFormMacroLibrary.ftl
> and it depend to javascriptEnabled
>
> i wonder , Is it the design wise not to include the ajaxEnabled entries
> inside widget-form xsd ?
>

[Jacques Le Roux]

For the moment the only way it works is to directly pass it in the login URL, like in

https://demo-trunk.ofbiz.apache.org/catalog/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
(note we use the same to automatically login people to demos from main page, I mean http://ofbiz.apache.org/)

It can then be also retrieved from session using UtilHttp.isJavaScriptEnabled() (see LoginWorker.doBasicLogin() which sets it)

HTH

Jacques

Le 26/02/2014 14:57, Adrian Crum a écrit :

> Making Ajax optional would be a nice feature to have. Please create a Jira issue and include a patch if you have one.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 2/26/2014 2:25 AM, Jen Sing Choe wrote:
>> Hi,
>>
>> how to disabled the ajaxEnabled
>>
>> i cannot see the ajaxEnabled entries inside the widget-form xsd
>>
>> and i trace it to htmlFormMacroLibrary.ftl
>> and it depend to javascriptEnabled
>>
>> i wonder , Is it the design wise not to include the ajaxEnabled entries
>> inside widget-form xsd ?
>>
>

[twosolution]

Hi,

Please comment.

*Objective*
1. To have ajaxEnabled to be configurable (enabled and/or disabled)
2. To have ajaxEnabled to be configurable independently on each widgets
fields. i.e. lookup, text, dropdown, pagination, etc.

*Finding*
1. i noticed there are lots of implementation uses ajaxEnabled as found
inside htmlTemplate and htmlFormMacroLibrary.ftl
and as well xxxFormMacroLibrary.ftl

2. renderLookupField, renderTextField, renderDropDownField and etc, have
condition checking on ajaxEnabled

3. current implementation tie to ajaxEnabled = javascriptEnabled

*Proposed patching** Option One *
ajaxEnabled to be control by property in widgets.properties
We can assign boolean for each different widget fields
ex.
widget.lookup.ajaxEnabled=N
widget.text.ajaxEnabled=Y
widget.dropdown.ajaxEnabled=Y

And inside htmlFormMacroLibrary -> renderLookupField, renderTextField,
renderDropDownField, etc, retrieve this property

*Proposed patching Option Two*
1. modify the widget-form.xsd to include attribute ajaxEnabled in "lookup"
element
2. then this attribute is retrieved and populated inside
MacroFormRenderer.java and ModelFormField.java
3. and thus is attribute is available inside htmlTemplate.ftl and
htmlFormMacroLibrary.ftl

*Proposed patching Option Three (similar implmentation to javascriptEnabled
as highlighted by Jacques*
1. retrieve ajaxEnabled during login session (LoginWorker)
2. ajaxEnabled to be stored inside UserPref entity (is this needed ?)
3. ajaxEnabled to be stored inside session
4. create a new method to retrieve ajaxEnabled from session
5. retrieve ajaxEnabled from the session inside htmlTemplate.ftl and
htmlFormMacroLibrary.ftl

*Pro and Cons*
Option One and Option Two allow ajaxEnabled to be set individually in
respect to the widget fields.
That is, i may want want dropdown to have ajaxEnabled but i dont want
lookup to have it.

Option Two require changes inside widget-form.xsd file. (good way or bad
way ?)

Option three
Its disabled ajaxEnabled globally, provided each implementation location,
we retrieve the ajaxEnabled from the session and use it.
I am not sure ajaxEnabled works in htmlFormMacroLibrary.ftl -> pagination
-> renderNextPrev
#macro renderNextPrev


*Seeking for advice*
I have created patch for Option One and Option Two and Option Three.
And these patches are only for Lookup widget.

I have one problem for Option Two. I add a new attribute = ajaxEnabled
inside the widget-form.xsd
and point the xsi:noNamespaceSchemaLocation to a local file.
But, the schema validation still throw exception
Message: cvc-complex-type.3.2.2: Attribute 'ajaxEnabled' is not allowed to
appear in element 'lookup'.

And i trace it to UtilXml.java [459] trunk revision 1557427
and method resolveEntity print out the correct xsd location in my local
file directory.
Any advice ?

Thanks
Jen Sing



On Thu, Feb 27, 2014 at 12:02 AM, Jacques Le Roux <
[hidden email]> wrote:

> For the moment the only way it works is to directly pass it in the login
> URL, like in
>
> https://demo-trunk.ofbiz.apache.org/catalog/control/
> main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
> (note we use the same to automatically login people to demos from main
> page, I mean http://ofbiz.apache.org/)
>
> It can then be also retrieved from session using
> UtilHttp.isJavaScriptEnabled() (see LoginWorker.doBasicLogin() which sets
> it)
>
> HTH
>
> Jacques
>
> Le 26/02/2014 14:57, Adrian Crum a écrit :
>
>  Making Ajax optional would be a nice feature to have. Please create a
>> Jira issue and include a patch if you have one.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 2/26/2014 2:25 AM, Jen Sing Choe wrote:
>>
>>> Hi,
>>>
>>> how to disabled the ajaxEnabled
>>>
>>> i cannot see the ajaxEnabled entries inside the widget-form xsd
>>>
>>> and i trace it to htmlFormMacroLibrary.ftl
>>> and it depend to javascriptEnabled
>>>
>>> i wonder , Is it the design wise not to include the ajaxEnabled entries
>>> inside widget-form xsd ?
>>>
>>>
>>

--
Disclaimer : This E-mail is intended only for the use of the individual or
entity named above and may contain information that is confidential. If you
are not the intended recipients, please immediately notify us by return
email and delete it from your system. Any unauthorised dissemination,
distribution or copying of this email is strictly prohibited. Thank You.

[Adrian Crum-3]

I would prefer that we not store user preferences in the HTTP session.
Sometime widgets are used without a session.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 3/1/2014 5:24 AM, Jen Sing Choe wrote:

> Hi,
>
> Please comment.
>
> *Objective*
> 1. To have ajaxEnabled to be configurable (enabled and/or disabled)
> 2. To have ajaxEnabled to be configurable independently on each widgets
> fields. i.e. lookup, text, dropdown, pagination, etc.
>
> *Finding*
> 1. i noticed there are lots of implementation uses ajaxEnabled as found
> inside htmlTemplate and htmlFormMacroLibrary.ftl
> and as well xxxFormMacroLibrary.ftl
>
> 2. renderLookupField, renderTextField, renderDropDownField and etc, have
> condition checking on ajaxEnabled
>
> 3. current implementation tie to ajaxEnabled = javascriptEnabled
>
> *Proposed patching** Option One *
> ajaxEnabled to be control by property in widgets.properties
> We can assign boolean for each different widget fields
> ex.
> widget.lookup.ajaxEnabled=N
> widget.text.ajaxEnabled=Y
> widget.dropdown.ajaxEnabled=Y
>
> And inside htmlFormMacroLibrary -> renderLookupField, renderTextField,
> renderDropDownField, etc, retrieve this property
>
> *Proposed patching Option Two*
> 1. modify the widget-form.xsd to include attribute ajaxEnabled in "lookup"
> element
> 2. then this attribute is retrieved and populated inside
> MacroFormRenderer.java and ModelFormField.java
> 3. and thus is attribute is available inside htmlTemplate.ftl and
> htmlFormMacroLibrary.ftl
>
> *Proposed patching Option Three (similar implmentation to javascriptEnabled
> as highlighted by Jacques*
> 1. retrieve ajaxEnabled during login session (LoginWorker)
> 2. ajaxEnabled to be stored inside UserPref entity (is this needed ?)
> 3. ajaxEnabled to be stored inside session
> 4. create a new method to retrieve ajaxEnabled from session
> 5. retrieve ajaxEnabled from the session inside htmlTemplate.ftl and
> htmlFormMacroLibrary.ftl
>
> *Pro and Cons*
> Option One and Option Two allow ajaxEnabled to be set individually in
> respect to the widget fields.
> That is, i may want want dropdown to have ajaxEnabled but i dont want
> lookup to have it.
>
> Option Two require changes inside widget-form.xsd file. (good way or bad
> way ?)
>
> Option three
> Its disabled ajaxEnabled globally, provided each implementation location,
> we retrieve the ajaxEnabled from the session and use it.
> I am not sure ajaxEnabled works in htmlFormMacroLibrary.ftl -> pagination
> -> renderNextPrev
> #macro renderNextPrev
>
>
> *Seeking for advice*
> I have created patch for Option One and Option Two and Option Three.
> And these patches are only for Lookup widget.
>
> I have one problem for Option Two. I add a new attribute = ajaxEnabled
> inside the widget-form.xsd
> and point the xsi:noNamespaceSchemaLocation to a local file.
> But, the schema validation still throw exception
> Message: cvc-complex-type.3.2.2: Attribute 'ajaxEnabled' is not allowed to
> appear in element 'lookup'.
>
> And i trace it to UtilXml.java [459] trunk revision 1557427
> and method resolveEntity print out the correct xsd location in my local
> file directory.
> Any advice ?
>
> Thanks
> Jen Sing
>
>
>
> On Thu, Feb 27, 2014 at 12:02 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> For the moment the only way it works is to directly pass it in the login
>> URL, like in
>>
>> https://demo-trunk.ofbiz.apache.org/catalog/control/
>> main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
>> (note we use the same to automatically login people to demos from main
>> page, I mean http://ofbiz.apache.org/)
>>
>> It can then be also retrieved from session using
>> UtilHttp.isJavaScriptEnabled() (see LoginWorker.doBasicLogin() which sets
>> it)
>>
>> HTH
>>
>> Jacques
>>
>> Le 26/02/2014 14:57, Adrian Crum a écrit :
>>
>>   Making Ajax optional would be a nice feature to have. Please create a
>>> Jira issue and include a patch if you have one.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 2/26/2014 2:25 AM, Jen Sing Choe wrote:
>>>
>>>> Hi,
>>>>
>>>> how to disabled the ajaxEnabled
>>>>
>>>> i cannot see the ajaxEnabled entries inside the widget-form xsd
>>>>
>>>> and i trace it to htmlFormMacroLibrary.ftl
>>>> and it depend to javascriptEnabled
>>>>
>>>> i wonder , Is it the design wise not to include the ajaxEnabled entries
>>>> inside widget-form xsd ?
>>>>
>>>>
>>>
>

[Pierre Smits]

Given that OFBiz is intended to cater to multi-tenant and
multi-organisation setups the best 'all encompassing' solution would be:


   1. retrieve from UserPreference (and its associated entity
   UserPrefGroupType) the value that the user has chosen to have, with
   failover - when not available  - from;
   2. internal organisation specific setting, with failover - when not
   available - from;
   3. tenant wide setting, with failover - when not available - from
   4. OFBiz implementation wide setting from property file

However, it should be taken into consideration that the internal
organisation(s) and even the tenant might dictate that company wide
policies apply so that users may not be able to set (these kind of)
individual preferences.

Regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

[Jacques Le Roux]

OK at this point, please Jen create a Jira issue and copy (all) the comments from this thread.
It's far easier to follow and read and better for history sake

Thanks

Jacques

Le 01/03/2014 16:59, Pierre Smits a écrit :

> Given that OFBiz is intended to cater to multi-tenant and
> multi-organisation setups the best 'all encompassing' solution would be:
>
>
>     1. retrieve from UserPreference (and its associated entity
>     UserPrefGroupType) the value that the user has chosen to have, with
>     failover - when not available  - from;
>     2. internal organisation specific setting, with failover - when not
>     available - from;
>     3. tenant wide setting, with failover - when not available - from
>     4. OFBiz implementation wide setting from property file
>
> However, it should be taken into consideration that the internal
> organisation(s) and even the tenant might dictate that company wide
> policies apply so that users may not be able to set (these kind of)
> individual preferences.
>
> Regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>

[twosolution]

Hi,
Jira created
https://issues.apache.org/jira/browse/OFBIZ-5554

Thanks
Jen Sing


On Sun, Mar 2, 2014 at 1:06 AM, Jacques Le Roux <
[hidden email]> wrote:

> OK at this point, please Jen create a Jira issue and copy (all) the
> comments from this thread.
> It's far easier to follow and read and better for history sake
>
> Thanks
>
> Jacques
>
> Le 01/03/2014 16:59, Pierre Smits a écrit :
>
>  Given that OFBiz is intended to cater to multi-tenant and
>> multi-organisation setups the best 'all encompassing' solution would be:
>>
>>
>>     1. retrieve from UserPreference (and its associated entity
>>     UserPrefGroupType) the value that the user has chosen to have, with
>>     failover - when not available  - from;
>>     2. internal organisation specific setting, with failover - when not
>>     available - from;
>>     3. tenant wide setting, with failover - when not available - from
>>     4. OFBiz implementation wide setting from property file
>>
>> However, it should be taken into consideration that the internal
>> organisation(s) and even the tenant might dictate that company wide
>> policies apply so that users may not be able to set (these kind of)
>> individual preferences.
>>
>> Regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>>

--
Disclaimer : This E-mail is intended only for the use of the individual or
entity named above and may contain information that is confidential. If you
are not the intended recipients, please immediately notify us by return
email and delete it from your system. Any unauthorised dissemination,
distribution or copying of this email is strictly prohibited. Thank You.

[Jacques Le Roux]

Appreciated, thanks

Jacques

Le 02/03/2014 09:42, Jen Sing Choe a écrit :

> Hi,
> Jira created
> https://issues.apache.org/jira/browse/OFBIZ-5554
>
> Thanks
> Jen Sing
>
>
> On Sun, Mar 2, 2014 at 1:06 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> OK at this point, please Jen create a Jira issue and copy (all) the
>> comments from this thread.
>> It's far easier to follow and read and better for history sake
>>
>> Thanks
>>
>> Jacques
>>
>> Le 01/03/2014 16:59, Pierre Smits a écrit :
>>
>>   Given that OFBiz is intended to cater to multi-tenant and
>>> multi-organisation setups the best 'all encompassing' solution would be:
>>>
>>>
>>>      1. retrieve from UserPreference (and its associated entity
>>>      UserPrefGroupType) the value that the user has chosen to have, with
>>>      failover - when not available  - from;
>>>      2. internal organisation specific setting, with failover - when not
>>>      available - from;
>>>      3. tenant wide setting, with failover - when not available - from
>>>      4. OFBiz implementation wide setting from property file
>>>
>>> However, it should be taken into consideration that the internal
>>> organisation(s) and even the tenant might dictate that company wide
>>> policies apply so that users may not be able to set (these kind of)
>>> individual preferences.
>>>
>>> Regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>>