[Garnele]

Hallo Leute

Ich glaube ich stehe auf dem Schlauch, aber wie kann ich prüfen, ob Checkboxen aktiviert sind?

<input type="checkbox" name="test" value="erste" />
<input type="checkbox" name="test" value="zweite" /> 

Ich möchte gerne jede einzeln prüfen.

Danke, Garnele

[Bleistift]

Die beiden Checkboxen können nicht gleich heissen. :/

[Garnele]

Hallo

Ich sagte ja, ich stehe auf dem Schlauch

Danke, Garnele

[xabbuh]

Hallo,

es gibt zwei Möglichkeiten dein Problem zu lösen:

1. Du gibst beiden Checkboxen unterschiedliche Namen und prüfst in deinem PHP-Script mit isset(), ob die entsprechende Checkbox aktiviert wurde:

PHP-Code:

<?php
    if(isset($_POST['test1']))  {
        print('test1 wurde ausgewählt');
    }
    if(isset($_POST['test2']))  {
        print('test2 wurde ausgewählt');
    }
?>

2. Du hängst eckige Klammern an die Namen der Checkboxen an und behandelst diese in deinem PHP-Script somit als Array:

PHP-Code:

<?php
    if(isset($_POST['test']) && is_array($_POST['test']))  {
        if(in_array('eins', $_POST['test'])) {
            print('eins wurde ausgewählt');
        }
        if(in_array('zwei', $_POST['test'])) {
            print('zwei wurde ausgewählt');
        }
    }
?>

Grüße

[Jann Hendrik]

oder meinst du ggf. radiobuttons?
http://de.selfhtml.org/html/formular...m#radiobuttons

die könnten dann auch gleich heißen, und du kannst dann zB wählen, dass nur der eine und nicht der andere auch noch auswählbar ist.

[Ben]

xabbuh hat es ja schon sehr gut beschrieben. Ergäenzend hau ich hier noch einen Link rein: http://tut.php-q.net/formulare.html#u13

[DasMööp]

http://tut.php-q.net/formulare.html#u13

Wenn die Checkbox kein Haken hat wird sie auch nicht gesendet.

Jetzt erstelle/Prüfe ich das Form/den _post in einer classe und kann im Formular Felder definieren die ausgefüllt werden müssen.

Da die Felder radio/checkbox aber nicht mitgesendet werden kann ich diese nicht prüfen ...

Hat jemand evtl. doch eine Idee bzw. Ansatz ?

[Bleistift]

Doch, du kannst diese sehr wohl prüfen... Du kannst eben prüfen, ob sie gesendet wurden :/

PHP-Code:

if(isset($_POST['derNameMeinerCheckbox'])) {
    echo 'checkbox gesendet';
} 


[DasMööp]

Hi,

das is klar, das unmögliche liegt an der Sache das ich das Formular
anhand von Daten erstelle und dort felder definiere die ausgefüllt werden
müssen.

Das läuft Dynamisch, nur wenn ich eben nichts zurück bekomme was
es an Felder in dem Formular gibt dann kann ich nicht auf verdacht
irgend einen checkboxnamen auf isset prüfen ...

Ich erspare mir dabei das prüfen der Daten bzw. es wird gleich in
einer Class abgehandelt. Da mittels des input namens sofort klar ist was
da ausgefüllt wird und ob es ausgefüllt sein muss + den eigentlichen Namen
für fehler beim ausfüllen /bzw speichern der Daten.

Ich bin jetzt ab überlegen ob es hilft da js anzugehen oder solche felder
mittels hidden mitzuliefern als hinweis ... is aber auch irgendwie rotz

Oder ich hinterlege wieder irgendwo alle Felder des Formulares als
array. Hierzu müsste ich aber per pattern das File mit dem Formular
durchsuchen ein Array schreiben und das evtl. sogar mit im Formular
übergeben... damit ist dann eine prüfung möglich auf ist das da und wie
ist der Status.

also pattern nach

name="(.*)"

