Script# Update and Addition to Projects List

Dear Nikhil

first of all accept my congratulations for coming up such wonderful thing.I have two queries.

1)is Script# bound to aSp.net only?
2)how tightly is it integrated with VS IDE?

Thanks

Nikhil,

Amazing stuff you're producing - even though you say it's a hobby kind of thing, the first release got quality stamped all over it. Even the 22 page PDF documentation looks better than some stuff you have to pay lotsa $$$$ for :)

Keep up the wonderful work - I'm just about to test the new version.

/Johan

Dear Nikhil, your Script# is a very great project. I know that the class library sscorlib is not complete, but can you please add Microsoft Atlas classes. So it will be possible to create classes that derive from e.g. Sys.UI.Behavior class to create own behaviour.
Thanks

Thanks again Nikhil - trememdous work - I look forward to seeing more from you - you make things look easier than they are :)

Hello Nikhil,

Is 10 min video at http://www.nikhilk.net/Content/Video/ScriptSharpIntro.wmv still available? I am getting "Page cannot be found" error.

I would like to see Script# along with WPF/E help me in creating a cross platform/browser RIA. Developers like me using C# for web applications will definitely have productivity gain but it would be interesting to see how these technologies evolves and compares with Macromedia Flex in building RIA.

Thanks

Script# is great... Thank you.

Paketim
http://www.paketim.com

Wow,.. did you ever sleep at all ?

I'm having some problems installing and getting the latest bits to work properly. I followed the documentation but section 2.4 on installation is a bit unclear, especially the second part about the Script# directory.

I got the templates installed and that, but when I compile the sample project it complains about type string existing twice:

Error 39 The type 'string' exists in both 'c:\WINNT\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll' and 'c:\WINNT\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\site\08866bdd\41f60ccd\assembly\dl3\d88bd4f5\00ac010b_2087c601\sscorlib.DLL' C:\Program Files\nStuff\ScriptSharp\v0.1.1.0\Samples\Site\Hello.ashx 18 34 C:\...\Site\

Hey Nikhil,

On this weekend I tried to port some of my Virtual Address Book code to Script# and here are the bugs that I found and some suggestions:

First of all, one of the most critical bugs: DOMElement does not have a RemoveChild method. Current workaround: Type.InvokeMethod( parentElement, "removeChild", childElement ). Although addition of this method to this class would suffice, a more elegant solution can be infered from my comment below.

Second of all, I have a few comments on the general structure of your DOM classes. I noticed that neither you nor GWT implement the W3C standard fully/correctly. In your case, I do understand that this whole project was developed by you alone on your own free time, but implementing the W3C DOM correctly (at least a subset of the DOM Core specifications) in the next versions of the compiler would be of a very great benefit to us, developers. For example, addition of such interfaces as Node and Element, as well as proper implementation of their relationships with your existing Classes, such as Document (which should implement a Node interface), DocumentFragment (also should implement a Node interface) and DOMElement (which probably should be replaced by an Element interface which implements a Node interface) would simplify and streamline how Script# interacts with the DOM. To understand how difficult it currently is to interface with the DOM capabilities of most browsers from Script#, consider the following scenario that I had to go through during my experimentation:

All I needed was a documentFragment object to which I could add/remove Nodes. First of all, I tried the following:

Document myDocFrag = Document.CreateDocumentFragment();

The problem with this was that the Document class did not implement the Node interface described in W3C standard. This meant that I have no access to methods such as AppendChild and RemoveChild. "Why not cast to a DOMElement?" would be the next logical step. That's what I tried next:

DOMElement myDomElement = (DOMElement)Document.CreateDocumentFragment();

The problem with this code is that the C# compiler does not allow the cast to happen (and it's a good thing that it doesn't allow this because a Document is not a DOMElement logically, it should be a Node). So after some frustration, I got away with this ugly hack:

DOMElement myDomElement = (DOMElement)Script.Eval("document.createDocumentFragment()");

As you can see, interfacing with native/standard DOM APIs implemented by most modern browsers is a real pain in the .<insert body part of your liking here>...

Although I would like to help I can't simply because the source to the compiler is closed (and yes, I could write add-on Interfaces with meta-data and use them instead but this would just defy the purpose of having the existing classes in the System namespace, which would get included with each of your applications anyway).

Thanks again for giving us this tool. Now if we could collectively make it better, I couldn't be happier.

Hey Nikhil,

I agree that finding the greatest common denominator of APIs amongst different browsers is not an easy task. I guess it all depends on whether you are trying to create a framework that would hide / iron out browser differences from developer's view or a framework that would give the developer support for most of the browsers' APIs and leave the browser compatibility coding up to him/her or a framework capable of both, low level support and high level abstraction. Most probably, the best way to start about this would be to add support for DOM Level 1 as you mentioned and then grow support for browser specific quirks on top of that (I think that basing a DOM framework on a standard would be the best way to guarantee compatibility with future versions of browsers and DOM specifications). As for DOM API references for browsers, I found this page useful for Mozilla development: http://mozref.com/reference/ . I'm sure Microsoft's knowledge base has a similar page for IE.

Wow Nikhil, such a wonerful information you have provided.

Script# is great. Thanks alot.

Great Work!
I was wondering how difficult would it be to convert Atlas into dummy class library for use in Script#. That will definitely make it easier for many folks to play around with Atlas.

Hi Nikhil

Nice work you have uploaded on your site. It really feels great to see that.

Thnx for that information that I have been looking in from a long time.

Keep up the good work buddy!!