Keyless in standalone editor

mguinness

This is not a bug per se, but an observation I hope to get some feedback on. I'm using the editor in standalone mode for a details page and I'm not using any of the provided server-side libraries as I'm using ASP.NET Core.

I've read pretty much all the online documentation including standalone. The issue I have is when I invoke the editor using edit with no parameters, the data gets sent with the key as "keyless". To workaround this I modified the data to substitute the correct key.

ajax: {
    url: "/api/Save",
    type: "POST",
    contentType: "application/json",
    data: function (d) {
        d.data[id] = d.data['keyless'];
        delete d.data['keyless'];
        return JSON.stringify(d);
    }
}

Now I understand I need to use data-editor-id attribute as specified in this post and specify the key parameter in edit. That however seems geared towards collections and not necessarily for a single record.

I had a couple of ideas how this could work. Firstly the key could be proved in the idSrc option if table option is not provided. The edit function could lookup fields using data-editor-field selector as they would be singleton.

Secondly the key could be provided as the parameter in edit. This is what I initially assumed would work, but without the data-editor-id attribute it doesn't work. The data-editor-field attributes aren't loaded into the editor dialog which I assume is due to missing container. There is an inconsistency however that when the form is submitted the values do then get saved back to the elements which was unexpected.

I guess this could be seen as a solution in search of problem, i.e. you could use data-editor-id and a parameter in edit but that seems collection orientated - I don't see why a container is required for a single item edit where fields could be in separate areas of a page. Anyway I thought the feedback might be useful and maybe the documentation needs to be a little clearer for this particular instance which I would assume is a pretty common scenario.

allan

Secondly the key could be provided as the parameter in edit. This is what I initially assumed would work, but without the data-editor-id attribute it doesn't work.

This is what should actually happen already. Using something like editor.edit( 5 ); should replace the keyless with 5 (in that case - it doesn't matter what you pass in - it should replace the string).

I've just put a little example of that together. With edit(5) it does indeed send the 5 as the identifier (not sure why I'm picking on 5 today!). If you remove that 5 it will send keyless.

Are you able to modify that example or give me a link to a page that shows the issue?

Thanks,
Allan

mguinness

Thanks for the reply and example Allan. Yes the correct key is sent, but the initial values aren't populated in the dialog. If you change edit(5) to edit() they will.

The data-editor-field attributes aren't loaded into the editor dialog which I assume is due to missing container. There is an inconsistency however that when the form is submitted the values do then get saved back to the elements which was unexpected.

mguinness

Allan, can you confirm that the form values aren't being populated in the dialog from the example that you provided?

allan

Sorry - I completely missed that. yes you are correct. What's happening there is that Editor is actually looking for a collection id (data-editor-id) of 5, not finding it and therefore not being able to load in the data to be edited.

Perhaps it should check to see if there is a data-editor-id attribute on the page at all - if not then it can just fall back to load any values it can find...

Allan

allan

Just been talking this through with @colin - we think that if edit() is given an id that doesn't exist, it should actually throw an error (since you might have a collection editor and passing in an invalid id could cause data corruption since it would be loaded with random data).

That error throw needs a change in Editor, which I've logged to add.

For this use case, can you add data-editor-id as an attribute to an element on your page - even using it on the body would allow it to work?

Thanks,
Allan

mguinness

Thanks for your reply Allan. I did add the data-editor-id to body (albeit using JQuery as the body element is in a layout template). Then it worked as expected, treated like a single item collection. It's a little kludgy but it works.

Is it at all possible to programmatically set id? I'm guessing not, but I wanted to confirm.

If not, would it be possible to add a function type to idSrc? I was thinking that if provided id and data parameters you could override the current id by returning a custom id within the function.

This would also solve another problem that I've encountered, namely sending a compound key when attached to a DataTable. Right now, it's either a property name or array index. What I want to do is send a compound key made up of 2 fields, i.e. path and name. I can't do this currently unless I'm missing something.

So from the client-side aspect (i.e. JS+CSS only) it was actually always able to support compound keys - its all about how the server handles it the new support.

I wasn't able to figure out how to do that, unless that meant tweaking ajax.data (as shown in my original posting). I look forward to any comments that you may have.

allan

Is it at all possible to programmatically set id? I'm guessing not, but I wanted to confirm.

Correct - adding data-editor-id to the document using jQuery is as close as that would get at the moment.

Right now, it's either a property name or array index. What I want to do is send a compound key made up of 2 fields, i.e. path and name. I can't do this currently unless I'm missing something.

On the client-side there is no concept of a compound key as such - there is a single id (since it is assigned to a DOM id). The way compound keys work in Editor is that the server-side will combine the values of the two (or more) columns into a single value when sending to the client-side. Then when the client-side sends data back, the server will split that data apart again.

For example consider a column which has primary key values of "1" and "5" - you could send "1-5" to the server and then when the key is send back, split on - to get the two values. The Editor libraries basically do that (although they use a hash rather than a simple delimiter to avoid situations where the server-side script has changes and the client-side hasn't been reloaded - an error is thrown in that case).

Allan

mguinness

Thanks for clarifying Allan. Maybe sometime in the future a function type for idSrc will be added so I can do the concatenation client side rather than server side.