hmmm ... das könnt sich evtl. ausgehen ... (auch wenns wieder rotzig ist
mit dem umstand ansich)

Bisher 3 Fehler die wie ich finde mitgeliefert werden sollten:
1. Der Form name
2. Checkboxen auch bei null
3. Radio auch bei null (aber nur angelehnt)

So, danke fürs auslassen ... das frustet doch etwas. Und sorry habe vorhin auch glaube ich zur erklärung ein paar Sätze zu wenig geschrieben

[DasMööp]

Wie letztere Überlegung dann jetzt umgesetzt. Funzt wunderbar auch wenns
nach meinem geschmack umständlich wie Sau ist.

[Basti]

Ich würde da mal dein Modell überprüfen. Du musst doch auf der Severseite die Information haben, welche Angaben benötigt werden und welche nicht. Anders könntest du die Formulare ja nicht generieren. Es sei denn, du schreibst diese Information lediglich in die Templates. Dann hast du aber das Problem, dass du nicht gewährleisten kannst, dass dir nicht jemand dei ausgegeben Formulare manipuliert bzw. eben ganz eigne HTTP-POST-Requests absetzt.

Wenn die Info also nur im Template vorhanden ist, würde ich mit Widgets arbeiten, also im einfachsten Fall einer Methode, die dir ein bestimmtest Formularfeld generiert. Diese Methode kann dann z.B. in die Session oder sonstwohin speichern, welche Formularfelder ausgegeben wurden und mit dieser Info kannst du dann den zurückkommenden Request abgleichen. Das wäre allemal sauberer, als dein Template nach bestimmten Suchmustern zu durchwühlen (im Übrigen gibt es für sowas XML-Parser bzw. die DOM-Erweiterung von PHP).

Generell bleibt da natürlich die Frage, warum die Info, welce Daten benötigt werden ausschließlich im Formular, also im HTML-Quelltext bzw. Template verfügbar sein sollen.

Einfaches Beispiel:

PHP-Code:

<?php
// DataObject, das mittels Formular bearbeitet werden soll

class ForumPosting extends DataObject
{
    protected $aProperties = array(
        'title'      => some definitions,
        'text'       => some definitions,
        'author'     => ...,
        'ip'         => ...,
        'created_at' => ...
    );

    protected function valdate_title($mValue)
    {
        if (strlen($mValue) < 1)
             $this->addError('title', 'empty');
    }
}

In DataObject gehst du einfach alle Felder aus der Definition durch und schaust, ob eine Methode validate_<property> existiert. Natürlich lassen sich solche flags wie "required" oder Werte für "max_len" etc. auch in der Definition speichern oder zumindest immer wiederkehrende Prüfungen in eigene Methoden auslagern.

Das Dingens rufst du dann einfach so auf:

PHP-Code:

<?php

class YourController extends Controller
{
    public function action_addPost()
    {
        $View = new View('post_add_form');

        if ($this->Request->has('sent')) {

            $Post = $this->Persistence->create('ForumPost', $this->Request->get('post'));
            if ($Post->isValid()) {

                $Post->save();
                return new Redirect('thread blabla', 'add_post_success');

            } else {

                $View->assign('post', $Post);
            }
        }
        return $View;
    }
}

Im Template dann was in der Art:

PHP-Code:

<?php
if ($this->has('Post.errors')) {
?>

<div class="error_message">
    <h2>Bitte korrigieren Sie folgende Eingaben:</h2>
    <ul>
<?php foreach ($this->getArray('Post.error') as $sErrorId) ?>
        <li><?php $this->getTranslated($sError, 'de'); ?></li>
<?php } ?>
    </ul>
</div>

<?php
}
?>

<form ...>
    <input type="text" name="post" value="<?php $this->printVar('Post.title'); ?>" />
    ...
</form>

...irgendwie so halt.

