Development platform pickle.

[SeaSharp]

I am trying to develop my server-side code as a self-hosted C# WCF console application. This has been tested directly with URLs and the correct JSON responses are generated. However I don't think a self-hosted wcf application can serve up the static content since it is not a general purpose web server.

So I had a brainwave but this has failed. I configured IIS to listen on port "2020" and access my site as "http://mydomain:2020/testSite. This successfully renders the static welcome portion of my Ext application.

The problem is, on my first Ext request to fetch data...


proxy: new Ext.data.HttpProxy({url: 'http://mydomain/wcfService/GridPageQuery'}),
I see the following error in the Firebug console:

I see

[jay@moduscreate.com]

When you've got a pickle, make some http://www.bevnet.com/images/reviews/picklejuice/picklejuice-bottle.jpg
:P

[devnull]

have the iis instance communicate with the wfc app. then the ext app only talks with iis, which talks to the wfc app when needed.

[SeaSharp]

Why is server-side Ext application development so problematic in the Microsoft world?

Plan 1: I want a server-side framework that includes zero elements of Microsoft thinking e.g. aspx style page design, view-state and all that gumph. So I expected to use AjaxPro.Net as the intermediary for all interaction between Ext and C# server-side code. Outcome: Abandoned because I wish to use LINQ to SQL in Net 3.5 but AjaxPro will not compile in VS2008 due to depreciated functions. The author is not progressing the AjaxPro project.

Plan 2: Jump straight in with the latest and greatest WCF platform. Run the WCF service as separate application but need to use different ports to serve up static content from IIS. Trouble is different ports trigger cross domain script alerts so need to use an Ext Script proxy.

Unfortunately WCF takes charge of the whole JSON serialization process and I cannot find a way to persuade WCF to wrap the output JSON into the supplied JavaScript callback wrapping statement.

Plan 3: Just use WCF for inbound parameter packaging and inbound JSON to C# object serialization. Then generate my own JSON reply strings and manually wrap inside the Callback JS statement. So the return type of all my WCF service functions would be a String.

Failed. WCF still inspects the returned string which it considers to be a single object. So it automatically escapes double quotes inside my JSON string thereby screwing up things.

Plan 4: Host the WCF service inside IIS, and so allow static and dynamic content to be served from a common domain. Therefore WCF generated JSON could be returned direct to Ext without a callback wrapper. Failed: Got lost in configuration problems and security issues. From a browser I could not invoke a hello world WCF function. Googling this problem I am beginning to think that the WCF concept is going to drown in configuration hassles, this feels like J2EE 5 years on!

Plan 5: My current position as of this posting. Resort back to humble .aspx pages. Manually pluck POST parameters out of the request, query the DB, generate JSON and return directly. It feels so 1998 to have to create a separate .aspx page for each type of interaction between a Web2.0 client and Microsoft server.

[devnull]

Its been my experience that microsoft builds "solutions" that work best (or at all) only with other microsoft products and ways of thinking. So its more of microsoft's lack of open box thinking than it is with everyone else (Such as Ext) using accepted standards.
If it helps any, i use php for my backend, and typically have a single handler script for each "module" in my app. each ajax request supplies an "action" param which the handler runs a switch on to choose the right code to run. any responses are inserted into an abject, which gets encoded to json at the end.
I dont see the point of any sort of server-side "framework" since all it would be doing is handling the conversion to/from json. and with 99+% of the code logic happening on the client side, there shouldnt be enough code on the server side to even want the added complexity of frameworks anyway. my handlers are really just database connectors with some of the client side security validation duplicated (since client side security cant be relied upon) :)

[SeaSharp]

Good news, Plan 3 is back on the road.

Following some help from MS Support in the Indigo (WCF) forum I now have a solution to returning my own JSON string without the WCF plumbing trying to "help" by escaping all the double quotes in my JSON.

Here is a code snippet if others head down the WCF route.


public MemoryStream GridPageQuery(..)
{
var gridData = new GridPageData();

// query database and fill row collection in gridData

var jsonSerializer = new JavaScriptSerializer();
var sb = new StringBuilder();
sb.Append("stcCallback1001(");
jsonSerializer.Serialize( gridData , sb );
sb.Append( ");" );
var ms = new MemoryStream(Encoding.Default.GetBytes( sb.ToString() ));
return ms;
}
..

Technical Points:

1 - The main block of json gen-stream code will be wrapped in a utility function.
2 - I know "stcCallback1001" should not be hard coded.
3 - JavaScriptSerializer is a depreciated class but MS guru Scott Guthrie is on a mission to keep it in the framework.
4 - Yup that is C# code, those var's are a new language feature.

[JChung]

Why use var instead of the actual type name? var is required for anonymous types but for types with names, aren't you sacrificing the advantage of strong type checking by using the compiler's type inferencing rather than stating the type explicitly?

[SeaSharp]

Why use var instead of the actual type name? var is required for anonymous types but for types with names, aren't you sacrificing the advantage of strong type checking by using the compiler's type inferencing rather than stating the type explicitly?
That is what I thought when first reading up on the new .Net 3.5 language features but actually there is no loss of strong typing. The compiler throws an error on the following code:


var i = 2;
i = "string";

[Fade]

"var" is needed only where a concrete type cannot be decided.

in ur code:
var jsonSerializer = new JavaScriptSerializer();
var sb = new StringBuilder();

obviously you have misused this feature.

[SeaSharp]

obviously you have misused this feature.
Using either syntactic option will lead to the same compiled output and compiler messages.

I know which I prefer.


Dictionary<string, Form> formCache= new Dictionary<string, Form>();

// Once is now enough:

var formCache= new Dictionary<string, Form>();