Possible bug in v1/files endpoint?

[Carlo Didier]

This code

Code Select Expand

$('#btn-from-files').click(function() {
    IMatch.get('v1/files',{
        idlist: IMatch.idlist.fileWindowSelection,
        fields: 'id,filename,name,folder,folderid'
    }).then(function(response) {
        console.log(JSON.stringify(response));
        console.log(JSON.stringify(response.files));
        console.log(JSON.stringify(response.files[0]));
        console.log(JSON.stringify(response.files[0].filename));

        ....
    },
    function(error){
        console.log(JSON.stringify(error));
    });
});

returns this result:

{"files":[{"id":105722,"folderId":2909,"folder":"D:\\Photos\\Photos Carlo\\2017\\11\\2017-11-19 Landscapes\\","name":"D20171119008.dng","fileName":"D:\\Photos\\Photos Carlo\\2017\\11\\2017-11-19 Landscapes\\D20171119008.dng"},{"id":105723,"folderId":2909,"folder":"D:\\Photos\\Photos Carlo\\2017\\11\\2017-11-19 Landscapes\\","name":"D20171119009.dng","fileName":"D:\\Photos\\Photos Carlo\\2017\\11\\2017-11-19 Landscapes\\D20171119009.dng"}],"hiddenByStacks":0}
index.html (208,9)
[{"id":105722,"folderId":2909,"folder":"D:\\Photos\\Photos Carlo\\2017\\11\\2017-11-19 Landscapes\\","name":"D20171119008.dng","fileName":"D:\\Photos\\Photos Carlo\\2017\\11\\2017-11-19 Landscapes\\D20171119008.dng"},{"id":105723,"folderId":2909,"folder":"D:\\Photos\\Photos Carlo\\2017\\11\\2017-11-19 Landscapes\\","name":"D20171119009.dng","fileName":"D:\\Photos\\Photos Carlo\\2017\\11\\2017-11-19 Landscapes\\D20171119009.dng"}]
index.html (209,9)
{"id":105722,"folderId":2909,"folder":"D:\\Photos\\Photos Carlo\\2017\\11\\2017-11-19 Landscapes\\","name":"D20171119008.dng","fileName":"D:\\Photos\\Photos Carlo\\2017\\11\\2017-11-19 Landscapes\\D20171119008.dng"}
index.html (210,9)
undefined
index.html (211,9)

The field "filename" seems to exist until line 210

Code Select Expand

console.log(JSON.stringify(response.files[0]));
but in the next line

Code Select Expand

console.log(JSON.stringify(response.files[0].filename));
it is undefined ?

What's happening here?
Note that I can output any of the other fields. Just not "filename" ...

[thrinn]

JSON.stringify is for converting JSON data to strings. filename is not a JSON object but already a string. Maybe JSON.stringify  gets confused because of the ":" contained in the path?

[Carlo Didier]

JSON.stringify is for converting JSON data to strings. filename is not a JSON object but already a string. Maybe JSON.stringify  gets confused because of the ":" contained in the path?

No.

Code Select Expand

console.log(response.files[0].filename);
returns undefined too. Same for the "folderid" field ...

[thrinn]

Ah, case  error. The property is fileName, not filename.

[Mario]

All IMatch endpoints take parameters in lower-case, to make it easier to produce URLs with tools like curl and similar.
Returned JSON data uses the standard camelCase syntax.

[Carlo Didier]

All IMatch endpoints take parameters in lower-case, to make it easier to produce URLs with tools like curl and similar.
Returned JSON data uses the standard camelCase syntax.

And once again, the infinite stupidity of case-sensitiveness
In the IMatch webservices documentation, all fieldnames are all-lowercase. So I need to specify the field here in lowercase:

Code Select Expand

    IMatch.get('v1/files',{
        idlist: IMatch.idlist.fileWindowSelection,
        fields: 'id,filename,name,folder,folderid'


But then to use the same field, I have to use camelCase?
Why in hell should the exact same thing be referenced once in all-lowercase and another time in camelCase? ? ? ? ?

I ask for a field named "filename" and get a field named "fileName".
So, here "filename" and "fileName" stand for the same thing, but can't be interchanged depending on the use. And in other cases, "filename" and "fileName" stand for two different things ...
Infinite st... see above ...

[Mario]

But then to use the same field, I have to use camelCase?
Why in hell should the exact same thing be referenced once in all-lowercase and another time in camelCase? ? ? ? ?

My design decision.

a) The WebService processes URLs case-sensitive.
b) JSON is JavaScript Object Notation and using camelCase is the accepted standard to name objects and variables. You'll find that everywhere.

Just take it as it is.

[Carlo Didier]

Just take it as it is.

I'll have to. But still, it's either a bug (the call doesn't return what I ask for) or a grave inconsistency caused by case-sensitivity. Simply put: without that stupid useless case-sensitivity there would be neither bug/problem, nor inconsistency.

Maybe you could add a warning in the doc somewhere about this, because it's not really self-evident, intuitive or logical (hell no!).

I know,

a) The WebService processes URLs case-sensitive.
b) JSON is JavaScript Object Notation and using camelCase is the accepted standard to name objects and variables. You'll find that everywhere.

but if I ask for "filename" and try to use "filename" and it doesn't work, I don't immediately think about the above points.

I think you should, for consistency, have at least used the same notation for the Webservice. But it's too late for that now.

[Mario]