War jetzt vielleicht ein wenig ausschweifend und passt vielleicht gar nicht zu deiner Arbeitsweise, aber vielleicht bringts dich ja dennoch ein Stückchen weiter. Ist ja auch klar, dass Formulareingaben sich nicht immer 1:1 auf ein DataObject übertragen lassen, aber ein System, bei dem die Info, was wie validiert werden muss aus dem POST-Request hervorgehen soll kannst ist erstmal sehr suspekt - je nachdem, wie viel MAcht da an den Client übergeben wird.

Nochwas:
Ich hatte ein Ähnliches Problem mit Seitenkomponenen in einem CMS. Ich habdort einfach ein hidden-Field gesetzt mit der Info, dass eine bestimmte Komponente in das "große Seitenformular" eingebunden war und entsprechend aktualisiert werden muss, auch wenn keine Daten übertragen wurden.

Basti

[DasMööp]

Hi,

das muss ich mir mal in Ruhe durchedenken ,Deinen Ansatz, das klingt aber
aufs erste ned schlecht .Ich muss beides später mal umsetzen
erstmal muss es bei Vorliegenden Formularen funzen. Das Dynamisch erstellen
treibe ich paralell vorran nur ists da nicht so einfach das die Dinger dann
Sauber aussehen (ma guggen).

Folgende Umsetzung habe ich jetzt mal Strukturiert.


- Formular Classe prüft immer sobald ein Request kommt.

- Bei dem Aufruf ein Formular File zu Laden schicke ich
den Filenamen als hidden mit

- Bei der Prüfung der Request Daten Patter ich mir anhand der
definierten Typen die Feldnamen raus und vergleiche ob diese
auch im $_post[x] gesetzt sind ... wenn definiert wurde das
es ein muss Feld ist.


Bin jetzt grad dran zwar das File zu Laden aber in dem File pro
Feld ein eigenes Tag mitzugeben das ich dann patter die Infos zu
diesem Feld in die Session Speichere ... beim pattern wird das
ja gelöscht und steht auch nicht im Quelltext + der Formular Code
ist auch nur Standard. Somit habe ich alle Definitionen zur Verfügung, wenn
ein SumbitRequest kommt.

Hälst Du das mit den Session sauber /sicher ?
(gut besser als grad die erst umsetztung).

Muss mir Deine Überlegung noch genauer betrachten, bin auch am überlegen wie aufwendig und Sinnvoll das Dynamische ertellen ist.
Grund: Absolut Definierte Werte/Struktur der Formular.tpl
Grund2: Weniger Files (aber mehr Code) bzw. das Formular steht/generiert in der Classe schon und nicht per get_FileTpl.

Nur das Blöde bei dem Dynamisch das man das vielleicht auch nur für
die Hauptausgabe machen kann aber nicht wenn sich die breite welche zur Verfügung steht ändert.

Naja 1.teres wird es auf jeden Fall und an dem anderen kann man sich nur ranbastelln wie ich finde.

Mööp

[Basti]

Hast es wohl grad eilig gehabt. Ich verstehe nämlich etwa nur die Hälfte von dem was du schreibst.

Zunächstmal:
Ich generiere die Formulare nicht dynamisch. Da gibt es aber einige Ansätze und Anwendungen im Netz. Vielleicht mal unter den Stichwörtern "RAD", "CRUD", "Form Generation" etc. im Zusammenhang mit PHP suchen.

Aber zu deinen Problemen:
Wo schickst du die Formulare denn hin? Wieso musst du per HIDDEN-Field den "Filenamen" mitgeben und von was für einer Datei sprichst du da? Etwa dem Formular-Template?

Ein Formular ist doch immer an eine Funktion deiner Anwendung gerichtet: "Melde Benutzer an", "Bearbeite Artikel", "Füge Kommentar hinzu" etc. Diese Funktion wissen doch genau, welche Werte sie benötigen, denn sie verarbeiten diese Wert ja schließlich.

An was kaust du da gerade, dass das nicht gegeben ist?

