Hi Jean-François,
so you suggest using RPC to circumvent takeValuesFromRequest and invokeAction
triggered by the AjaxSubmitButton?
> Am 20.01.2017 um 14:46 schrieb Jean-François Veillette
> <jean_francois_veille...@yahoo.ca>:
>
> Thinking about it …
> It seems the problem partly come from having a repetition or some kind or a
> form of sequential access to your textfield bindings.
> Maybe you could avoid that by pointing directly to it by means of RPC? So
> use an AjaxProxy object, that talk to your server-side controller object,
> this object most likely have direct access to the object/attribute you are
> referring without having to go through the loop or some kind of sequential
> access.
>
> So you would most likely have to write a JS object that will take care of
> validations on your page, responsible for communicating (RPC) with server and
> validating values. Place the AjaxProxy object early in the components tree
> so that it would be found quickly (not nested inside a loop, or at least
> found early in a loop).
>
> just some thought,
>
> jfv
>
>
>> On Jan 19, 2017, at 10:32, René Bock <b...@salient-doremus.de> wrote:
>>
>> Hi list,
>>
>> In our framework, we are using partial ajax requests to validate input field
>> as soon as the user leaves the text field.
>>
>> In a very complex form, we noticed that the response time of the partial
>> requests depends on the position of the input field. The validation logic is
>> encapsulated in InputFieldComponent, and the form component is mainly a
>> WORepetition of these InputFieldComponents.
>>
>> The range of the measured response times is something between 60 ms for the
>> first component and 1200 ms for the last component in the form. The
>> longest response time is about the same as I would do a normal form submit.
>>
>>
>> Did anybody noticed a similar phenomena?
>>
>>
>> Anyway, my questions are:
>>
>> 1. Why does the position of a field make a difference at all?
>> 2. Is there a possibility to speed up things?
>>
>>
>> Here my observations:
>>
>> A profiling session reveals, that a lot of time is spent in
>> takeFormValuesFromRequest and invokeAction.
>>
>>
>> Answer for #1: As soon as ajaxSubmitButton which triggered the request is
>> found, invokeAction is somehow "interrupted". (see
>> ERXAjaxContext.wasFormSubmitted...)
>>
>>
>> As it is possible to eliminate unnecessary component tree traversal after
>> the right ajaxSubmitButton.action is found, it should also be possible to
>> ignore the other irrelevant childComponents.
>>
>>
>> ASSUMPTION:
>> a) for partial submits, we get only one form value (i.e the
>> partialFormSenderID).
>> b) the partialFormSenderID is the path of the sender component in the
>> overall component hierarchy.
>>
>> IDEA: for the component hierarchy tree traversal, we may ignore child
>> components not on the path to the partialFormSender.
>>
>>
>> Solution (proof of concept) for #2: In ERXWORepetition, I changed
>> takeFormValuesFromRequest and invokeAction as follows:
>>
>>
>> public void takeValuesFromRequest(WORequest worequest, WOContext wocontext) {
>> WOComponent wocomponent = wocontext.component();
>> String partialFormSenderID =
>> ERXAjaxApplication.partialFormSenderID(worequest);
>>
>> Context context = createContext(wocomponent);
>>
>> int count = _count(context, wocomponent);
>> boolean checkHashCodes = checkHashCodes(wocomponent);
>>
>> for (int index = 0; index < count; index++) {
>> _prepareForIterationWithIndex(context, index, wocontext, wocomponent,
>> checkHashCodes);
>> if(partialFormSenderID == null ||
>> partialFormSenderID.startsWith(wocontext.elementID())) { // NO RECURSION if
>> component[index] does not match senderID
>> super.takeValuesFromRequest(worequest, wocontext);
>> }
>> }
>> if (count > 0) {
>> _cleanupAfterIteration(count, wocontext, wocomponent);
>> }
>> }
>>
>> invokeAction is patched in similar way.
>>
>> The result is, that the ajax request at the bottom of the page takes now 60
>> ms instead of 1200ms :-)
>> Unfortunately, this is not a general solution. There are scenarios, there
>> invokeAction will not invoke any actions at all :-(
>>
>> Has anybody an idea for a general solution? Maybe a completely different
>> approach?
>>
>>
>>
>> Best regards (and sorry for this long post)
>>
>>
>> René Bock
>>
>> --
>> Phone: +49 69 650096 18
>>
>> salient GmbH, Lindleystraße 12, 60314 Frankfurt
>> Main: +49 69 65 00 96 0 | http://www.salient-doremus.de |
>> http://www.openforms.de
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/jean_francois_veillette%40yahoo.ca
>>
>> This email sent to jean_francois_veille...@yahoo.ca
>
Mit freundlichen Grüßen
René Bock
--
Telefon: +49 69 650096 18
salient GmbH, Lindleystraße 12, 60314 Frankfurt
Telefon Zentrale: 069 / 65 00 96 - 0 | www.salient-doremus.de
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
