Beiträge von Arne Drews

Ich denke, die Frage

Zitat von DER

Wie lange programmierst Du schon, bzw. was kannst Du bereits?

war an den TE gerichtet, basti1012

Um es mal klein und verständlich zu halten:

Tabelle posts

Id, Title, Content

Tabelle tags

Id, TagName

Tabelle posts_tags

Id, IdPost, IdTag

Nehmen wir an, Du hast folgende Tags:

Und bspw. einen Post mit der Id 1

nehmen wir jetzt an, Du taggst diesen Post mit HTML5 und JavaScript, dann hast Du in der Tabelle posts_tags folgende Einträge:

Das ist ein Weg der Normalisierung. Damit hast Du die Möglichkeit der Erweiterung offen gehalten und kannst per JOINs Deine Datensätze sammeln.

Wenn Du meinetwegen alle Posts mit dem Tag JavaScript haben willst, sähe das in etwa so aus:

SELECT
    posts.Title,
    posts.Content,
    tags.TagName

FROM
    posts

JOIN
    posts_tags ON posts_tags.IdPost = posts.Id

JOIN
    tags ON tags.Id = posts_tags.IdTag

WHERE
    tags.Id = 3

Nagel mich nicht fest, ist jetzt nur aus'm Ärmel, aber so in etwa solltest Du das korrekte Ergebnis erhalten.

Also mal als Beispiel, wie Du es gerade aufgegriffen hast, wird das tagging in der Art genutzt, dass die tags an die Beiträge gebunden werden.

Und da kommt auch schon die Normalisierung ins Spiel. Wenn Du bspw. mehrer Beiträge mit den selben Tags hast und die Tags ( angenommen ) als Spalten an die Beitragsdatensätze hängst, hast Du viele Dopplungen innerhalb der Spalten, deshalb bricht man das in einzelne Tabellen.

Beispiel:

Du hast eine Tabelle posts und erstellst dazu die Tabelle tags, in der alle bisher eingegeben Tags enthalten sind.

Jetzt kommt eine dritte Tabelle ins Spiel, die pro post:tag Beziehung einen Datensatz enthält.

Durch die eigene tags-Tabelle ist es egal, wie viele unterschiedliche Tags es gibt. Die Daten werden über die dritte Tabelle zusammengeführt.

Zitat von DER

In meinem Speziellen Fall habe ich die Tag Grenze auf 4 festgelegt, und frage mich nun, wie man sowas am besten umsetzt, ohne die Datenbank zuzumüllen, und ohne viel Aufwand im Code aufbringen zu müssen? Und Vor Allem, so, dass sich das System auch einfach von 4 auf z.B 8, oder sogar mehr Tags umstellen lässt.

Normalisierung einhalten und schon ist die Erweiterungsfrage passé.

Für den Rest wäre interessant zu erfahren, was Du bisher angestellt hast, bzw. wie Deine Vorstellungen im Detail aussehen?

Das macht keinen Sinn. Entscheide Dich für eine Version und bring alles darunter zum Laufen.

Anbieten tut sich aktuell dann auch jQuery 3, wenn es denn unbedingt jQuery sein muss.

break ist das Zauberwort. Ich gehe mal davon aus, Dir ist nicht bekannt, dass JS die Array-Elemente automatisch als Objekt betrachtet?

function parseSpecialDays( date_string ) {
  
  var result = false;
  
  for ( var index in feiertage1 ) {

    row = feiertage1[index];
    
    if ( row.date == date_string ) {
      
      result = { 'date':row.date, 'title':row.title };
      break;
      
    }
    
  }

  return result;
  
}

Du befindest Dich in dem each() Kontext, das return muss ausserhalb gesetzt werden.

Warum mischt Du jQuery und natives JS? Entscheide Dich doch für eins...

Stell um auf das Flexmodell, das position-Gehampel bringt nur Probleme.

Dein Footer-Code ist dabei uninteressant. Die Frage ist, wie das Layout aufgebaut ist.

Der Footer sitzt einfach nur an der falschen Stelle im DOM

Die Spalte id in der Tabelle stadt sollte ein AUTO_INCREMENT sein, den musst Du nicht befüllen, das ist ja der Witz an der Sache.

Du kannst doch die ID auch gar nicht über das Formular senden, weil der Benutzer gar nicht wissen kann, welche ID die Stadt bekomme.

Es ist übrigens auch noch nicht abgefangen, ob die Stadt evtl. schon existiert.

Alles gut, ich dachte schon ich raff es nicht...

Zitat von Ryoko1981

Beim Hin und Herschalten der Radio-Buttons wird das Pflichtfeld korrekt deaktiviert.

Genau deshalb verstehe ich Dein Problem nicht. Wenn Du basierend auf den Zustand einer Radiobox Felder deaktivieren kannst, was hindert Dich es stattdessen zu aktivieren?!

Dann verstehe ich Deine Frage nicht.

Du willst das Feld als Pflichtfeld haben, aber beim ersten Aufruf, soll das kein Pflichtfeld sein?!