Wenn du daran arbeitest, dass alle Formulare deiner Anwendung automatisch validiert und ggf. die Werte gefiltert werden sollen, dann brauchst du ja eh irgendwo die Definition, in welche Gültigkeitsbereichen welche Werte für welches Formular liegen müssen. Wenn du hier z.B. absolut eindeutige Feld-Bezeichner (also die name-Attribute der Formular-Felder) benutzt, dann kannst du die Gültigkeitsbereiche global festlegen.

Oder eben per Formular (wobei ich hier einen Hash mitschicken würde, der in der z.B. Session dem Namen des Formulars zugeordnet ist). Möglich auch die Definition für jeden Wert einzeln festzulegen. Hier bietet es sich wahrscheinlich an, bestimmte Datentypen zu definieren und diese dann in den Templates verschiedenen Widget-Klassen zu übergeben, die z.B. auch die zusätzlichen clientseitigen Prüf-Methoden einbauen. Das könnte man auch so als Schicht anlegen, dass alle geposteten Daten gleich wieder durch "ihre" Widgets "durchgehen" und z.B. das Formular nochmal mit Fehlermeldungen zurückgeschickt wird, ohne dass du in der eigentlichen Anwendung dazu was programmieren musst (außer vielleicht irgendwelche Callback-Methoden, durch die du dann nochmal gesondert reagieren oder die Werte zusätzlich noch "inhaltlich" validieren kannst).

Schreib am besten mal konkreter, was du vorhast, dann wird das "Rumgeeier" hier vielleicht produktiver.

Basti

[DasMööp]

Hi,

also nochmal ganz in ruhe.

Stand der Dinge ist:

Keine Hiddenfelder mehr !
Form/Field Daten in Session !
Definierte vorgaben in dem Formular bei jedem Feld.

Ich setze ein Formular aus einem File, dieser Function gebe ich folgendes mit

- Filename
- Template Variable
- Option ob BB-Code gesetzt werden soll
- Optional den result von einer Query

Jetzt ist in jedem Html Formular Feld eigens ein String festgelegt in welchem
stehen muss was für ein

- Feldtype (checked, text, ...)
- 0 oder 1 für Mussfeld
- Name des Feldes
- Name der Spalte in der DB
- Pattern angabe

Nun suche ich mir diese Informationen aus dem File heraus in
ein Array.

Wenn ein result dann werden die Daten auch gleich gesetzt. Wenn nicht
ist ja alles Leer, die Verweise sind aber jetzt nicht mehr im Formular
ersichtlich.

Die Information des Formulares Speichere ich in der Session
- Formularname
- Count der Felder im Formular
- Feld Informationen der einzelnen Formularfelder

Wenn ein Request kommt dann durchläuft es automatisch die Klasse
und prüft ob die Felder aus dem Session Array in dem request vorkommen.
Wenn der Count aus der Session(+1 wegen submit) und dem request
übereinstimmen sonst -> error.

Dies (SESSION) ganze ist ja nur Wichtig für eben
- Checkboxen
- Radio (naja)
- Select Multiple
wenn hier nichts ausgewählt ist, ich aber 1 für ein Mussfeld definiert habe.

Jetzt wird erstmal auf Mussfeld geprüft, wenn das ok ist dann wird
das Value für das Template mal gesetzt. Wenn nicht wird die Bezeichnung rot
ausgegeben und das Feld rot umrandet.

Beim setzten des Value habe ich ja den Type.
Mittels einer switch Anweisung kann ich hier dann anhand fester Typen
zB. text, text nur Pwd, text nur eMail, schon vorab prüfen und gegebenfalls
ein false/error defineren.

Zudem kann ich jetzt noch wenn das Pattern gesetzt wurde dieses verwenden
und anhand diesem jetzt nochmal Überprüfen zB. nur auf Zahlen oder die
länge. Da ich ja nicht für jede Möglichkeit im Switch was brauche nur für
die 9 vordefinierten.

Gesonderte Sachen kann ich ja immer noch in anderen Klassen prüfen
wenn es sein muss (bzw. eben durch das pattern). Aber so habe ich das
meiste dann einfach schon abgehandelt.

