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 <
[email protected]> 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.

Reply via email to