MVC Architecture

[Erik]

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]

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?

 

[Kier]

Did you ever considering writing XenForo using Ruby on Rails?

I just did. No.

 

[Erik]

I just did. No.

Any particular reason? Not that I'm advocating RoR, but you sound somewhat vehement.

 

[Kier]

Virtually all domain knowledge for forum software revolves around PHP these days. Using RoR would alienate the entire third-party development community.

 

[Mike]

...never mind deployment, management, efficiency/speed, speed of development (from a PHP background)...

 

[Shadab]

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]

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.

 

[Dean]

Does anyone have links to existing mvc threads on xf? So I could read more?

 

[Shadab]

Does anyone have links to existing mvc threads on xf? So I could read more?

I don't think there are any threads on xf dedicated to MVC. Here are two that are somewhat related, though:

• What's Your Favorite Framework
• Database and Model Implementation

 

[feldon30]

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]

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.

 

[Brandon_R]

I would have to say the HTML and the CSS are the view and the javascript is the controller. There is not model here.

 

[feldon30]

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.

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.

 

[Kier]

I would have to say the HTML and the CSS are the view and the javascript is the controller. There is not model here.

Developers argue ad nauseum about what bit is the model and what is the controller and bla bla. In the end it's unimportant, provided the principles of abstraction and encapsulation are enshrined in the design.