Editor Version issue: editor fields not populate
Editor Version issue: editor fields not populate
Hello,
We have an issue regarding differences between versions of editor. ( version 1.3.1 vs 1.5.4 )
In both versions, we have these javascript event listeners, that I believe you made for us:
$('select', editor.node('orders.id_customer')).on('change', function () {
editor.field('orders.id_customer_location').update(
getCustomerLocationsCascading( editor, editor.get('orders.id_customer') )
);
} );
$('select', editor.node('orders.id_customer_location')).on('change', function () {
editor.field('orders.id_customer_location_part').update(
getCustomerPartNumbersCascading( editor, editor.get('orders.id_customer_location') )
);
} );
$('select', editor.node('orders.id_customer_location_part')).on('change', function () {
var res=getInternalPartNumberToMatch( editor, editor.get('orders.id_customer_location_part') )
editor.set('orders.id_part', res[0].label);
editor.set('part_master.part_number', res[0].value);
} );
Each of the functions brings back JSON data that populates a select field.
Please see link:< removed link and access > Click on Orders tab, then Order Entry.
Select a row, click edit. The customer, location, and customer part no is populated correctly. Cancel that editor and select a different row of a different customer and click edit. The location and part num are not populated, even though the json data comes back from our function correctly.
We have ported this back to 1.3.1 and it works correctly.
Another issue, probably related, is when we are displaying the web console, we see the PHP function files called several times when running this code in editor 1.5.4, but when running on editor 1.3.1, the PHP function files are only called once per edit.
This question has accepted answers - jump to:
Answers
Hi,
Thanks for posting this. I realise this will be a little frustrating, but I don't have an immediate answer for you. I've just been looking at debugging this and the issue is caused by the new behaviour in the latest Editor which itself was designed to resolve a different issue with async loading of select fields. That works well for two fields which are async, but you have three fields which are loaded synchronously where it doesn't appear to work well at all.
Let me look into this in more detail and get back to you - although it will probably be next week I'm afraid.
Allan
I've removed the access, please let me know ( post here ) if you need the access info again.
Thanks.
Hi Allan,
Wondering if you have anything for us, or a date to look forward to yet? We are nearing go-live and this is one of our remaining issues.
Thanks for you help.
I'm afraid I'm having some issues with pinning down the best way to do this. Unfortunately I don't yet have a fix for how to resolve it.
Allan
Allan, we need a resolution to this issue. If we need to re-code some parts ( cascading dropdowns ) to match your new code, let us know.
I'm sorry I don't have an answer for this yet - it is proving to be really quite difficult I'm afraid. I'm hopeful of being able to resolve it next week all being well though.
Allan
I've been trying to recreate this issue with Editor 1.5.5 and haven't been able to do so. I've put an example up here: http://live.datatables.net/tegirofo/1/edit .
The example uses
dependent()
to do the cascading drop downs. I've uses a local function with asetTimeout
to emulate the async behaviour of Ajax. The timeout is 500mS which is really high, so the interface can look slow, but it is useful to demonstrate exactly what is happening.First question - does the example work okay for you.
Second question - if you aren't able to link to a page showing the issue you are having, can you modify my example above to demonstrate the issue so I can resolve it.
Thanks,
Allan
Just wondering if you've had a chance to look at my example?
Allan
Regarding the example, yes, it does work for us on your site. To further diagnose, we moved the code to localhost, using editor 1.5.4 and your code worked as expected.
We are thinking that it may be that we use ajax to fill our objects with returned data, whereas your example uses static data from the DOM.
I am sending you email to gain access to the demo site, plus ftp access to the demo site.
Super - thanks for sending me the link. That allowed me to discover what the issue is.
Basically the problem comes down to the placeholder (
---
label and empty sting value) that you have for each of the select lists.What is happening is that after the options are updated Editor will attempt to use the currently selected value as the value to show in the new list. If it can't find that value, then it will use the old value. In your case the current value is an empty string (since the original couldn't be found!) and thus the empty string option is selected in the new options list.
What I've done is to rework how Editor handles this situation so it will only attempt to set a value that was set via the API or by the end user (i.e. not the default selected value if there is no matching value in the list).
I've just updated Editor on your site (now at 1.5.6-dev) and this appears to work well.
Thanks for your help tracking this down.
Regards,
Allan
p.s. Your Ajax requests are impressively quick - 100mS :-)
Excellent Allan, thanks so much.
Thanks for the feedback and confirming it works for you. This fix will be in the 1.5.6 release which I expect to be in early April.
Regards,
Allan