Und in der Classe die das Form benötigt diese kann einfach auf die
Variable zurückgreifen welche true oder false bei error hergibt.

Jetzt ersichtlicher ?

Fazit es funzt jetzt, frage ist nur ob ich da auch einen weg einschlage
der ok ist und nicht völlig unsinnig.

[Basti]

So ganz kann ich es mir noch nicht vorstellen. Was bedeutet z.B.

Ich setze ein Formular aus einem File, dieser Function gebe ich folgendes mit

Was ist das für eine Datei? Ein Template? Eine Definition des Daten-Schemas? Eine Datei mit einer Klasse, die das Formular repräsentiert? ...

Welcher "Function"?

Jetzt ist in jedem Html Formular Feld eigens ein String festgelegt in welchem
stehen muss was für ein

Als Attribut des jeweiligen Tags, oder wie? Warum dann nicht gleich einen Widget-Tag definieren, der - je nach Typ - die entsprechenden Attribute einzeln erwartet, oder dem du einen Identifier für ein Datenobjekt mitgibst, der die Definitionen (maximale Länge etc.) enthält? Das ganze kannst du dann mit DOM parsen oder per XSLT in ein PHP-Template umschreiben.

Jetzt wird erstmal auf Mussfeld geprüft, wenn das ok ist dann wird
das Value für das Template mal gesetzt. Wenn nicht wird die Bezeichnung rot
ausgegeben und das Feld rot umrandet.

Warum musst du Werte setzen, wenn eine Eingabe valide ist? Warum existiert zu dem Zeitpunkt (an dem noch nicht mal klar ist, ob der POST-Request valide ist oder nicht) überhaupt schon ein Template? Gut, im meinem Beispiel oben (YourController) hab ich die View auch schon gesetzt, obwohl ich sie garnicht benötige, wenn die Daten alle okay sind (denn dann werden die Daten ja nur verarbeitet und es gibt einen Redirect), aber das war lediglich meine Schreibfaulheit und keine grundlegende Design-Entscheidung.

---

Prinzipiell finde ich die Entscheidung, die Definition für die Datentypen in die Templates (wenn ich das richtig verstanden habe) recht fragwürdig. Klar kann das sehr einfaches Programmieren ermöglichen, aber du kannst einem Template-Designer (oder dem Anwender, wenn er die Templates selbst bearbeiten kann) doch nicht anvertrauen, dein Daten-Modell zu zerschießen.

Was, wenn hier ein Wert "max_len" eingegeben wird, der den definierten Speicherplatz deiner Datenbank-Felder überschreitet? Was, wenn ein Regulärer Ausdruck zur Validierung rausgelöscht oder verändert wird und die Benutzer plötzlich auf alle Dateien auf dem Server zugreifen können?

Das macht natürlich nichts, wenn du alleine an dem System arbeitest, aber prinzipiell gehören - nach meinem Verständnis - derartige Definition nicht in die View-Schicht bzw. ist es einfach sinnig zu unterscheiden zwischen der Definition des Datenmodells und der Definition des Aussehens der Formulare. Und hier würde ich eben eher in die Richtung gehen, die Definition des Datenmodells so zu erweitern, dass du ausreichend Infos hast, um daraus dynamisch Formulare zu erzeugen, als die Definition der Formulare so auszuweiten, dass sich aus diesen dein Datenmodell ergibt.

Lesenswert:
http://wiki.apache.org/cocoon/Design...FormGeneration

Basti

PS:
Und mit der Bitte um Konkretisierung meinte ich weniger die konkrete Umsetzung als viel mehr den Sinn und Zweck des Ganzen, wie und worin das eingebunden ist.

[DasMööp]

Und mit der Bitte um Konkretisierung

Naja das ist erstmal nur meine Entwicklung, und sollte da jemals jemand
ein Modul schreiben dann muss er sich halt an die Struktur halten.

Konkret ist das File ein templateFile wo das entsprechende Formular
drin steht. Nur das eben hier definierte werte stehen ...

<input ... [formField$07|1|select1|group|] ...>

