Getting Started with XenForo/MVC Frameworks

[James]

OK so I know basic-intermediate PHP. I know functions, I know variables, I know arrays, I know classes.. blah blah.

Where can I get started with creating add-ons for XenForo? I've got my XF locally set up via Zend Studio on my localhost, but I want to start tearing it apart.

The problem I have is that I'm not used to MVC frameworks, I have no idea what's meant to be in a model, a view or a controller and the only definition I could give is a Google'd one.

Any ideas on where I can get started, hopefully with some reference to XenForo?

 

[Tigratrus]

OK so I know basic-intermediate PHP. I know functions, I know variables, I know arrays, I know classes.. blah blah.

Where can I get started with creating add-ons for XenForo? I've got my XF locally set up via Zend Studio on my localhost, but I want to start tearing it apart.

The problem I have is that I'm not used to MVC frameworks, I have no idea what's meant to be in a model, a view or a controller and the only definition I could give is a Google'd one.

Any ideas on where I can get started, hopefully with some reference to XenForo?

Likewise. Really interested in any info anyone can provide along these lines.

I've got most everything setup on my localhost, though I'm just starting to dabble with Zend/Eclipse. I'm really liking Coda as an alternative to Dreamweaver though.

 

[Ajaxboy]

Model view controller, separates presentation from design and from the coding.. for example.. model is the dealings with database... and such.. view has to do with the templates.. and controllers are the handlers of actions/pages etc. Hope this definition makes it easier to understand.

 

[rEd86]

I'm in the same boat. Experienced programmer that's new to the MVC model and wanting to get up to speed quickly so I can create some hard-core plugins so xenForo can replace our existing platform that's over 8 years old and showing its age. (forums would be a new feature we would introduce)

--Ed

 

[Paul B]

Isn't this thread of any use?

http://xenforo.com/community/threads/creating-an-addon.5416/

 

[Kier]

Most of the threads in the Official Development Tutorials and Resources forum have useful snippets of information that all go together to make a good reference for anyone starting down the add-on path.

 

[Mikey]

for what it's worth, this really helped me understand the basic MVC principles: http://book.cakephp.org/view/890/Understanding-Model-View-Controller

 

[Kier]

It's worth noting that MVC is not a hard-and-fast-set-in-stone approach when it comes to web application development. If you ask different people, they will give you different answers for what components belong in the model and which in the controller or the view. XenForo opts for a 'skinny controller' approach, where our controllers are very simple and push most of the work off to the model as it can be easier to reuse code like that.

 

[James]

So if MVC is interpreted differently depending on the project, how does XenForo approach it?

What does XenForo store in the model, view and controllers?

 

[rEd86]

It's worth noting that MVC is not a hard-and-fast-set-in-stone approach when it comes to web application development. If you ask different people, they will give you different answers for what components belong in the model and which in the controller or the view. XenForo opts for a 'skinny controller' approach, where our controllers are very simple and push most of the work off to the model as it can be easier to reuse code like that.

That was the reason I asked about the XenForo approach to MVC in my tutorial request. I don't want to stray too far from the way the team here is approaching it so my plugins are aligned with the direction of future releases. (and other plugins)

I was looking for a way to get up to speed quickly but it looks like good old fashion trial and error is going to be the best way to cut my teeth!

--Ed

 

[James]

Controller

The Controller manages the user requests (received as HTTP GET or POST requests when the user clicks on GUI elements to perform actions). Its main function is to call and coordinate the necessary resources/objects needed to perform the user action. Usually the controller will call the appropriate model for the task and then selects the proper view.
Model

The Model is the data and the rules applying to that data, which represent concepts that the application manages. In any software system, everything is modeled as data that we handle in a certain way. What is a user, a message or a book for an application? Only data that must be handled according to specific rules (date can not be in the future, e-mail must have a specific format, name cannot be more than x characters long, etc).
The model gives the controller a data representation of whatever the user requested (a message, a list of books, a photo album, etc). This data model will be the same no matter how we may want to present it to the user, that’s why we can choose any available view to render it.
The model contains the most important part of our application logic, the logic that applies to the problem we are dealing with (a forum, a shop, a bank, etc). The controller contains a more internal-organizational logic for the application itself (more like housekeeping).
View

The View provides different ways to present the data received from the model. They may be templates where that data is filled. There may be several different views and the controller has to decide which one to use.
A web application is usually composed of a set of controllers, models and views. The controller may be structured as a main controller that receives all requests and calls specific controllers that handles actions for each case.

(Source: http://net.tutsplus.com/tutorials/other/mvc-for-noobs/)
Would it be accurate to say XenForo uses the same structures?

 

[Tigratrus]

For what it's worth, I'm getting some use out of David Powers' "PHP Object-Oriented Solutions". Not terribly far into it yet, but so far I'm liking his writing style and his focus on using actual code usage to explain concepts rather then getting bogged down in the typical car/fruit/etc analogies when discussing OOP concepts. I've always hated tech books that get so far afield with their attempts to make an explanation "accesible" that their analogy gets heavily in the way of understanding the actual concepts.

Anyway, I remember most of the OOP basics from years ago when I was working with Delphi II and III, but it's proving to be a good refresher as I bring myself back up to speed before diving into Xenframework/ZendFramework.

 

[Nasr]

A simplified explanation...

Model:


Your model class mainly handles fetching of data; usually from the database. So this is where all your hand crafted SELECT queries would be placed. Performing an sql query from anywhere else (for example, from a controller class or heaven forbid, a view class) is a bad idea.

DataWriter:


As the name suggests, a DW is responsible for manipulating data. ie, it would handle insertion, updation and deletion of data from the database. One thing you'd notice is a datawriter handles one row at a time. So unlike your Model from which you can select a bunch of rows in one go; a datawriter can manipulate a single row of data, only.

Using a datawriter to manipulate data has an added benefit of maintaining integrity of your data.

Event Listeners:


Whenever you set up a code event listener via the Admin Panel, you have to specify a "callback" method which would be executed when your selected event occurs. This callback method can be placed in ANY class of your choice. Most devs choose to place these methods in a "Listener.php" file, to make it obvious to the reader. But it's not a requirement. I place such methods in an "Addon.php" file, along with the installer code, as I find it easier to manage that way.

Maybe this might be of help in some way.

 

[ninja-9]

Here is a simplified explanation that I found on the net:

http://php-html.net/tutorials/model-view-controller-in-php/

Check-it one-time!

In the comments, there is discussion on the distinction between business logic and application logic... hmmm... very good stuff!