Modul mit eignem Error handler?

[xsign.dll]

Moin,

ich bin ja gerade am Account Modul und dabei ist mir aufgefallen, dass wir es damals häufig über eine Error Variable gelöst haben, welche dann an Smarty weitergegeben wird.
Prinzipiell so:

Mod:

Code:

$err = array();
if( !$input->blablablal )
{
     $err['bla'] = 1;
}

if( count($err) == 0 )
{
     // mach irgendwelchen Mist
}
$smarty->assign('err', $err);

TPL:

Code:

{if $err eq 1}{t}blablablablalab{/t}{/if}

So. Das kann man mit Sicherheit über den Modcontroller/View lösen, sodass man letztlich alles auf folgendes reduzieren kann:

Mod:

Code:

$this->setError(_('Blalaal'), 'optionalerErrorCodeOderName');
if( $this->checkErrors() )
{
     // mach irgendwelchen Mist
}

TPL:

Code:

{if $error}
     {showErrors}
{/if}

In smarty kann man es mit Sicherheit über zugewiesene Handler Funktionen lösen, welche auch mit spezifischen Error Cdoes/Namen umgehen können.
Siehst du da irgendwelche Probs André ?

[Jens-A. Koch]

Hmm... Der Vorschlag gehört in den Bereich "Form-Handling" bzw. genauer "Form-Validierung".

Mir gefällt ein Teil des Vorschlags gut:

Wenn man nur {showFormErrors} in dem jeweiligen TPL verwendet und dafür eine Smarty Funktion erstellt.
TPL:

Code:

{showFormErrors}

Smarty Plugin:

Code:

1.Prüfen, ob FormErrors Array gesetzt
2.Wenn ja, dann foreach Element des Arrays
3.Fehler auflisten

Damit wäre die Ausgabe von Fehlern in einer Fehlerliste überhalb oder unterhalb des Templates möglich.

Vorher das FormErrors Array befüllen:

Module:

Code:

Bedingung nicht erfüllt,
$view->setFormError(errorname, errorcode);

Damit würde ich die Methode setFormError in den View oder den allgemeiner Modulecontroller stecken.

Ein anderer Ansatz im TPL wäre folgender (der ließe sich dann auch gut mit JS verbinden):

<td>
{if (isset($errors.title))} <div class="error"> {/if}
<input type="text" value="{news.title}" />
{if (isset($errors.title))}<br/>{$errors.title}</div>{/if}
</td>

Ich sehe zwei Dinge als Problem.

Erstens, im Hinblick auf die clientseitige Validierung mittels Javascript:

Als gedanklichen Ausgangspunkt können wir festhalten, dass wir beide Validierungsarten brauchen: clientseitig (JS), wegen des Komforts der direkten Fehlerkorrektur ohne Formularsubmit und serverseitig (PHP), wegen Sicherheit und Typ-Richtigkeit der abzulegenden Daten.

Bei JS wird der Fehler oft direkt beim Inputfeld angezeigt. Meistens wird dieses farbig eingefärbt (rot/rosa) um das fehlerhaft befüllte Eingabefehld hervorzuheben. Die Fehlerausgabe erfolgt also direkt an dem Inputfeld.Bei unserer Methode wäre die Errormessages überhalb oder unterhalb der ganzen Forms.
Das müsste man irgendwie verbinden, denn sonst definiert man die Errormessages doppelt. Kann man das irgendwie verbinden?

Zweitens, das ganze Thema Form Validierung und Rückmeldung ist recht umfangreich!
Wollen wir das selbst lösen oder eine Klasse nehmen? Wenn Klasse, welche?
Doctrine? Unsere Inputfilter Klasse? Die bekannte PHP Inputfilter? Oder eine von Smarty, wie z.B. SmartyValidate. Oder PEAR::HTML_QuickForm (creating, validating, processing HTML forms).

[xsign.dll]

gut mir soll es dabei nicht vorrangig um form validierung gehen, sondern um content basierte error übergabe an den jeweiligen view bzw. der view gibt es dann an den respektiven client.

trigger_error behandelt ja direkte Systemfehler, die schwerwiegenderer natur sind. diese enden meistens eigentlich mit nem die() oder exit().
Was ich aber im Sinn hatte, war direkt für den View per Interface vorzuschreiben, dass es eine error-behandelnde content funktion gibt.
Dies muss nicht bedeuten,dass eine form validiert wird. Das kann auch schlichtweg das fehlen eines Systembausteins sein (gd-library), die dann vom Modul angeprangert wird und vom view in sinnvollem format ausgegeben wrid mit jeweiligem error code.

Wie du schon sagtest, bedarf es bei Form-Validierung ganz anderer Methoden. Hier soll es aber schlichtweg um die Übergabe eines Errors vom View an den Client gehen.

[Jens-A. Koch]

Demnach wünscht Du Dir also eine weitere Methode? Das wäre eine Unterteilung in Modul-Fehler {showModuleErrors} und Form-Valdierungsfehler {showFormErrors}. Formfehler kleben an den Inputfeldern oder in der Nähe. ModulFehler überhalb des Modulcontents.

[xsign.dll]

Gibt es hier irgendwelche Neuigkeiten im Core? Es wird zunehmend notwendiger, dass Errors von einem Modul ausgegeben werden können. Wie oben beschrieben, am besten generalisiert, damit wir nicht Template UND Modulklasse ändern müssen.
Von mir aus ins Template: {$moduleErrors}
Im Modul dann: $this->assignError('Headline', 'Text');
Vllt. findet man noch einen anderen Namen als "Error", da dies einen schwerweigenden Fehler impliziert. Zumindest bei mir.

[Jens-A. Koch]

Bitte 2 Tickets dafür anlegen.
Das eine ist {showFormValidationErrors}, das andere {showErrors}.
Das erste erfasst Formfehler und gibts sie an die jeweilige Form zurück und wird, der Position nach, in den Formhandler integriert.
Das zweite gibt allgemeine Fehlermeldungen zurück und wird vor die Ausgabe des Modulcontents geschaltet.

[xsign.dll]

http://www.clansuite.com/trac/ticket/59
http://www.clansuite.com/trac/ticket/60