Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>A little late to the party, but I've got $0.02 here that I'm not sure what to do with...</p> <p>Forgetting about (typical) Web-MVC (ie: RailsMVC, et cetera) for a second:</p> <p>Consider that JavaScript can all be resident in the same place, and that you don't have to worry about figuring out routing and class-instantiating (unless you really want to).</p> <p>Ideally, from a software point of view, what you want MVC to do is to separate what the user does, from what makes up the content (based on the action), from what makes up the view (based on the action).</p> <p>There's nothing saying that you can't have multiple views, or even that you can't have a view which contains multiple views (which might use templates, or be functionally generated, and attached to a DOM-node - either is valid).</p> <p>In a simple pseudo-example, rather than having a flow that looks like:</p> <p>Action Loads Controller -> Controller Loads Model -> Controller Queries Model -> Model Answers Controller -> Controller Loads View -> Controller Feeds Data to View -> View Sends Page to Controller -> Controller Outputs Page</p> <p>Why not something like:</p> <p>Controller Listens for Action (addEventListener) -> Controller Turns Action into State-Logic -> Controller Notifies Model (observer) OR Model Polls Controller -> Model Changes State based on Logic, and Collects / Sorts all Data -> Model Notifies View (observer) OR View Polls Model -> View Changes State based on Logic -> View Renders all Components, based on Data + ViewState (innerHTML OR documentFragment).</p> <p>It looks a little longer, but in reality, everything is nice and separate. With the View (or View Manager or however you want to think of it) dictating what windows are on the page, and how each window is made up, and where the data goes, inside of each article, in each window...</p> <p>...now you have an MVC pattern, but you ALSO have the ability to say:</p> <pre><code>View["mainpage"] = { data : { tweets : [{id:...}...]/* et cetera - pushed by Model, not Controller */ }, layout : [ "Header", "Carousel", "Articles", "TwitterFeed", "RSSFeed", "Footer" ], // if your system is this clean, you could even prototype the content-builders // rather than defining them in each ViewState - you'd just need layout, then buildPage : function () { var page = document.createDocumentFragment(); for (/* everything in this.layout */) { View.build[this.layout[i]](this.data, page); } document.body.appendChild(page); }, cleanUp : function () { /* fancy or simple DOM cleaning for state-change */ }, // grabs SubView by expected handle (id="tweetfeed" or whatever) and replaces it // observer functionality, for views to automatically update as data changes updateView : function (view, newData) { ... }, addData : function (data) { this.data = data; }, // for Observer /* Observer - if you want to run the WHOLE site with AJAX from index.html * clean up old (ex:"main") page and build and/or transition new (ex:"media") page * could be unique for each page, for custom transitions, or just prototype it */ changeState : function (newState, newData) { View["mainpage"].cleanUp(); View[newState].addData( newData ); View[newState].buildPage(); } } </code></pre> <p>And now you've defined your whole main-page. Of course, it's going to be extra work maintaining not only definitions for your main page, but for every page/section. ...and then, you need to make the functions which will create each sub-view -- but component-based design is EXACTLY what you were asking about. In essence, for each widget, it will have its own building-logic. That's what views do - they either have an individual template that gets reused, or they have a function that works the same way every time.</p> <p>And an atomic view is one where you're dealing with a function that builds 1 item (1 Tweet, 1 Post, 1 Store item) and builds the view for that. Having a Single_Tweet view post a single-tweet to the page, 20 times in a row would be a <strong>bad</strong> idea for JS performance.</p> <p>But having a Single_Tweet view push tweets, in order, into a Tweets array that your Twitter_Feed view puts on the site is A-OK.</p> <p>Even better is when your Pages are Views, made up of Widgets of Views, made up of Atomic-Units of Views. And when all of that happens off-DOM (so innerHTML or documentFragment).</p> <p>And the best would be a Framework where you define pages in this way, but you can also update an individual Widget, based on data-pushes from the Model, whenever you want.</p> <p>And that's the beauty of AJAX -- old-fashioned MVC can happen, without a Controller that knows everything.</p> <p>The Controller just holds a list of pressed-keys, the mouse coordinates, a clicked button's intent... And it tells the Model that something happened. The Model does everything state/data/data-manipulation (sorting) related, and feeds the new state or data to the view, which takes it all and puts it into HTML, in the order you specify.</p> <p>That's about it.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload