Archived Boards and Threads... > SMF Feedback and Discussion

What can we do to help grow our 3PDs?

<< < (19/23) > >>

Ensiferous:
I'd like to apologize up front, because as I wrote this some of my frustration with SMF code turned it into more of a rant than I had originally intended.

Old topic but I figured I'd just give my opinion seeing as I actually work a lot with SMF - or rather, against SMF. Because working with SMF code is a battle, and we're not on the same side.

To reiterate a point made I think was very valid. "The problem with SMF is SMF itself"

You say you strive to modularize it and make it more API like, but I'm running SMF 2.0 RC1-1 and I honestly don't see this. You just have to look at ssi.php to see my point, this is the supposed file for integration yet it sets no less than 32 global variables and include 6 files outside of the settings file.

This isn't integration, it's building stuff on top of SMF - and that's the totally wrong way of going about it. The forum is not a central part of a site - at least not for anything serious - if you think like that you doom your software to be used by 12-year-old and "install and forget" type of people. If you want developers to use it then a shift in programming methods needs to happen with SMF developers. You need to seriously reconsider your entire codebase. Usually I'm not a guy who will rewrite things because you just end up redoing the bugs you already did once, but I'll make an exception for SMF. Start over, scrap PHP 4 support, (seriously, not even the php devs support it any more, forget about the people who are still running it) and work on a code structure that will allow people to integrate SMF into their software, not the other way around.

That's not to say SMF shouldn't offer stuff such as user system and calendar, but it should work perfectly fine using info given to it by another system. Naturally this info would have to be in a specific format, but so long as a programmer doesn't need to include a butt load of your code to use it then it won't be a problem.

A lot of my pet-peeves and cringe-worthy things about SMF actually shows in the SSI file.

$smcFun array with links to functions is just about the most stupid thing I've EVER seen, and I've seen a lot of stupid things. You hide the functions you use in an array so that I have no idea where the hell this function is defined.

Also it seems SMF is re-implementing php functions as in "$smcFunc['strlen']".

SSI is practically a joke, if I want my site login to be the same as my forum login then I don't want to include 2,000 lines of SMF code, I want a simple class I can instantiate, feed a mysql resource link as well as user info to a method and then have that class do what it must.

At this point in time it's impossible to do with SMF, at one point you had a smf_api.php file going which was a step in the right direction. I basically took this and started maintaining it myself to do what I needed it to do without including all of the SMF code - sadly, you've abandoned this.

Since I got off-track and repeated myself a bit I'll just reiterate my points:
 - Realize a forum is a part of a site and not the site itself. It should be treated as such.
 - Forget about PHP 4, it's old, it's not supported and it's horrible.
 - Start over. Restructure code and API and modularize it, in a perfect world none of your modules would depend on the core itself, that way it can easily be included in any other project and used.
 - NO GLOBALS! Ever!

So in my opinion, get SMF 2 out the door and then start on SMF 3 from scratch. Then I could see myself helping out with code contributions to the core and via mods - but right now? No chance in hell I'd spend the time required to even understand SMF code.

Arantor:
Mostly valid points, that.

Though I'm not a rep for SMF, I would argue the following:


* Globals have a place. Just as Goto does. Not all styles of programming support it, not all programmers like it, but there is a place for them.
* A forum can be the entire site itself. Or it can be part of it. Like everything else it depends what you're trying to do. The exact same argument holds for phpBB3 actually. I personally think SMF does the balance fairly well with SSI.php
* I'm currently building an MMORPG that uses SMF for the forum and also to handle all the user authentication. The 2,000 lines is actually smaller than some of the auth classes I've seen, including Zend Framework's.
* If modules don't depend on a core, they by definition have to redo some of the stuff the core does.

Ensiferous:
Globals never have a place, they make it impossible to use unit tests and you have no clear point of definition, basically you have no idea what data you're working with or where it comes from, they are a relic from the past and should not be used in any modern code.

