My Idea: The coding of MTF

Ok, So MTF, the idea, is almost perfect for OOP, mostly because OOP alows extending and « plugining in » (and MTF is based off that). I’ve been thinking about it and here is my idea for the « recoding » of MTF.

There is a class for MTF base. This class defines the basic functions that every forum type would need. This calss also sets up public functions that will be overwritten like a function for forum display, showthread, etc.

Then we have another class for every addon. Every addons class extends the base class and overwrites the public functions that are custom for this forum type.

Finally in say global_start something like:
if ($forumid AND in_array(THIS_SCRIPT, array(‘showthread’, ‘forumdisplay’,etc)
$forumtype = //use forumcache to get the forum type
include(‘mtf/class_’ . $forumtype);
$ft = new $forumtype($forumid);
Then hooks like showthread something like:
would be ran.

This method also allows a very simple product and only really one file upload.

4 réponses sur “My Idea: The coding of MTF”

  1. you’re the one to know where it can go… i understand nothing in what you say, but the logic is pure.. go for it.. lol

    … i look stupid; i understand everything of what you are talking about, i just never coded it… i have confidence in your evaluations, you know better than me what the OOP have to look like.

    and yes, i think that MTF is the perfect gadget for OOP, that’s why i contacted you about it.

  2. the base is very thin actually, the goal is to have a logic, nothing else… the base is actually just the menu in the forum editor, and it fold for each type you select…

    from what i see, we need:

    1- forum editor part
    2- forumdisplay check-type/preview
    3- showthread check-type/elements
    4- post editor check-type/elements/fields
    5- moderation permissions

    i personally think that the entire management of all these features is already done in vBulletin… permissions, edition etc. we can add some bitfields when specific features need more permissions, but that’s it…

    i have a full featured Attachment Manager in the Attachment Album, i think it’s the only thing that will require a bigger engine if we stop editing vBulletin files, because i hate file edits.. i would prefer duplicating an entire file instead, so the clients do not have to break their files, it makes the support a lot smaller too — because i hate to support my stuff, i prefer perfect stuff.