Will you be publishing the source code for the project you used in the screencast? I would love to have a deeper look at it.

Thanks Andrew

Hi Andrew,

Thanks for the screencast and code; I've been taking a close look. The one thing I don't understand (I'm somewhat new to MVP) is why you send the model data back and forth? The app seems to work identically while transmitting far less data when I modify Equin.Modelbase.Async as follows:

//Dictionary args2 = new Dictionary("model", model);
Dictionary args2 = new Dictionary("model", new Dictionary()); // null threw an error

Maybe it's just the nature of the example you chose.

Thoughts?
Hugh Lynch

Thanks for the reply.

It is definitely nice to be able to pass a compatible model back and forth, but passing the whole model with each call seems ungainly. Is the client supposed to re-render the full model after each call? Or compute a delta from its previous copy?

I wonder how hard it would be to use a checkpoint and delta design, where the client sends a delta (addItem("foo")) and a version indicator for the model (an int or timestamp). The server compares the version with its own, decides whether to apply the delta and returns an error or a list of deltas for the client to apply along with a new version indicator. In the normal case, the version would just increment and the list would contain just the delta sent. This typical response could be shortened to OK.

Regards,

really like what you are doing here...
The only thing that confuses me a little is
the whole support built in for passing the model around.
Since both javascript (client) and .net (server) are
capable of parsing xml (or json) documents and fragments,
why the extra effort? Is it a script# limitation
that you are trying to go around?

Hey,

i really like what you have doen here. Gotta say that first.

But, i spent a week using the .net framewrk 3.5 and it has something simialr backed in with Ajaz.
Basically, you can take a SOAP Web Service, but expose it as a JSON service by just a declaritive attribute.
So its reflection based at runtime.
It also is able to generate the Model from the c# model as a Javascript object structure.
And it genertaed the proxy.
All this is reflection based and at runtime.
Bad points about it:
1. Its reflection based and not software factory based, so the comile time erros dont show.
2. Its slow because its reflection based.

Also, the first thing i thought of when i saw what you are trying to do was an i cant believe i am suggesting this is "DaatSets". Yes the old clunky containers fro years ago,. The thing about the Data Set was that it had the Difffram concept that basically allowed the Model to know that a line item had changed, and only send the change. You could hold the DataSet in the server session and then just do the old "DataSet.Merge()" in c# to merge in any changes.

Again, i am not suggesting this is a solution, but more cluching at straws of ideas that might help you.

Also, you probably know about Ext#. They too are using Script# to genertae javascript from c#.

And of course there is MonoRail in the Castle project.


Really like what you are doing here. Few people seem to really think about the mismatch that exists today, and if solved its a big big win. Please keep going on this. I want a framework to do this :)

And Nicky open source Script :) mate ...

Thanks for this learning !

Cool, the post.

Thanks for the information.