Hi Rick,

I am trying to pass a json data object to a CallBackHandler and can't seem to make it happen. Can you please review and tell me what I need to do to hook up and process the object?

Thanks, Craig

The client call looks right, but you're not receiving the result type on the server. Create a parameter on the method with your SubscriberDelete type that should be deserialized into.

[CallbackMethod(...)]
public bool ServerDelete(SubscriberDelete model) 
{
}

Also, you should probably use ajaxJson() which makes the client call easier:

ajaxJson

It's in ww.jquery.js and it defaults to a POST operation:

ajaxJson(url, { id: value, name: "Rick" })
     .then( function(result) {
                 alert("Server result: " + result;
            })
     .error( function(error)  { alert("server request failed:  " + error.message); }

+++ Rick ---

Hi Rick, The CallbackHandler works great for everything except passing JSON objects, I'm still having issues with...

For instance, a simpl

Then a simple JSON post in WebSurge fails.

Can you tell what I have wrong? It seems that I'm only having issues with JSON objects.

Thanks, Craig

Not sure - that all looks right to me. That should work. Not sure about the jquery operation - I think the datatype may have to be something other than JSON but I can't recall offhand. WebSurge however should show accurate info of exactly what goes to the server.

+++ Rick ---

Hi Rick, I honestly can say I have never been able to pass a JSON object to a CallbackHandler method. I also can't find any examples anywhere in any WW applications to use as an example. I will try to Skype call you later for support.

This is the only error message I have been able to gather...

Thanks, Craig

You need to make sure that when posting data to the server that the Content-Type is set to application/json. If you use ajaxJson() that should happen automatically.

I just took a look and tried this out with the MVC Sample in the West Wind Toolkit. Other than having to update all the NuGet packages to the latest versions (without it the JSON libs were out of date) the following works:

Note that without the Content-Type this doesn't work and gets the error you are seeing.

+++ Rick ---

That was it... You're a rock star!

It's always a good idea to use application/json, but I've updated the packages and in the latest release the default is JSON so if no content type is provided, if POST data is present it assumes that the data is JSON.

+++ Rick ---

It's always a good idea to use application/json, but I've updated the packages and in the latest release the default is JSON so if no content type is provided, if POST data is present it assumes that the data is JSON.

+++ Rick ---

"but I've updated the packages and in the latest release the default is JSON so if no content type is provided" This is good news!

Rick, Do you plan on opening a tool kit for .NET CORE?
(Maybe I should start this as a new thread)... Thanks, Craig

I have a lot of libraries on Github. Looks for:

Westwind.AspNetCore

Nothing really all that similar to what you're thinking here I think though, because most of the things (like CallbackHandler) are built-in to ASP.NET Core as Controllers via MVC.

I'm finally getting to the point of building the new Web Store in .NET Core.

+++ Rick ---

Wait What!? "I'm finally getting to the point of building the new Web Store in .NET Core." WOW! This is fabulous news! I hope you post articles and/or notes along the way!

Well you're probably not going to like it - I'm using Postgres and a document store to implement it. A bit different but I feel this is actually a much better fit for a store type application (ie. variable schema for invoices and items for example).

+++ Rick ---

I find it interesting you have chosen to go that route with it for sure...

Do you worry about getting away from SQL Server?
Do you think SQL Server will ever support JSON document storage?
Do you plan on rewriting the Client App as well?

Thanks!

Nope not worried about getting away from SQL Server one bit 😄

1. I'm building this store update for myself to make my life as easy as possible keeping this app running over the years and I think a document database will make this much easier. It also allows much more flexibility for anybody else who wants to use this because the schema is flexible without having to do object mapping. Meaning you can just add fields to the entities and the database will be able to use those new properties.

2. SQL Server already has some support for JSON fields, but it's very, very limited compared to PostGres's support. I'm using a .NET library called Marten which lets you use a LINQ provider over JSON data. The beauty of using Postgres is that you can still use SQL side by side with the document database if needed although I don't see much need for that for the store. Also Marten supports duplicated fields for high access, which basically adds SQL fields that map the document fields. What this means is that you can query these fields either via SQL or via the document syntax (where SQL tends to be faster).

3. No not rewriting the client app. Instead there will be a Web based order/inventory manager that provides that functionality as a SPA app. Angular or Vue, haven't decided which yet - leaning towards Angular since that's what I'm using the most.

To that effect I've built out my business object base class that works similar to how all of my data access Business objects are working with the same API, so the code you write against that looks very similar to the way the current store works, but without all the mucky raw SQL statements and non-LINQ mapping support.

One other thing is that Marten has been hinting that a future version may support SQL Server's JSON engine, but that's likely a few years off.

+++ Rick ---

This is cool stuff! Thanks for taking the time to explain technologies. Craig