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

What can we do to help grow our 3PDs?

<< < (21/23) > >>

Indeed thank you Arantor and Ensiferous for this discussion.

I think it will obviously need some time to digest.  I just wanted to say these sorts of posts on the structure of smf are not superfluous.
At the moment the devs are working towards getting 2.0 completed, and then obviously we will begin further planning for the next iteration of SMF.  So this is obviously the right time to propose/discuss these sorts of changes.
(although we might want to break off these responses into a separate topic on the future structuring of smf architecture/code.)

As for PHP4, we were already working on 2.0 before php4 got officially mothballed, so it didn't make sense to strip php4 support, since support required only a few compatible functions under the current coding style.  I don't think any decision has been taken about support for it for next smf. (I personally wouldn't be against dropping php4 support).

I would quite like a better MVC approach for smf, although MVC and OO aren't necessarily mutually exclusive. Its just that alot of projects doing MVC have done it in a non OO way.

I for one have opted to be notified for future posts in this topic, and I know a post has already been made about this topic to the attention of the developers. So please continue ;)

* regularexpression goes back to bugfixing


--- Quote ---$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']".
--- End quote ---
As far as I know, some functions are reimplemented if UTF-8 is enabled, to support UTF-8 on specific PHP configurations. And one use of the array is for the database implementation - SMF supports multiple DBMSes (MySQL, PostgreSQL, etc.) each of which use different functions. Things like $smcFunc['db_query'] will actually go to the correct function (although, I'd personally use classes that inherit from an abstract class, then instantiate the correct class via a factory method). I was actually saying to someone a while back that an object-oriented SMF would be nice, but it'd be a BIG rewrite that'd require a lot of effort. It'd be nice to see, one day :)

And indeed, I agree with you on a few points. I've seen a few sites migrate away from SMF because they foumd it too hard to integrate :(


--- Quote from: Daniel15 on June 05, 2009, 12:14:56 PM ---And indeed, I agree with you on a few points. I've seen a few sites migrate away from SMF because they found it too hard to integrate :(

--- End quote ---

I came to the point where I had phpBB3 installed and everything converted over because SMF 1.1.9 performed so horribly bad with a 750k memberbase in certain cases such as banning. SMF 2 RC fixed that though so I opted to save my time on integrating phpBB3 and just adapt my own smf_api.php to work with SMF 2 - but it was close, real close.

In the case of $smcFunc the idea is that you don't actually need to touch how it's defined; it's an abstraction to handle the different database backends, and is done so in a way that doesn't require creating three classes then lazy-loading and declaring. It's also PHP 4 friendly for the reasons above.

I would suspect the roadmap would be that for 3.0 to strip PHP 4 support and move some of it towards an OO style.

Two big hooks for 3PDs will be some variation on SSI.php and SMF_API. The former isn't geared to full blown app development with SMF; it's designed as a general purpose slot-in to integrate into sites for those people who aren't strongly technical but can manage a little PHP. For example a news feed on a simple site, or to present the login across a wider site and rely on SMF to handle authentication.

SMF_API has more potential for 3PDs in that regard; it's intended to be lighter-weight, and more readily able to get under the hood a bit - but it's not current for 2.0 I believe. That should be the first step, I think.

A third big hook is the codebase itself. The function DB has gone a long way towards simplifying how to access the codebase to do big things with it - plentiful, good documentation never hurt anyone - and I won't deny a clean-up could be used.

What would be really good is for whatever structure 3.0 might have is for it to be posted with a structure diagram and a guide to how it might look structurally so that we can all help hammer it out. Whatever, I think it's going to be a virtual rewrite rather than a code shakedown/restructure.

Eliana Tamerin:
$smcFunc doesn't just handle databases, if you look at its coding. It's scripted to handle much more than that.


[0] Message Index

[#] Next page

[*] Previous page

Go to full version