Re: [Postfixadmin-devel] Merging model/ and scripts/models-ext/

[Valkum <va...@go...>]

Hello,

nice to see that something happened with my handlers.

I hope that you noticed that i added a config class to stay away from
global vars.
If we use my handlers we have to add this config class natively.
For l18n we should use something else to. Global Vars in touch with OOP
bring headaches


Rudi

Am 27.11.2010 00:40, schrieb Christian Boltz:
> Hello,
>
> The classes in scripts/models-ext/ contain some changes that affect the 
> public interface of the classes. 
>
> @David: Can you please review them and add some comments? I don't want 
> to break the XMLRPC interface or anything else ;-)
>
> - is model/
> + is scripts/models-ext/
>
> AliasClass:
> -    public function get($all=false) {
> -        $username = escape_string($this->username);
> +    public function get($alias, $all=false) {
> +        $alias = escape_string($alias);
> ...
> -            return $list;
> +            $this->return = $list;
> +            return 0;
>          }
> -        return array();
> +        return 1;
>
> UserHandler:
> -    public function change_pass($old_password, $new_password) {
> +    public function change_pw($new_password, $old_password, 
> +                              $match = true) {
>
> This will break for sure (changed function name and parameter order), 
> also the code inside the function changed a lot.
>
> $match = true means that the old password is checked before doing 
> anything. For admin mode, it would probably be easier to make 
> $old_password optional (which would also require the changed parameter 
> order ;-) (Or would this be less secure?)
>
> If I get xmlrpc.php right, the functions are not directly accessable 
> over the API, but are wrapped (in this case in the UserProxy, function 
> change_pass) - right?
>
> That would mean if we change the function parameters, we have to change
> - xmlrpc.php
> - users/password.php
> (Again: Right?)
>
> UserHandler in scripts/models-ext/ also contains several new functions, 
> but this shouldn't break anything ;-)
>
>
> I really have to (find some time to) dig deeper in those classes...
>
>
> Regards,
>
> Christian Boltz