Wow this is a long question.
First, I recommend that you look at the "Metadata by hand" topic which describes a much simpler way to define your metadata ... using the Breeze Labs metadata helper. That will cut down a lot of the tedium and make it much clearer to read and understand.
Second, do NOT specify "jsonResultsAdapter" in your metadata. It looks to me like your pinning your metadata to the WebAPI adapter when, in fact, you want to use a different one. Do NOT specify the "namingConvention" in your metadata either as that will trump whatever you set elsewhere. And given that you are not getting metadata from the server, "hasServerMetadata" should be false
if you bother to set it at all (which you shouldn't).
Third, stick to the client-side name and forget about "nameOnServer". The NamingConvention
is going to crush that anyway.
Fourth, if (as it appears) the client-side and server-side property names are BOTH camelCase DO NOT change the NamingConvention
default! You don't want any translation. The default does no translation.
If I'm correct about that, do NOT change the NamingConvention
to camelCase! The "camelCase" convention tells Breeze "the server is PascalCase so translate my client-side camel case property names into Pascal names on the server". If I understand correctly, you don't want client-side "id" to become server-side "Id" ... which is what will happen. That's why (I believe) you are seeing "Id" as the "nameOnServer".
Fifth, within a JsonResultsAdapter
, the node names match the JSON from your server and, therefore, are server-side names. Keep them that way. The NamingConvention will convert them to client-side names when it translates node property values to entity property values. In fact, you'll lose data if you mistakenly use client-side names on the nodes.
Do you have some need to mutate property names and values in the JSON as it arrives from the server? If not, don't mess with those names in your visitNode
method. About all you'll need to do is make sure that you identify the correct EntityType
for the node and return that in the result.
Sixth, I'm pretty sure the "entityType" property of the visitNode
result must be an actual EntityType
, NOT the name of the type as you have shown in your example. You can't say
return {
entityType: 'tracks',
};
You have to give it the real type (I'm pretty sure)
return {
entityType: trackType,
};
Look at the other Breeze adapters (e.g., the Web API adapter). It gets the EntityType
from the MetadataStore
.
Seventh Why are you setting the "nodeId"? I'm not saying you're wrong to do so. But you should know why. The "nodeId" is used to help reconstruct an object graph when the same entity appears multiple times in the payload. It is only useful when accompanied by a "nodeRefId" in some other node which points to a "nodeId" value. At this point, where you only have one kind of entity and not relationships, setting the "nodeId" isn't accomplishing anything. Later it will ... but only if you're setting it with a value that makes sense.
What I think you're doing is setting the "nodeId" to the primary key value of Track
. Isn't that what node.id
is in your case? If I'm right, don't do that. The "nodeId" is NOT the PK of your entity. It is a marker for serializing entity graphs with cycles.
Wow mine is a long answer
I fear you are a bit over your head here. Writing a dataService adapter or a jsonResultsAdapter is not a Breeze beginner task. If you're going to go there, please study the existing adapters and follow them meticulously. Know why they do what they do rather than wing it.
I hope I've provided a few clues here.
I suspect it is much simpler than you're making it. Some key thoughts:
Make sure you aren't changing the
NamingConvention
unless you really do need to change the spelling of property names from client-to-server.Set the "entityType" in your JsonResultsAdapter to an
EntityType
, not the name of the type.Don't rewrite breeze functions like
rawValueFn
; you'll break Breeze and you won't know how or why.