postfixadmin-devel

[Postfixadmin-devel] Return value of model/* classes

[Christian B. <pos...@cb...>]

Hello,

while merging model/UserHander and scripts/models-ext/UserHandler, I 
noticed that they use very different (and unfortunately incompatible) 
return values.

I took UserHandler->change_pw as an example, but this is most probably 
an issue that appears at lots of functions inside the model/* classes.

The "old" model/UserHandler returns
- true on success [1]
- false on failure

The "new" scripts/models-ext/UserHandler (that I merged to 
model/UserHandler some minutes ago, r896) returns
- 0 on success
- 1 on failure

Needless to say than true and 0 are the exact opposite :-(

The questions are:
- Will the XMLRPC interface compatibility break if we switch to 0/1?
  (you can test this already with current SVN trunk for change_pw ;-)
- Will the CLI break if we use true/false?
- And finally: Which style is "better"? Which one should we use?


Regards,

Christian Boltz

[1] or if there is no error check, but that's another story ;-)
-- 
In the beginning was the word, and the word was content-type: text/plain

Re: [Postfixadmin-devel] Return value of model/* classes

[Rudi F. <va...@go...>]

Hello,

Between the models and the cli are the shells. In these classes we can
change the 0, 1 problem.
When i created the classes i orientated at the unix/linux format. 0 ok
1-n failure code.

Regards Rudi

Am Samstag, 18. Dezember 2010 schrieb Christian Boltz <pos...@cb...>:
> Hello,
>
> while merging model/UserHander and scripts/models-ext/UserHandler, I
> noticed that they use very different (and unfortunately incompatible)
> return values.
>
> I took UserHandler->change_pw as an example, but this is most probably
> an issue that appears at lots of functions inside the model/* classes.
>
> The "old" model/UserHandler returns
> - true on success [1]
> - false on failure
>
> The "new" scripts/models-ext/UserHandler (that I merged to
> model/UserHandler some minutes ago, r896) returns
> - 0 on success
> - 1 on failure
>
> Needless to say than true and 0 are the exact opposite :-(
>
> The questions are:
> - Will the XMLRPC interface compatibility break if we switch to 0/1?
>   (you can test this already with current SVN trunk for change_pw ;-)
> - Will the CLI break if we use true/false?
> - And finally: Which style is "better"? Which one should we use?
>
>
> Regards,
>
> Christian Boltz
>
> [1] or if there is no error check, but that's another story ;-)
> --
> In the beginning was the word, and the word was content-type: text/plain
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
>

Re: [Postfixadmin-devel] Return value of model/* classes

[Christian B. <pos...@cb...>]

Hello,

Am Samstag, 18. Dezember 2010 schrieb Rudi Floren:
> Between the models and the cli are the shells. In these classes we
> can change the 0, 1 problem.
> When i created the classes i orientated at the unix/linux format. 0
> ok 1-n failure code.

Good motivation, but in PHP more code uses true/false ;-)

I changed UserHandler and parts of AliasHandler to true/false, and also
updated the CLI - everything should still work as expected.
I'will change the remaining *Handlers when time permits (unless someone 
beats me, of course ;-)

Two questions regarding the CLI: 

1) When I do an invalid action (for example trying to create an already 
existing mailbox), I get an error message, but $? is still 0. Is this 
something I broke while switching to true/false or is that a bug in the 
CLI code? (and: how to fix it?)

2) Is there some way to have less duplicated code in the shells/* ?
For example, shells/alias.php and shells/domain.php have 400 common 
lines and only 100 lines specific to one of these files.


Regards,

Christian Boltz
-- 
> /etc/sysconfig/powersave/cpufreq contains the line:
> # the next lover CPU frequency. Increasing this value lowers the
             ^^^^^
we should keep that one ;)
[Michael Gross in https://bugzilla.novell.com/show_bug.cgi?id=183704]

Re: [Postfixadmin-devel] Return value of model/* classes

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

[easier to handle in german; translation on request]

hab es mal eingebaut im aktuellen commit für user add. Bei mir geht es
nun. Testet es mal selber und sagt mir was ihr davon haltet.

Am 27.12.2010 01:01, schrieb Christian Boltz:
> Hallo Rudi,
>
> Am Sonntag, 26. Dezember 2010 schrieb Valkum:
>> hab mir das mal angeschaut. Ich habe auch ein paar TODOs und MARKs
>> geadded.
>>
>> Zu 1:
>> Was genau meinst du mit $? ?? Also bei mir arbeitet die add funktion
>> so wie sie soll.
>> Kannst du mir da ein paar mehr infos geben.
> Ich meine den Statuscode in der Shell (bash o. ä.)
>
> Also sowas wie
>
>     postfixadmin-cli user add fo...@cb... [...] || echo "Fehler"
>
> oder auch (vereinfacht)
>
>     true || echo "Fehler"
>     false || echo "Fehler"
>     true && echo "geht"
>     false && echo "geht"
>     true ; echo $?
>     false ; echo $?
>
> Wenn jemand Domains, Postfächer etc. mit einem Script anlegen will (und 
> das ist definitiv ein Usecase fürs CLI), ist diese Art der Prüfung 
> deutlich einfacher als den Output parsen zu müssen.
>
> Also genau die Shell-Returncodes, die Du beim Schreiben des CLI 
> bezüglich Returncodes im Kopf hattest - nur eben nach "außen" und nicht 
> "intern" im PHP-Code.
>
>> Zu 2: Hab schon mal angefangen. Also sollte mit Vererbung
>> funktionieren. Code der in allen shells existiert kann in die mutter
>> klasse gelagert werden, also Shell in shell.php
>>
>> Hast du mir das recht zu commiten entzogen? Würde sonst meinen
>> aktuellen code mit den Änderungen und comments hochladen.
> Wie Du ja schon festgestellt hast, hast Du nach wie vor 
> Commit-Rechte ;-)
>
>
> Gruß
>
> Christian Boltz

Re: [Postfixadmin-devel] Return value of model/* classes

[Christian B. <pos...@cb...>]

[easier to handle in german; translation on request]

Hallo Rudi, hallo Leute,

Am Montag, 27. Dezember 2010 schrieb Valkum:
> hab es mal eingebaut im aktuellen commit für user add. Bei mir geht
> es nun. Testet es mal selber und sagt mir was ihr davon haltet.

Funktioniert schonmal wie erwartet, aber... ;-)

Ich glaube, wir sollten zwischen interaktivem Modus und nicht-
interaktivem Modus (sprich: alles auf der Kommandozeile) unterscheiden.

a) komplette Kommandozeile:
- kein Aufruf von _welcome() (außer bei -v [verbose])
- keine Ausgabe einer Erfolgsmeldung - außer bei -v
- Fehlermeldungen nur bei -q unterdrücken
-> Ohne -q oder -v sollte im Erfolgsfall gar nichts ausgegeben werden
   und bei einem Fehler (nur) die Fehlermeldung.

b) interaktiver Modus:
- da macht -q generell kaum Sinn ;-)
- grundsätzlich _welcome() aufrufen (außer bei -q)
- Ausgabe der Erfolgsmeldung sollte default sein (außer bei -q)
- aus Konsistenzgründen bei -q auch Fehlermeldungen unterdrücken
- Problem: was, wenn jemand Fehlermeldungen, aber keine Erfolgsmeldung 
  haben will? (Wobei ich ehrlich gesagt bezweifle, dass das vorkommt - 
  aber wir sollten es zumindest einplanen ("-v=0"?), um nicht später das 
  Standard-Verhalten ändern zu müssen.)


Gruß

Christian Boltz
-- 
> Ich denke mein Beispiel war gut, nur dein Beispiel hinkt.
Wenn mein Beispiel hinkt, dann hat Deines einen Behindertenausweis
und darf direkt beim Eingang parken... ;)
[Georg Schmidt und Christian Luetgens in dsrs]

Re: [Postfixadmin-devel] Return value of model/* classes

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

Am 27.12.2010 23:04, schrieb Christian Boltz:
> [easier to handle in german; translation on request]
>
> Hallo Rudi, hallo Leute,
>
> Am Montag, 27. Dezember 2010 schrieb Valkum:
>> hab es mal eingebaut im aktuellen commit für user add. Bei mir geht
>> es nun. Testet es mal selber und sagt mir was ihr davon haltet.
> Funktioniert schonmal wie erwartet, aber... ;-)
>
> Ich glaube, wir sollten zwischen interaktivem Modus und nicht-
> interaktivem Modus (sprich: alles auf der Kommandozeile) unterscheiden.
>
> a) komplette Kommandozeile:
> - kein Aufruf von _welcome() (außer bei -v [verbose])
> - keine Ausgabe einer Erfolgsmeldung - außer bei -v
> - Fehlermeldungen nur bei -q unterdrücken
> -> Ohne -q oder -v sollte im Erfolgsfall gar nichts ausgegeben werden
>    und bei einem Fehler (nur) die Fehlermeldung.
>
> b) interaktiver Modus:
> - da macht -q generell kaum Sinn ;-)
> - grundsätzlich _welcome() aufrufen (außer bei -q)
> - Ausgabe der Erfolgsmeldung sollte default sein (außer bei -q)
> - aus Konsistenzgründen bei -q auch Fehlermeldungen unterdrücken
> - Problem: was, wenn jemand Fehlermeldungen, aber keine Erfolgsmeldung 
>   haben will? (Wobei ich ehrlich gesagt bezweifle, dass das vorkommt - 
>   aber wir sollten es zumindest einplanen ("-v=0"?), um nicht später das 
>   Standard-Verhalten ändern zu müssen.)
>
Nehmen wir an: User will email (wird in externes system eingetragen);
cli wird aufgerufen; die Erfolgsmeldung (mailadresse und generiertes
passwort) wird dann auf irgendeine weise automatisch dem User
mitgeteilt. Dieses verhalten sollte auch ohne verbose möglich sein, da
verbose im übertragenden sinne ine ausführliche auskunft über den
programmstatus zur laufzeit gibt. Zum suchen von fehler etc. Nur eine
Nummer kleiner als -d für debug. Also sollte zumindest die
Erfolgsmeldung bei a) ausgegeben werden im Standart.

Gruß
Rudi