Xenforo codebase less plugin-friendly

[Claudio]

I was reading an opinion of Ian (DBTECH):

We did try to develop for xenForo, but due to the fact that development of xF has ground to a halt, and we find codebase less plugin-friendly than vB5 (please don't take this as an official company-sanctioned comparison ), we decided to scale back development on it.

Let me give you a rough example of coding for vB vs coding for xF. Let's say you want to add a custom page that runs your custom code.

xF:
1. Create a route prefix in the admincp (~5 form elements)
2. Create a controller handler (~5 form elements) in the admincp that refers from the route prefix
3. Create a controller handler file in the filesystem (partially copy-pastable) that handles the actions and tells xF what template to render
4. Create the template in the AdminCP and edit it
5. Edit the controller file / template as needed

vB5:
1. Create a route in the mod's installer code
2. Create a widget and edit its template how you like
3. Create an API file in the filesystem and add code as needed


TL;DR / non-technical: We find it easier to create an addon for vB5 than it is to create an addon for xF.

What do you think about this? Do they need to understand XF software first or his opinion is right?

https://www.vbulletin.com/forum/sho...-vB5-Connect?p=2350018&viewfull=1#post2350018

 

[Cory Booth]

I was reading an opinion of Ian (DBTECH):



What do you think about this? Do they need to understand XF software first or his opinion is right?

https://www.vbulletin.com/forum/sho...-vB5-Connect?p=2350018&viewfull=1#post2350018

<sarcasm> I thought XF and VB were the same code? How can creating a plugin be any different between the two? </sarcasm>

 

[Forsaken]

I was reading an opinion of Ian (DBTECH):



What do you think about this? Do they need to understand XF software first or his opinion is right?

https://www.vbulletin.com/forum/sho...-vB5-Connect?p=2350018&viewfull=1#post2350018

He's complaining about extra steps required to develop an add-on; XF is much more robust than vBulletin is, and much easier to develop for if you take the time to work with it.

 

[Claudio]

and much easier to develop for if you take the time to work with it.

I don´t know anything about programming.

So he is right? is more difficult to develop plugins for XF than VB5?

 

[Forsaken]

I don´t know anything about programming.

So he is right? is more difficult to develop plugins for XF than VB5?

It depends on who is doing the developing; for me and most developers I know, they prefer XF by far.

 

[SchmitzIT]

I don´t know anything about programming.

So he is right? is more difficult to develop plugins for XF than VB5?

If taking two extra steps equals more difficult, then sure.

Let's put it this way. If you need something changed or added to your house. Would you prefer just starting to add new components together and hope the foundation supports it, or would you sleep easier knowing that a systematical approach and taking the time to ensure that your new additions meet the architecture ensures that your new addition conforms and is done properly?

(Not the best analogy, perhaps. Even if you follow the methodical approach, a guy who doesn't know what he's doing might still mess things up, and a real professional handyman/coder could still do a great job without the architecture, but hopefully it gives you some kind of an idea).

 

[Jeremy P]

More difficult? Sure.
But it's worth going the extra mile.

XenForo's architecture allows for powerful addons and third party apps to be developed.

I used MVC before I used XenForo, so I picked it up pretty fast. I understand how it could be a bit more intimidating, but I am in favor of it. The code separation really helps with organization and makes projects easy to manage. I can only imagine the PHP behind vBulletin plugins are a bit more like spaghetti code. In fact, I'd say all vB5 code looks something like spaghetti code.

To ease setup time for developing XF Addons I created an "application skeleton" with a Listener file, Controller, Model, DataWriter, and Installer. It comes it handy to get going on new projects.

So sure, with XF it's a bit more complicated, but that's on purpose, and with good reason. Their conventions encourage well-coded addons, imo. And you get used to it, and once you do, it is a dream to work with.

 

[Chris D]

I have no basis for comparison because before I used XenForo I'd never done any PHP development at all. But personally I find it a pleasure to work with. I actually try to take an interest in PHP code in general now so I have a habit of looking at other people's PHP scripts. And my head hurts and eyes bleed when I look at non MVC code.

XenForo could be infinitely more difficult than vB5. But who cares, because it's infinitely better.

 

[Insy]

What do you think about this? Do they need to understand XF software first or his opinion is right?

He's right for small addons only (it takes longer to start if you don't have a skeleton), the development of new applications or complex addons in XenForo is much much nicer than in vBulletin DBTech has a long experience in vB development, it is clear that after the development of addons via hooks, developing using MVC framework takes longer to start. And it's faster then.

I have developed several addons for vB 3.x/4.x (for internal use only, you will not find anything on vB.org) and I could do everything via the admincp, I still have difficulties with XenForo because I need to create a bunch of files as DBTech mentionned, but a developer may have fun to develop for a so well designed script.

 

[Digital Doctor]

dbtech hasn't been keen on Xenforo for a long time.
It might be easier for certain experienced vB coders to keep with vB coding than to learn XF coding.
I thought alot of vB coders were waiting to see vB5 stabilize before making any addons.
Who knows when vB5 will be a stable platform ?

 

[Insy]

Who knows when vB5 will be a stable platform ?

No ETA known.

 

[Rodrigo Farcas]

Let's not forget VB5 is pre alpha !

 

[Insy]

Let's not forget VB5 is pre alpha !

Alpha software can be unstable and could cause crashes or data loss. The exception to this is when the alpha is available publicly (such as a pre-order bonus), in which developers normally push for stability so that their testers can test properly. External availability of alpha software is uncommon in proprietary software. However, open source software, in particular, often have publicly available alpha versions, often distributed as the raw source code of the software. The alpha phase usually ends with a feature freeze, indicating that no more features will be added to the software. At this time, the software is said to be feature complete.

Even not. An alpha release should have no more features and they still add new features according to the bug tracker.

 

[Robbo]

Haha what a joke. Any good programmer will see the benefits of how XF works. It is properly structured and easily maintained (mostly). Having to do things in the ACP is a pain but hey, we made a CLI tool for that and for template I made DevTools for that... but hey amateurs will always like procedural style code more (just because something uses the word class doesn't make it OOP).

 

[Bob]

but hey amateurs will always like procedural style code more (just because something uses the word class doesn't make it OOP).

QFT!

 

[Sadik B]

xF:
1. Create a route prefix in the admincp (~5 form elements)
2. Create a controller handler (~5 form elements) in the admincp that refers from the route prefix
3. Create a controller handler file in the filesystem (partially copy-pastable) that handles the actions and tells xF what template to render
4. Create the template in the AdminCP and edit it
5. Edit the controller file / template as needed

Point 1, creating a new route Prefix is only needed if you want a separate route. In most cases you could just extend the available routes, so step 1 and 2 he refers to are not mandatory. For instance, I can extend member or account route to extend or add any new member functionality. Same goes for thread, forum routes etc. New routes I believe should only be defined if you are developing a large addon, something like a shopping cart or a gallery etc. in which case 2 small steps doable within 5 minutes are no price to pay for the maintainability benefits which xenforo provides.

Step 3, 4 and 5 are almost always required but they are laughably easy compared to VBulletin's hook system. Plus the lines of code required in XF is almost always comparatively less for the same function. Add to that the extensibility of core functions is very easy, so between VB 3, 4 and XF, Xenforo wins hands down.

VB5 I have no idea... The HTML output was revolting... and I had no desire to see their code after what some very experienced professional devs had to say about it's code.

 

[kkm323]

So as I recall vb3 add-on doesn't work for vb4, and vb4 add-on doesn't work for vb5...
Now that's not a waste of time! interesting