Und nur wenn diese mit dem request übereinstimmen ist es valid, zudem
stehen diese Daten nicht im Quellcode.

Welcher "Function"?

Wenn ich ein Formular benöige so wird das lediglich über zb. eine Methode/function der Formular Classe aufgerufen.

->set_form(ZielTplVariable,file,bbCode true/false,SqlDaten/null);

Warum musst du Werte setzen, wenn eine Eingabe valide ist?

*das passiert nur wenn ich vorher eine Variable der FormularClasse auf true
setze ... hat den Sinn wenn man Daten ändert ,will ich bei manchen Modulen
das gleiche geänderte Formular ja wieder haben.

Warum existiert zu dem Zeitpunkt (an dem noch nicht mal klar ist, ob der POST-Request valide ist oder nicht) überhaupt schon ein Template?

Naja wenn es valid ist dann speichern und entweder das Formular wieder anzeigen oder eben kein Setzten der Values und anderes Ziel In abhängikeit der Variable (siehe *).
Wenn nicht valid dann setzen und die false hinweise definieren.

aber du kannst einem Template-Designer (oder dem Anwender, wenn er die Templates selbst bearbeiten kann) doch nicht anvertrauen, dein Daten-Modell zu zerschießen.

Hmm warum nicht ? Ich definiere hier ein paar Vorgaben und die sind einzuhalten ... Sicherlich ist das vorgehen nur eine Umlagerung der
Datenprüfung. Hat für mich aber Sinn wenn ich schon eine eigene Formular Classe habe die mir das Setzen und prüfen von Daten abnimmt, und ich muss
nur noch in Modulen die einen request erwarten absolute Sonderfälle behandeln, vor dem Speichern.

Ich kam da nur drauf da ich eigentlich im Formular lediglich zu beginn hier schon ein Mussfeld Definieren wollte um mir im eigentlichen Code die abfrage der Felder zu ersparen.

If (isset(bla)) und das x mal

Daraus wurde dann mehr wie ich ersichtlicher weise bei Zb. einer checkbox
keinen Request für meine FormularKlasse bekommen habe. Und das zu prüfen
im Code wenn es mehr dieser Felder sind find ich unsinnig/aufwendig.

Hab die Classe jetzt 4 mal umgeschrieben, bin zwar soweit zufrieden aber immer noch am überlegen ob das das grüne ist.

Kann Dir ja auch gerne mal die Classe als Code Zeigen ... wenn das was bringt.

[Basti]

Zitat von DasMööp

<input ... [formField$07|1|select1|group|] ...>

...warum hier nicht XML?

->set_form(ZielTplVariable,file,bbCode true/false,SqlDaten/null);

Schonmal PEAR::HTTP_QuickForm (oder so ähnlich) angeschaut?

Sicherlich ist das vorgehen nur eine Umlagerung der
Datenprüfung. Hat für mich aber Sinn wenn ich schon eine eigene Formular Classe habe die mir das Setzen und prüfen von Daten abnimmt, und ich muss
nur noch in Modulen die einen request erwarten absolute Sonderfälle behandeln, vor dem Speichern.

Klar, das macht absolut Sinn. Ich geh halt anders ran, weil mir das so nicht taugen würde.

Kann Dir ja auch gerne mal die Classe als Code Zeigen ... wenn das was bringt.

Mir brings wohl eher nichts, da diese Herangehensweise für mich eben nicht in Frage kommt. Die Designer, mit denen ich zusammenarbeite sind zwar fit, aber die Validierung der externen Daten werde ich definitiv nicht in deren Hände legen - a) weil so unnötige Fehlerquellen entstehen, die sie womöglich nicht selbst beheben können und b) weils unnötig ist, da es ja letztlich Wurscht ist, wo ich die Feld-Definitionen reinpacke. Da ich eh hauptsächlich an DataObjects rumschraube und diese ohnehin Funktionen zur Validierung implementiert haben müssen gehört es für mich eben genau da hinein (also nicht in die Klassen, aber nur diese bzw. die Instanzen brauchen erstmal die Information aus den in XML geschrieben Definitionen und können die dann ggf. an Widgets weitergeben).

