How to learn - From someone who's learning

Marc

Well-known member
Thought I would put up this topic as I thought it would be good for others to read that are in the same situation as myself who is currently learning how to create addons for xenforo.

My Background
  1. I am a developer by trade, however not something I have been doing for years and I only code windows based .NET applications with no experience in web development.
  2. I know the basics of PHP programming, although I do need to keep learning this to become more proficient at both writing and reading code.
  3. I understand object oriented programming.
  4. I have never before created an addon for any forum software at all.

So as some already know I have been trying to code an addon for mapping members, and here are the things I have learnt that I hope will help others in the same situation. Baring in mind I am still doing these things.

  1. TAKE THE TIME to set up an IDE to work in and get a local installation of xenforo set up. This is well worth the effort as it helps when trying to find out what is available in different parts of the framework.
  2. READ TUTORIALS ON HERE - There is a lot of information on xenforo that is invaluable. Look at some of the "How to's" and follow them. Do them for yourself. It will make you feel more comfortable with it besides anything else.
  3. READ THE CODE FIRST - When extending classes etc, read the code you are extending from so you understand what it is doing. I was told only yesterday by ragtek to learn to read, and this has to be the best piece of advice I have yet received.
  4. TRY TO FIGURE IT OUT - Always try to figure out what you have done wrong before asking the question.
  5. DOWNLOAD ADDONS - Download other peoples addons that achieve similar things when you are getting stuck, and look at how they have done it. For example I found how to extend the datawriter correctly by looking through the scratchpad demo by Kier.
  6. ENSURE YOU UNDERSTAND - This is something I have been guilty of in the past couple of weeks. When you do something that you have seen done elsewhere, try to understand WHY you are doing it and how that works. This way when you have problems they are easier for you to debug and fix.

Feel free to add to this.
 
  1. DOWNLOAD ADDONS - Download other peoples addons that achieve similar things when you are getting stuck, and look at how they have done it. For example I found how to extend the datawriter correctly by looking through the scratchpad demo by Kier.
  2. ENSURE YOU UNDERSTAND - This is something I have been guilty of in the past couple of weeks. When you do something that you have seen done elsewhere, try to understand WHY you are doing it and how that works. This way when you have problems they are easier for you to debug and fix.
There's IMHO a small problem.

If somebody who have not really a clue makes a add-on, an somebody else with no clue checks this, he learns it false.
For example: Models should ALWAYS be instanced with the create factory, instead of creating a new object with the new operator.

There were some add-ons, which didn't do this and other people copied them...
 
There's IMHO a small problem.

If somebody who have not really a clue makes a add-on, an somebody else with no clue checks this, he learns it false.
For example: Models should ALWAYS be instanced with the create factory, instead of creating a new object with the new operator.

There were some add-ons, which didn't do this and other people copied them...

Actually thats an extremely good point, and TBH the reason why I was looking at the scratchpad demo for how to do bits. Figured as its been coded by Kier, it would have been done correctly.

It does make you wonder if people or maybe even addons should have "Xen Standards Certified" or something, although it would likely be far too much work for someone to keep up with checking.
 
There's IMHO a small problem.

If somebody who have not really a clue makes a add-on, an somebody else with no clue checks this, he learns it false.
For example: Models should ALWAYS be instanced with the create factory, instead of creating a new object with the new operator.

There were some add-ons, which didn't do this and other people copied them...
Not everyone is familiar with MVC frameworks. I know PHP (to an extent) but I wouldn't know how to create something with the MVC style that XF has.
 
Not everyone is familiar with MVC frameworks. I know PHP (to an extent) but I wouldn't know how to create something with the MVC style that XF has.
Actually, that's part of the point of XenForo - we have done our best to create a framework that people can work with without requiring that they have the knowledge necessary to create MVC from scratch.
 
Actually, that's part of the point of XenForo - we have done our best to create a framework that people can work with without requiring that they have the knowledge necessary to create MVC from scratch.
I agree. I know how/when to put things in the model by using the autoloader class names. The problem is, me (and many others) don't know what belongs in a model or what belongs in a controller. I know more now than I originally did (part of the learning curve), but that problem still exists for people not familiar with it.
 
One of the easiest ways to learn how to create add-ons for XenForo is to look at XenForo itself. Once you understand the pattern and how information is passed for different functions within XF itself, you can perform similar designs much easier.

It's not always easy, but thankfully the developers have documented quite a bit so it's much easier to follow. If you're using a proper IDE, it's even easier. (y)
 
The simplest division is View/non-View - and the way to approach it is like this: If you are doing anything with data that is going to affect how it looks, or is pushing it towards a particular output format, the only place it can go is in the View.

The items you pass to the View in your $viewParams (for XenForo_Controller->responseView()) should be usable by any display format. If you are passing data that could not be used in XML, JSON, HTML, XHTML, a compiled destop application, a printer, a fax machine... then you are doing it wrong, and some of your code should sit in a View.

As for Controller vs Model, it's best to think of reusability. If you have some code that is specific to a content type and that could potentially be used multiple times in several different Controllers, or several times in the same Controller, it probably lives in a Model.

As far as possible, Controllers should be limited to collecting input and passing that input in a managed form off to methods in Models before calling the appropriate controller response. The thinner your Controller, the better.
 
The simplest division is View/non-View - and the way to approach it is like this: If you are doing anything with data that is going to affect how it looks, or is pushing it towards a particular output format, the only place it can go is in the View.

The items you pass to the View in your $viewParams (for XenForo_Controller->responseView()) should be usable by any display format. If you are passing data that could not be used in XML, JSON, HTML, XHTML, a compiled destop application, a printer, a fax machine... then you are doing it wrong, and some of your code should sit in a View.

As for Controller vs Model, it's best to think of reusability. If you have some code that is specific to a content type and that could potentially be used multiple times in several different Controllers, or several times in the same Controller, it probably lives in a Model.

As far as possible, Controllers should be limited to collecting input and passing that input in a managed form off to methods in Models before calling the appropriate controller response. The thinner your Controller, the better.

Cheers for that, some handy info :)

Also something else I should have noted. xenforo itself is commented to death. Have a look through the code if your trying to work out how something works. :)
 
As for Controller vs Model, it's best to think of reusability. If you have some code that is specific to a content type and that could potentially be used multiple times in several different Controllers, or several times in the same Controller, it probably lives in a Model.

As far as possible, Controllers should be limited to collecting input and passing that input in a managed form off to methods in Models before calling the appropriate controller response. The thinner your Controller, the better.
So would you say that a query belongs in a model or controller? Any query could be re-used multiple times. What if I had:
Code:
$db->query("SELECT username FROM xf_user WHERE user_id > 6")

Would that belong in a model, or would it be better off putting it in a controller?
 
So would you say that a query belongs in a model or controller? Any query could be re-used multiple times. What if I had:
Code:
$db->query("SELECT username FROM xf_user WHERE user_id > 6")

Would that belong in a model, or would it be better off putting it in a controller?
In short: Queries always go in the model.

(Strictly speaking, there can be a few exceptions, but they're not worth going into here. The exceptions aren't controllers or views though.)
 
Oh a IMHO very important note (because many add-ons don't do this^^):

Try to use the existing models and don't reintroduce the wheel ! If you need users from the db, use the user model, threads => thread model....
 
It's not always easy, but thankfully the developers have documented quite a bit so it's much easier to follow. If you're using a proper IDE, it's even easier. (y)
Abit off topic but what's a good IDE? I use notepad2 atm :X
 
Top Bottom