• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

MVC Architecture

Erik

Well-known member
#1
HTML/CSS/JavaScript is essentially a model-view-controller architecture if you think about it.
HTML = model
CSS = view
JS = controller
:)

Edit: this was a split thread FYI. I did not create a thread solely to explain that HTML/CSS/JavaScript is similar to MVC. :)
 

Erik

Well-known member
#2
Much thanks for the links Andy, especially the video.

I was going to commission a custom mysql database program, think I'll hold off a bit longer. :)
Interesting, noted for future reading/watching.

If Kier is reading this:
Did you ever considering writing XenForo using Ruby on Rails? :)
 

Shadab

Well-known member
#7
HTML/CSS/JavaScript is essentially a model-view-controller architecture if you think about it.
HTML = model, CSS = view, JS = controller :)
Actually no. The HTML, CSS and JS together just play a small part in how you go representing a View in an MVC application. If the view is represented in html (as opposed to rss and json):
  • (x)HTML is the actual markup
  • CSS defines the presentation of the view
  • JS defines the behavior of the view
Correct me if I'm wrong, please. :)
 

Erik

Well-known member
#8
Actually no. The HTML, CSS and JS together just play a small part in how you go representing a View in an MVC application. If the view is represented in html (as opposed to rss and json):
  • (x)HTML is the actual markup
  • CSS defines the presentation of the view
  • JS defines the behavior of the view
Correct me if I'm wrong, please. :)
You are correct when thinking about it in the scope of a web application, yes (all the HTML, CSS, and JS are the output to the browser, and thus the view).

But what I meant is that the DOM is in itself somewhat of an MVC model. The HTML is the model and contains the data. The CSS is the view in that it presents that data and controls what it looks like. The JS is the controller in that it controls and manipulates the HTML (the model), and can change the CSS to affect the view. It's probably not MVC by strict terms, but it fits with the general idea. :)
 

feldon30

Well-known member
#11
Ok, how about an example of something that is certainly NOT MVC...

A function called DisplayUserProfile which uses SQL calls to retrieve some info from the database, formats that data, cleans up the spacing, calls the template or templates, and finally outputs the user profile.

This really hurts your flexibility and prevents developers from writing powerful plugins because they must try to jump in the middle of your displaying the profile, and interfere with the HTML that would normally be output.


An MVC way to do it is:

  • You have a function which *retrieves* the user profile from the database, and prepares the information. This function has no idea how the data will be formatted or displayed.
  • You have a function which takes that information and formats it to be displayed. This function has no idea how the data is stored (MySQL, PostgreSQL, XML, RSS), or what device will display that data (iphone, web browser, XML feed, RSS feed).
  • You have a function which displays the final template. This function has no idea how the data was stored, or how it was formatted.
This sounds overly complex, but by doing this, third party plugins can completely change how user profiles are retrieved, stored, formatted, and displayed, by extending all of those functions. Not just profile fields, but really ANY type of information or functionality you would want to marry to the user record.

This is why I'm so excited about Style Properties. Look at the Notices feature in vBulletin. Great idea, but limited by the design. We couldn't really extend what triggered it, how the data was formatted and displayed, and we couldn't add a SQL query or other data retrieval.
 

Kier

XenForo Developer
Staff member
#12
feldon30, you forgot an important component there, right at the beginning of your 'MVC way', which is that you also need a function that interprets a user request, and passes it on to your data retrieval function. Your data retrieval function doesn't know or care how it's been requested.
 

feldon30

Well-known member
#14
feldon30, you forgot an important component there, right at the beginning of your 'MVC way', which is that you also need a function that interprets a user request, and passes it on to your data retrieval function. Your data retrieval function doesn't know or care how it's been requested.
Indeed. And based on what data you are sharing with that user, or what permissions that user has, will significantly affect how much data is exposed.

No doubt, I still have a lot to learn. ;)

Brandon_R said:
I would have to say the HTML and the CSS are the view and the javascript is the controller. There is not model here.
I believe the attempts to fit HTML, CSS, and JavaScript into MVC are not something which originated with Kier or Mike. There are some parallels, I believe first and foremost, MVC as described here applies to the PHP code. If the JavaScript were really the controller, then a ton of information which is never displayed would be pushed to the browser and then filtered out by Javascript or CSS. Not a good setup.