My personal wishlist

[D@ve]

1. using OOP consequently

Espcially Mod authors could profit oft extended classes:

For example we have our normal user class

Code: Select all

class user_general
{
    public function do_something($property)
    {
        //some normal phpBB
    }
} 

But in the normal phpBB you just use another class in a separate file. This class is empty by default and extends the normal phpBB User class. In that way modders could add a lot of functionality without touching the phpBB Core

Code: Select all

class user extends user_general
{
    public function do_something($property, $other_property)
    {
        //here we overwrite the general function
    }
    public function do_something_else($property)
    {
    }
} 

On the other hand it would be quite cool to have more framework functions eg: user::load_by_id(), user::load_by_username() or something like that...


2. A more complex permissions System.
I really love the permissions of phpBB. But I miss more detailed options... Not just "allowed" and "not allowed" permissions. There is a lot of suff in the general posting config that simply doesn't belong there (time limits, max characters, etc.). Imo all this stuff should be managable via permissions.

3. better user <=> group management
I was really happy about the "Newly registered users" group. It would be cool if you could extend that in a general way. So that you could define certain conditions for a group Membership. Example
- Every User with < 20 Post => automatically in group "Newly registered users"
- Every User with > 1000 Post => automatically in group "Professional users"
- Every User with language "de" => automatically in group "English users" (so you could manage a multilingual board)

4. A "Recycled" Forum
I was a Moderator in a lot of boards. Every board has a hidden garbage forum for "deleted" topics. It would be REALLY cool if you could jsut click on the delete button and the post/topic will be moved into that garbage forum, instead of deleting it.

5. Consequently ban user
I often have the problem that I want to delete/ban users without deleting the whole account. If I delete the account I will loose IP-data and email addresses and can't prevent them to register again with the same data. But if I just "ban" them, some board fuctionality still works. For example subscribtions, PNs or email. And they still are in the users list. So my workflow looks like that:
1. ban user
2. put user into a "banned user" group (where permissions for PN and stuff like that are switched of)
3. switching off all the notify-options in his profile
I would be VERY happy if I could do that just with one click on "ban" so that a banned user wont receive PNs, notifications and stuff like that and is REALLY banned.

6. AJAX
Since I use phpBB as a framework for almost all website I produce it would be cool if there would be some basic Ajax classes for web 2.0 maybe you don't need to reinvent the wheel and just implement an existing framwork like (e.g. Xajax is very slight andy easy to combine with phpBB)

Some tiny stuff
- language switch for guests
- should be possible to deactivate some safety issues, like additional login box for ACP etc.
- Language Switch for guest_users
- automatic DST switch
- a link to the user profile in the ACP
- combining user_activation and admin_activation
- Standard-Settings for search and UCP (e.g. topic notification switched on by default)
- an option to merge two different users (just some lines of sql).
- searchable PMs
- a "deregister" function in the UCP, for useres to delete or ban (see 5.) their account
- Editable "terms and condition": a terms page, every user has to accept if something has changed.
- Style: Template-Vars in Includes (eg <!-- INCLUDE forum_row.FILE_NAME--> )
- using namespaces for phpBB instances (makes it easier to combine phpBB with other frameworks)
- logging the IPs of a user (not just of the post)

best regards,
Dave

[ameeck]

You're fist suggestion is not possible, as it is would not allow two modifications to work at the same time. What you describe is extending the original class and ensuring that all instances used in phpBB would have the new method. In order to omit necessary code changes, you need to use magic methods __call and __callStatic

e.g.

Code: Select all

class MyClass extends Object
{
    public $a;
    public $b;
}

//Extension function:
function MyClass_join(MyClass $_this, $separator)
{
    return $_this->a . $separator . $_this->b;
}


MyClass::extensionMethod('MyClass::join', 'MyClass_join'); // PHP 5.2 

$obj = new MyClass;
echo $obj->join(' '); 

This example is taken from the Nette PHP framework. http://api.nettephp.com/0.9/Nette/Object.html

In this case, the parent general Object class maintains a list of added methods and with __call it allows you to call extended methods added to the class on-the-fly. The extensionMethod method just adds the new method to a list from which __call grabs available functions.

I haven't seen Symfony 2 yet much, but it should probably allow some kind of a similar behaviour.

[igorw]

What you are suggesting is some kind of "mixin" or multiple inheritance. Seriously, using proper OOP can help a lot. Use composition instead of inheritance. Allow replacing parts of the user instead of extending and replacing the whole user. Just saying.

[D@ve]

Was just an idea.
If I don't use phpBB for our projekcts I take the QCubed framework this is based on this system and it's pretty cool if you can add or repalce functions without touching the core.

[ameeck]

What you are suggesting is some kind of "mixin" or multiple inheritance. Seriously, using proper OOP can help a lot. Use composition instead of inheritance. Allow replacing parts of the user instead of extending and replacing the whole user. Just saying.

Yeah, it's practially a mixin. Can you follow up on your thoughts a bit more?

[igorw]

Mixins are messy. They are hard to test. In case of PHP they are slow. Instead, you could create a proxy user, replacing the real user, that delegates method calls to MODs. You could also use a set of decorators that wrap around each other, each replacing functionality.

But it's generally better to find a solution that doesn't require modification of the user class by multiple MODs at all. Instead of modifying the behavior through inheritance you should use composition. In case of the user this could be format_date. Instead of having a "format_date" method, you would have a DateFormatter (or similar) instance. Instead of overriding the method you can now just replace the DateFormatter instance with a custom one.

[ameeck]

evil3: But what if the administrator wants to install multiple MODs, each customizing the format_date function (or supplying another instance of a method that takes care of its function)?

[igorw]

Well, obviously there can be conflicts if two MODs want to change the same thing. And here it really depends what they change. If it's "prepend the date with 'date>> ', then the decorator approach (preferably applied on the DateFormatter) would work. The same applies to wrapping the date in a '<span class="my_date">' tag. Here the order must be configurable though. Should 'date>>' be embedded in the span too, or not? The MOD cannot know.

When replacing functionality it becomes more difficult. Let's say two MODs want to replace the actual date string. One of them just returns a unix timestamp, the other uses a hebrew calendar. Obviously, there can only be one.

Using mixins does not change that.

[D@ve]

Using decorators It's not a bad idea. But I think it is not unimportant to keep it simple for mod authors. Nobody touches somthink he doesn't understand. The styles are a good example for that. Pro Silver and SubSilver are both state of the art in XHTML and CSS Design. But the whole thing is too complicated what you see in the lack of creativity at the templates (most designers just alter the templates in Color and images, real creative templates are very rare because nobody dares to touch the templates).

But what if the administrator wants to install multiple MODs, each customizing the format_date function (or supplying another instance of a method that takes care of its function)?

This is a problem you always have to face. You can minimiz it using small entities and not the one big swiss army-knife-do-it-all-in-one class/method.

[LiquidSpark]

You would simply deactivate the mod(s) you don't want.