Aber klar: Kannst den Code gerne mal hier reinkopieren.

Basti

[DasMööp]

warum hier nicht XML?

Hatte mal was mit xml zu tun aber das waren Kataloge für einen Marktplatz.
Den Schritt habe ich noch nicht vollzogen was mir xml in sachen cms/web
so bringt.

Für mich waren das einfach nur beschreibende Datenspeicher die anhand
der dtd verglichen wurden auf valid. hmm...

Werd mich mal nach einem praxis Beispiel umsehen.

Schonmal PEAR::HTTP_QuickForm (oder so ähnlich) angeschaut?

Sagt mir so gar nichts ... ne

Das mit dem auslagern der Informationen (also nicht im Formular File) würde
mich soweit schon Interessieren, mein erster Gedanke war vorhin die Felder
in der Datei/Classe (Modul) per Array festzulegen. Somit ist das Formular File
frei von diesen Informationen.
Oder eben in der Combi mit xml ... (noch kein Plan von)

form class

PHP-Code:

/*
 * Created on 06.02.2007
 * form.inc.php5
 */

  /*
   * Form Setting
   * [formField$Typ|must|formFieldName|dbFieldName|pattern]
   * 00 -> Submit [formField$00|0|formName|select|]
   * 01    -> Text
   * 03    -> Textarea
   * 04    -> Checked
   * 05    -> Radio
   * 06    -> Select
   * 07    -> Select Multiple
   * 08    -> Text/eMail
   * 09    -> Text/Passwort Standard Field
   *
   * Extra Defined
   * [formSubmit$form|Senden]
   */


class form_inc {

    private $var = null;
      private $cache = array();

      private $classCms = null;

      public  $postFormInfo = null;

      public  $postFormContent = null;
      public  $postFormStatus = true;
      public  $postFormValues = false;

      private $postFormName = null;
      private $postFormField = null;

      /* __construct */
      public function __construct($classCms) {

    /* set - classCms Instanz */
    $this->classCms = $classCms;

        if (isset($_POST['submit'])) {

            $this->cache['postRequest'] = $_POST;
            $this->postFormInfo = $_SESSION['postFormInfo'];

              $this->check_form();

        }

      }

    /*
     * set
     * post Request Forms
     */
      public function set_form($formVar,$formFile,$formBBcode,$formValue) {

        /*
         * unset
         * set
         * Session Field Info
         */
        unset($_SESSION['postFormInfo']);
        $_SESSION['postFormInfo'] = $this->postFormInfo;

        /*
         * set
         * Data from formValue mySql result
         */
           if (isset($formValue) AND !isset($this->cache['postRequest'])) {

            $arrayFormValues = mysql_fetch_assoc($formValue);

            foreach($this->postFormInfo as $key => $unit) {

                $unitArray = explode('|',$unit);

                if (isset($arrayFormValues[$unitArray[3]])) {

                    $this->cache['set_FormValueArray'][$unit] = $arrayFormValues[$unitArray[3]];

                }

            }

            $this->set_formValues();

           }


        /*
         * set
         * value default
         * @this->postFormInfo
         */
           if (!isset($formValue) AND !isset($this->cache['postRequest'])) {

            foreach($this->postFormInfo as $key => $unit) {

                $unitArray = explode('|',$unit);

                if (!empty($unitArray[4])) {

                    $this->cache['set_FormValueArray'][$unit] = $unitArray[4];

                }

            }

            $this->set_formValues();

           }

        /*
         * set
         * BBCode
         * @formBBcode true
         */
           if ($formBBcode == true) {

               $this->set_formBBcode();

           }

        /*
         * add
         * template
         * @add_parseTpl($formVar,$formFile)
         */
           $this->classCms['template']->add_parseTpl($formVar,$formFile);

      }

      public function set_formBBcode() {

        /*
       &