I have. It's all documented:



https://www.photools.com/dev-center/doc/imatch/tutorial-recipes.html

[Carlo Didier]

Yes. But a real example would make the consequences of this clear.
I read that too at some point, thought once again just thought stupid case-sensitivity and moved on. But I didn't realize what it meant in practice (inconsistent use of field names).
It just sounds like with certain calls I'd get results with properties named in camelCase, but not that if I'd specifically request fields in all-lowercase, I would nonetheless get results with field names in camelCase.

Insert just one clear example like this:

WARNING: be aware that the same field will need different writing whether it is used in a call to a webservice endpoint to specify the fields to be returned and in the returned result!
Example:

IMatch.get('v1/files',{
        idlist: IMatch.idlist.fileWindowSelection,
        fields: 'id,filename'      // all lowercase!
    }).then(function(response) {
        console.log(response.files[0]);
    });

will return these fields:

{
  "id": 16360,
  "fileName": "D:\\some_path\\some_file.jpg"     // camelCase!
}

And it should also be clearly mentioned right at the top of the IMatch WebServices Documentation app.

Remember that your users do generally not have years of experience in javascript, web services, etc and clarifying such things like above would save them and you a lot of time and anger.

[Mario]

I doubt that this will support anything.
Most programmers are fully aware of case-sensitiveness in modern programming languages.

[Jingo]

Remember that your users do generally not have years of experience in javascript, web services, etc and clarifying such things like above would save them and you a lot of time and anger.

Very true.. but I really feel you need to learn the language basics before trying to program in modern languages....  I spent over a month learning the ins/out of basic JS, AJAX and Bootstrap BEFORE trying to program anything for IMatch... it taught me a lot of the concepts you are having trouble with (or don't like) such as proper case, asynch calls, CSS usage, etc.  It wasn't until I was sure I understood these ideas before I tried to learn the IM endpoints and constructs and it helped me greatly.... I could then concentrate on the specifics to IMatch knowing I had the basics of the programming language (which is universal to Javascript - not something Mario wrote).  I still had lots of troubles.. often spending an hour or more trying to figure out why something simple was working (and yes - camel case did get me once or twice as well) - but each time I learned something knew and put it to good use down the road.  It's all part of learning a new programming language... Ruby is different from Perl which is different than PHP...  just like VB was vastly different than C#.

I would highly recommend anyone wishing to code apps for IM take a step back and engage in the language basics (and even moderate concepts) before just diving in...  modern languages are very different than VB, Pascal and other legacy coding.

Just my 2 cents.... 

[Mario]

Just my 2 cents.... 

Very true!

I link to some good resources in the sidebar at https://www.photools.com/developer-center/
and there are thousands of tutorials on all JS, HTML, CSS and other modern technologies on the net and YouTube.

[thrinn]

Just my 2 cents.... 

Andy, I fully agree with you. And JS is still being extended and developed, other than VBA where there is not much change anymore. E.g. await/async are language constructs I was not familiar with.

[Carlo Didier]

I really feel you need to learn the language basics before trying to program in modern languages....  I spent over a month learning the ins/out of basic JS, AJAX and Bootstrap BEFORE trying to program anything for IMatch... it taught me a lot of the concepts you are having trouble with (or don't like) such as proper case, asynch calls, CSS usage, etc.  ...
I would highly recommend anyone wishing to code apps for IM take a step back and engage in the language basics (and even moderate concepts) before just diving in...  modern languages are very different than VB, Pascal and other legacy coding.

Just my 2 cents.... 

But I don't want to spend months to re-implement something that took me 1-2 days (including learning the "basics") in the old IMatch.
I don't really need a user interface for my apps. I don't need webservices and asynchronicity. I don't need AJAX or bootstrap.

Because what I want to script is very simple and linear. It's like having to manage a whole Formula 1 stable to get a hightech F1 car running ... to drive 5 miles to the grocery to get your milk.
The tools provided are just inedequate to the task I have. And the price, in time spent, is just astronomically high compared to the task.

[Mario]

I can only repeat myself. Use VB.NET or curl or Python or PowerShell or any other language you know.
Nobody forces you to use JavaScript or to write an app if you don't need one.

This is all very time consuming, not only for you but also for other user and me who try to help you.

[Jingo]

I really feel you need to learn the language basics before trying to program in modern languages....  I spent over a month learning the ins/out of basic JS, AJAX and Bootstrap BEFORE trying to program anything for IMatch... it taught me a lot of the concepts you are having trouble with (or don't like) such as proper case, asynch calls, CSS usage, etc.  ...
I would highly recommend anyone wishing to code apps for IM take a step back and engage in the language basics (and even moderate concepts) before just diving in...  modern languages are very different than VB, Pascal and other legacy coding.

Just my 2 cents.... 

But I don't want to spend months to re-implement something that took me 1-2 days (including learning the "basics") in the old IMatch.
I don't really need a user interface for my apps. I don't need webservices and asynchronicity. I don't need AJAX or bootstrap.

Because what I want to script is very simple and linear. It's like having to manage a whole Formula 1 stable to get a hightech F1 car running ... to drive 5 miles to the grocery to get your milk.
The tools provided are just inedequate to the task I have. And the price, in time spent, is just astronomically high compared to the task.

If you don't like the drive to get there - best to just take a taxi?  There are lots of folks in the community who would love to program your apps for you... I being one of them.