Vielleicht erklärst Du Dein Vorhaben mal etwas detaillierter?

Zitat von Ryoko1981

Ich komme aber einfach nicht drauf, wie ich es definiere, dass das Pflichtfeld direkt deaktiviert ist, wenn ich das Formular neu betrete...

required="true" weglassen ???

Gerade bei E-Mail funktioniert das relativ zuverlässig mit <input type="email" und :valid bzw. :invalid.

Es gibt seit HTML5 das Attribut pattern, wo Du reguläre Ausdrücke für das erforderliche Eingabe-Muster erstellen kannst.

Mit dem Pseudo-Selektor :valid oder :invalid kannst Du das bestenfalls schon einfärben.

Sollte das nicht ausreichen, müsstest Du mit JS eine Prüfung der Eingabe machen und dem Element eine vorgefertigte CSS-Klasse zuweisen.

Wo hast Du denn $_POST['idstadt'] her? Die kann doch im Formular gar nicht bekannt sein...

Hi,

Zitat von Stef

Man kann auch dem Constructor die Klasse mit der Variable, aus dieser, als Parameter übergeben ?

Ja, ist aber versionsabhängig!

Ich habe hier ja nur einen funktionalen minimalen Ansatz zur Verfügung gestellt und solche Dinge bewusst weg gelassen.

Zitat von Stef

Warum benutzt du static bei der Eigenschaft sowie den Funktionen vom Planner ?

Der Planner ist für mich kein instanziierbares Objekt. Er muss nur bestimmte Methoden ausführen können.

Ich hätte aus meiner Sicht auf die Aufgaben des Planner bezogen keinen Vorteil, ein Objekt instanziieren zu müssen.

Daher habe ich den Planner statisch gemacht.

Zitat von Stef

Mit static braucht man nicht die Klasse zu instanzieren und kann mit 2 Doppelpunkten aus die zugreifen. Aber das ist für mich kein Grund static zu verwenden.

Für mich aber

Mit Doppelpunkt oder nicht hat das allerdings wenig zu tun. Mir reicht das Argument, dass ich kein Objekt instanziieren muss, denn das benötige ich dafür nicht.

Ein Beispiel:

Jedes Schiff hat seine Eigenschaften, die nicht mit denen anderer Schiffe übereinstimmen müssen. Daher definiere ich ein Schiff als ein eigenständiges Objekt, was einer Instanz der Klasse Ship entspricht.

Den Planner gibt es nur einmal, ganz egal welches Schiff, welcher Zeitraum und welche Person betroffen ist.

Mann kann den Planner sicherlich instanziierbar umschreiben, aber ich würde das an der Stelle nicht machen.

Zitat von Stef

Warum benutzt du dabei keine protected bzw private Funktionen?

Das tue ich. In dem Beispiel sind ja nur die elementaren Methoden drin. Die müssen aus dem Script aufgerufen werden können und sind daher public.

Du darfst nicht vergessen, dass das hier nur ein kurzes Beispiel darstellt, wie ich den Workflow interpretieren würde.

Es fehlt noch ein ganze Menge zum fertigen Projekt, aber zumindest funktioniert das Beispiel und mit Planner::debug() erhältst Du ein Array mit den Daten, die der Planner im Produktivmodus als bestätigte Buchung eintragen würde.

Das ist am Ende auch nur meine Sicht auf die Dinge, was nicht zwingend als einzig richtiger Weg zu betrachten ist!

Zitat von MrMurphy

Was voevtonggen gefällt muss noch lange nicht den Ebay-Interessenten gefallen.

Und nu? Deshalb macht es immer noch keinen Sinn, dass ihm hier Leute erzählen, was ihnen am besten gefällt. Denn das muss anderen eBay-Interessenten auch nicht gefallen, so wie Du schon selber schreibst.

Genau, auf der Basis würde ich die hier gefragte Problematik wie bereits angesprochen auch komplett MySQL überlassen:

INSERT INTO stadt ( stadt ) values ( 'meine Stadt' );
INSERT INTO adressen ( vorname, nachname, id_stadt ) VALUES ( 'Hans', 'Wurst', LAST_INSERT_ID() )

Das würde mit PDO bspw. so aussehen:

$sQuery = "INSERT INTO stadt ( stadt ) values ( :stadt );";
$sQuery .= "INSERT INTO adressen ( vorname, nachname, id_stadt ) VALUES ( :vname, :nname, LAST_INSERT_ID() )";

$oStmnt = $oPDO->prepare( sQuery );
$oStmnt->execute([
        'stadt' => $stadt,
        'vname' => $vorname,
        'nname' => $nachname
    ]);

WICHTIG: Das funktioniert auf die Weise nur, wenn der erste INSERT nur einen Datensatz schreibt! Wird an der Stelle ein Mulit-INSERT verwendet, liefert LAST_INSERT_ID() die ID des ersten Datensatzes! Da müsste man dann halt umdenken.