I'm more with Ryan as well. In my latest project, I've split my REST-like web services from my services that just show my views. My web views don't come preloaded with any data. They only contain an extremely limited html mark up and they import all of the javascript and css files I need to be functional. I guess you could almost view them as a javascript interpretation of an IoC container. My web views are then populated using a javascript templating language with the data being pulled from my REST-like web service via jQuery.
Doing things this way means that my pages are actually loaded in three distinct phases: 1. Load web view which declares all javascript and CSS dependencies that it intends to show. 2. Once the page loads I call the REST-like web services on the server to get the data I want to show 3. Once the data gets to my client my templating framework pulls the appropriate template file from my server and renders it with the data. It's a little chatty but I figure I can use caching where necessary and right now I have no traffic. The flexibility and modularity of this approach has been key for this approach. I needed to work out a way to create a bunch of web views where the user experience isn't baked and where I could mix and match the different views of my data at will. This is also SUPER testable. I can test my REST web services using ruby's unit testing with Rack/Sinatra (which is most of the complication of projects like this). The template logic is testable in w/e javascript unit testing framework I'm using... (I'm not testing them... but I've been experimenting with TDD and how far to push not TDD-ing)... and the actual web views... quite honestly I just test them manually because they have never caused any pain by being untested. I'm just getting ready to fit the site into a pre-made web design template and I have no concerns that what I've done will be the least bit difficult to fit into any given mould. On Sat, Jan 22, 2011 at 7:10 PM, Paul McCallick <[email protected]> wrote: > That's an interesting take on it, Ryan. You almost have to builld two > layers of mvc - one on the client which is traditional ui style mvc, > and one on the server side which is web style mvc. > > Mike, in old school mvc the view has no real logic in it and doing > validations at that layer would be considered very bad form. In fact, > the view never does anything on its own. It tells the controller what > the user did, and if there is a resulting update to be made in the > view, the controller will tell the view to do it. In the web world > this would result in lots of round trips. > > > > On Jan 22, 2011, at 5:03 PM, Ryan Riley <[email protected]> > wrote: > > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[email protected]] On Behalf Of Paul McCallick > >> Sent: Saturday, January 22, 2011 2:27 PM > >> To: [email protected] > >> Subject: The reality of web mvc > >> > >> I've been thinking about how most web apps these days do some serious > >> JavaScript backflips, and how that sort of violates the mvc pattern. > >> With all of that magic happening at the view layer, you're sort of > >> forced to make some processing decisions that never hit the contr > >> > >> Thoughts, strategies?l > > > > The problem stems from the fact that MVC is a UI pattern, and web apps > are > > services delivering messages, not UI. A true MVC platform would be all > > JavaScript. MVC just so happens to very closely match the > resource-oriented > > nature of the web so that it makes it difficult to catch the slight > > mismatch. > > > > So what you really need to do is segregate your service (web app) from > your > > UI (JavaScript). Then you'll see the clean divisions and be able to do > some > > MVC with JavaScript. Check out Sammy.js, among others. > > > > Ryan > > > > -- > > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > [email protected]<altnetseattle%[email protected]> > . > > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Seattle area Alt.Net" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<altnetseattle%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/altnetseattle?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