A forum can be the entire site yes, but not for any serious project, the sort of developer who might create quality mods for a forum would be unlikely to have a forum site only, usually the type of people who run those projects are people who can't create a product themselves and thus rely on scripts other people made. Thus why I feel it's relevant to this topic as they're specifically asking for ways to make themselves more attractive to third party developers.

As for the 2,000 lines of code, it was a guestimate to the lines of code that didn't deal with the actual function (in this case user authentication) but rather with various other stuff such as templating, sessions, security, permissions etc. In actuality, the number is far, far larger as subs/load.php alone is 2500 lines. Regardless, citing one bad example as a valid reason for bad code is not a really good argument. Zend Framework is not the pinnacle of good code. :)

As for the modules not depending on the code, you have a point, except I'm in favour of a minimal core that doesn't really do anything but direct code flow to the right parts. Think of it in a layered way, you have a model that analyses the url to determine which action to take, then loads a controller to do so, that controller then loads the various modules and loads the forum as appropriate.

If a module then only depended on other modules then they should be loadable from outside the forum framework without too much fuzz and the various bridges to other sites and scripts would merely be to define a new module loader.

I'm by no means saying it would be easy getting a system in place like this, but it's definitely not impossible.

Arantor:
I have yet to see any sufficiently large piece of code that doesn't use globals at all in any way shape or form (other than globally declared classes). I can give you one excellent reason for globals in the case of SMF though - performance. It would be interesting to see what the SMF developers make of my take on the design decision.

I see it that if you have data that persists for the life of the script's execution - i.e. for the entire page generation, putting into a global scope for that script makes perfect sense. So when we initialise we populate $context with the data of who the user is. If we objectify everything we would logically need to make a User class and make the current user a property of an instance of that class. Then we have to pass the property of that class any time we need to use it, meaning that every time we do a function we have to be sending that data between functions. This will be slower than calling it into scope from outside when you do it a lot (i.e. more than once)


Regarding forums being the entire site, I know of some places where it is by far the main part of a site, and everything else being a bolt-on to it, some that support people very comfortably in fact. It just depends on the project and its aims. But take a look through Showcase - the number of people for whom the forum is the site is the forum is quite surprising.

Actually, under the hood SMF is fairly modular - a check of the Function DB would confirm that is the case.

Regarding the large size of includes; agreed SSI is not as minimal as perhaps it could be, but it has to be a fairly generic thing lest you have a module for each part (one for authentication, one for getting posts, one for getting user details) and moving that to the SSI user-developer to implement. In fact, though you say ZF is not the pinnacle of coding (which it isn't), the manner of objectification you're suggesting - giving each specific area its own module is precisely how ZF is arranged. Whether the individual lines of code are poor, the structure is that which you are arguing in favour of.

2.0 is already a fairly big rewrite versus 1.1 - what would you expect to see in 3.0 that completely rewrites 2.0?

Ensiferous:
You're severely underestimating the power of the CPU, the speed difference between the two programming styles is measured in micro seconds and you will not lose many requests per second. Personally I find the tiny speed degradation worth the gain you get in ease of programming. Besides, you're optimizing in the entirely wrong area, most likely 90% of your script execution time will be spent waiting for the file system of the database. If you want to optimize things then cache things that actually take up time, don't micro-optimize. Besides, premature optimization is the root of fluffy and cute.

I'm not saying that forum-only sites doesn't exist, I'm just saying they're rarely run by the type of person who consistently produce their own code and would be willing to help out with third party addons to SMF.

As for Zend Framework, personally I believe they abstract things a bit too much and use too much magic with cross includes and a much too much complexity. That doesn't mean they aren't going in the right direction, pretty much any PHP framework these days uses a MVC structure, Zend, Solar, CodeIgniter. It doesn't really matter, in the end they all use OOP code since it promotes readable code that's modularized and easy to make heads and tails of.

Navigation

[0] Message Index

[#] Next page

[*] Previous page