views:

84

answers:

3

do you think it would be difficult to write a framework where mvc compares last html it output to the current html we want to output, and instead of sending the entire html, figure out what has changed and generate js code that will do the updating as compared to previous html? (presuming nothing was manually changed on the client using js)... maybe an idea for a codeplex project? or maybe something like this exists? if so, do tell. thanks.

A: 

Have you considered caching? E.g. Caching in asp.net-mvc

Will be more straightforward and it makes more sense to me too.

o.k.w
thats missing the point, together with the low-bandwidth efficiency, you can update any part of the html without issue. currenlty you can't do this in mvc ajax unless you nail the server with as many calls as you have regions of updating needed. the questions still remains. read my other post for more on this if you want
Erx_VB.NExT.Coder
if worked, we'd never need to use js again (for the most part/for most users) and can write proper mvc apps in mvc only. at the moment i am using jquery to do everything because of mvc's lackings. this defeates the purpose of mvc, seperating view logic from business logic, its just not elegant code, and too many hacks to get things done right.
Erx_VB.NExT.Coder
This is not a short coming of MVC, it's how HTTP and browsers work. JavaScript is absolutely necessary if you only want update a portion of the page.
Justin Johnson
@Erx_VB.NExT.Coder: Pardon me if I didn't understood your question. I'm just offering an opinion which unfortunately is 'missing the point'. I'll still leave the answer here as the comments are worth a read or two.
o.k.w
@okw: thank you for the added suggestion
Erx_VB.NExT.Coder
@justin: the shortcomming of mvc is you can't update multiple parts of the page unleess you hammer out multi ajax requests hittign the server unnecessarily, or loading the entire view... with webforms you could do this with one call and one return. the thing i suggested is an option that would provide benefit, for people who do not want to use javascript to use mvc, making mvc a proper, fully contained framework! there are plenty of people that hate writing js/jquery to write a proper app!
Erx_VB.NExT.Coder
@Erx I think you're failing to realize that this is not possible with current technology. What you are suggesting is equivalent to AJAX, except that AJAX doesn't have the misplaced notion of generating JavaScript on the fly to alter the current page. Also, the shortcoming of MVC is that it's not entirely suitable for stateless applications. I'm sorry if people hate writing JavaScript. If that's the case, they should get out of web.
Justin Johnson
@justin: why do you think my suggestion is a misplaced notion? how is it not possible? you cache/save the last html sent, based on what user does in his mvc controllers etc to their views, and how their views change, whatever change there is, mvc can generate the js to make that change on the client instead of sending everything again. you have cached-like bandwidth saving while still having everythign dynamic and updatable. best of both. its perfect. i cant see how it is not possible as a side feature, NOT a replacement of course.
Erx_VB.NExT.Coder
also think of the benefits of seperation of concerns, code abstraction, all the main arguments for mvc. having to write half ur business and display logic on the client and not being able to do it all on the server is just plain poor, the ideal is to have all your logic in one place, the server, and let the framework figure out the js that needs to be written based on what you do on the server.
Erx_VB.NExT.Coder
The point is that all that can be done with AJAX, *in one request.* What you're suggesting is not possible with current browser technology. You're essentially proposing that the browser magically handle your AJAX behavior for you. I agree that there are better ways to display and update content, but we're stuck with HTTP, HTML and the browser idiom.
Justin Johnson
well, im jsut proposing that a server side class write the js to update the html on the client for me, so i dont have to write the js... thats all... this way all my code logic exists on the server.
Erx_VB.NExT.Coder
also, the code generating the js would be on the server of course, and it may not make sense in every request, but the server can decide when to send back js and when to send back the updated html. im just curious to know, as i think i might be missing something, why it is that this would not be practical or useful? of course, client code will still be needed for client only interactions and when client doesn't want to go to the server... but at least, when u go to the server, you wont need client code for the response.
Erx_VB.NExT.Coder
A: 

You would need to save the state of any client at your server, and no response could be cached anywhere because every client needs a different response.

Even if this is possible, it would make no sense in the "HTTP world" imho.

Karsten
@karsten: output caching wouldn't be needed! however the output cache could just save the base page html. then all returned items (where it makes sense to do so) would just return javascript which instructs the client on how to change the html to update the current display.i won't need to use javascript to update my html all the time, smaller amount of data being sent (js to do the updating), don't you think it'd be an option worth having? im thinking maybe i suck at explaining... because i would kill for this.
Erx_VB.NExT.Coder
Sounds like using javascript to update small parts of your page via AJAX to me. You will need javascript for any kind of non-standard-request anyways.
Karsten
@karsten: yes thats right, BUT the difference is the mvc framework would be generating the javascript, so you do not have to do anything on that front!!! get me?
Erx_VB.NExT.Coder
I get what you want to do, but I see no advantage over partial AJAX requests. Your MVC Framework does process AJAX requests, right?
Karsten
Erx_VB.NExT.Coder
also, with output caching, you have the bandwidth savings at the cost of not being able to update your html - not entirely comparable. where as here you have the best of both worlds. maybe im not seeing something and getting overly excited about nothing? i just can't see what it is i might not be seeing tho :) cuz i would so love this feature :)
Erx_VB.NExT.Coder
why would every client need a different response? javascript is the same (almost always) everywhere on all clients. and the client request will go back with an id so that the server knows which one its dealing with. so it would make every bit of sense in the http world. this is why im really thinking i've been unable to explain something central to what im thinking.
Erx_VB.NExT.Coder
A: 

[deleted deleted deleted ]

Erx_VB.NExT.Coder