Beiträge von ilou

    So findet ihr das ihr besser (Ist Jetzt mit einer ArrayList)


    Kannst du mal selber erklären, Schritt für Schritt, was du vor hast?


    Aktuell machst du etwas ganz komisches.


    Und wer hat dir beigebracht, abzufragen, ob ein "Wert eine Eigenschaft" besitzt anstatt eine "Eigenschaft einen Wert".

    Normalerweise strukturiert man Abfragen mit player.getLevel() > 100 und nicht 100 < player.getLevel()

    Um da direkt anzuknüpfen:

    Hey Benne,


    danke für deine Anregung, ich habe nochmal über entsprechendes drübergeschaut.

    So ganz gefunden hast du nicht alles, wodurch der Lesefluss noch immer ein wenig gestört wird, aber immerhin ist diese Suche mal ausführlicher, als eigentlich jede andere, die man hier finden kann.


    Für mich ist euer Projekt leider nichts, aber ich wünsche euch viel Erfolg bei der Suche.

    Aber theoretisch gesehen sind ja nicht alle Statements/Queries anfällig für SQL Injections. Genauer gesagt sind es ja nur die, die direkte Inputs von Spielern annehmen.

    Das stimmt. Ich verwende zumindest in der Webentwicklung trotzdem immer Prepared Statements. Vielleicht auch, um solche Anfragen immer einheitlich zu haben, also den Code zum Anfragen. Ich werde durch das WSC aber auch dazu gezwungen, da deren Database-API nur noch Prepared Statements unterstützt.


    Aber wie oben erwähnt, nehmen sich Prepared Statements und normale Statements bei einmaliger Ausführung scheinbar nichts.


    Bei dem Rest kann ich dir nicht helfen, habe noch nicht mit Datenbanken in Java gearbeitet.

    Sollte ich für einmalige SQL-Tasks auch PreparedStatements nutzen oder ist es besser die normalen Statements zu nutzen?

    Wie sieht es von der Performance bei einmaliger Verwendung aus? Gibt es eine grundlegende Faustregel, wann was genutzt werden sollte?

    Genau kann ich dir diese Frage nicht beantworten. Für meinen Teil würde ich aber immer Prepared Statements in Betracht ziehen, allein schon aus dem Grund, wie du selber sagtest, um SQL Injections zu vermeiden.


    Soweit ich das gerade richtig interpretiere, werden "normale" Statements ebenfalls compiled, so wie PreparedStatements, nur mit dem Unterschied, dass Prepared Statements gecached werden, so also eine schnellere Ausführung bei weiteren Aufrufen dieser erfolgen kann. Performance-technisch dürften sich Prepared Statements meines Erachtens nach also nicht großartig viel gegenüber "normalen" Statements geben, zumindest bei einmaliger Ausführung :)

    Falls du Maven nutzt, versuch mal den Cache zu leeren und IntelliJ neu zu starten. Falls du kein Maven verwendest, kannst du es trotzdem mal versuchen.

    Ich frage mal nicht, warum du weißt, dass eine deiner Command-Klassen nicht funktionieren, wenn die Main schon nicht auffindbar ist.


    Wer gibt dir denn den Fehler? Der Server? Stimmen deine Imports?

    Ich würde dir dafür try-with-resources empfehlen, dann musst du dich ums closen nicht mehr kümmern.

    Das habe ich ihm auch schon einmal empfohlen, aber er scheint es nicht nutzen zu wollen/können. Aber ich kann mich nur (erneut) der Empfehlung anschließen, try-with-resources zu verwenden. Das macht dir die Arbeit leichter und sicherer.


    Auch der Empfehlung, Primary Keys zu definieren, kann ich nur zustimmen: Das hat nicht nur den Vorteil, dass du Duplikate vermeidest, sondern sorgt auch für einen guten Performance-Boost. Ein Primary-Key ist nämlich auch automatisch ein Index und Indizes werden in relationalen Datenbanken so organisiert, dass diese schnell aufgerufen/gefunden werden können. Es verkürzt also auch noch deine Ausführungszeit.


    Ich würde daher einfach mal empfehlen, dass du mal versuchst, den Sinn und Nutzen von Primary Keys zu verstehen und sie bei dir zu implementieren.

    Noch als kleiner Hinweis, auf den auch andauernd hier hingewiesen wird: Du solltest dir auch überlegen, Ressourcen wieder freizugeben, also beim PreparedStatement mittels Aufruf von close wieder zu schließen. Wenn du das Erstellen des PreparedStatements mit try-with-ressource umsetzt, sollte Java sich sogar unter allen Umständen um das schließen kümmern.

    Wie wäre es mit message.startsWith(word) oder message.equalsIgnoreCase(word).


    Contains sagt es ja eigentlich schon. Wenn die Nachricht das Wort beinhaltet.

    Das hat aber den Nachteil, dass sowas wie Du hs oder so nicht gefiltert wird. Daher ist contains aus meiner Sicht schon vernünftig. Vielleicht fügt man vor dem zu überprüfenden Wort und danach noch ein Leerzeichen ein, dass man damit auf alleinstehende hs (oder anderes) untersucht. Aber da dann aufpassen: Besteht die Nachricht wirklich nur aus hs, enthält diese nicht  hs . Das könnte man umgehen, indem man einfach vor und nach der eingegebenen Nachricht auch noch ein Leerzeichen einfügt.


    Jetzt hat man den Part geschafft.

    Dann sollte man aber noch Fälle mit Sonderzeichen überlegen. Sowas wie ,hs, #hs oder Ähnliches würde dann wieder nicht erkannt werden.


    Da fällt mir aber gerade auf Anhieb nicht großartig eine Möglichkeit zu ein, das effektiv zu beheben, ohne jede Kombination einzuspeichern und abzugleichen.

    Hey,


    der Code kommt mir bekannt vor: https://community.woltlab.com/…r-php-seite-user-abfrage/ :D Aber egal.

    Da du das WSC nutzt, würde ich in keinem Fall dazu raten, PHP-Code direkt auszugeben. Das WSC nutzt Templates zur Darstellung von (dynamischem) Inhalt. Ich vermute mal, du hast dein HTML-Formular auch in einer entsprechenden Template-Datei (.tpl).


    Darin kannst du Template Scripting verwenden: Den Inhalt von Variablen kannst du vereinfacht gesagt mit {$variablenName} ausgeben. Damit es aber diese Variable auch gibt, musst du diese in deiner Formular-Klasse, also die jenige, die von AbstractForm erbt, die Funktion assignVariables so erweitern, dass an das Template die entsprechende Variable übergeben wird. Das kann dann in etwa so aussehen:

    Code
    public function assignVariables() {
        parent::assignVariables();
    
        WCF::getTPL()->assign([
            "variablenName" => "Herbert"
        ]);
    }


    Du kannst jetzt als Variablen-Namen z.B. "userName" nehmen und dort entsprechend den Nutzernamen des Nutzers angeben, sofern es einen gibt.


    Du kannst dann im Template mit dem Attribut value="{$userName}" den Nutzernamen vom Nutzer als Wert für das Input-Feld ausgeben.


    Schau dir aber auch gerne die Dokumentation diesbezüglich vom WSC an. Wenn man sich damit ein wenig auseinandersetzt, klappt das schon recht gut: https://docs.woltlab.com/tutor…art-1-base-structure.html


    Gruß

    ilou


    //EDIT: Achsoo, das ist gar kein WSC-Plugin. Hab mich eben schon gewundert, warum du die global.php nochmal extra includest. Dann darfst du diesen Beitrag gerne ignorieren. Ich lasse ihn aber trotzdem mal stehen. Vielleicht enthält er ja trotzdem hilfreiche Informationen.


    //EDIT2: Dann kann das von JD1992 doch funktionieren.

    du willst in einem Server Team arbeiten und Plugins entwickeln ohne Datenbank Erfahrung?

    Ich denke eher nicht das dich irgend ein Team einstellt,

    Das sehe ich anders. Serverteams suchen Händeringend nach Entwicklern. Klar, es ist sicher besser, wenn bereits Erfahrungen im Umgang mit Datenbanken hat, aber in einigen nicht wenigen Teams vermutlich keine Pflichtvoraussetzung. Den Umgang mit Datenbanken hat man schnell gelernt, und macht bei Spielmodi, zumindest zu Zeiten, in denen ich mit Minecraft gearbeitet habe, auch nur einen abstrahierbaren Bruchteil aus.

    Nur mit dem Problem, dass sich kein Entwickler auf eine solche Stellenaussschreibung, ohne die entsprechenden Informationen, bewirbt. Daher wird es wohl sehr selten zu einem solchen persönlichen Gespräch kommen, und auch der Wille eines Entwicklers, eure Webseite für eigentlich fundamentale Informationen zu durchsuchen, wird wohl oder übel recht gering sein.

    Wir orientieren uns an unseren eigenen Ideen umso einen durchgängigen Spielspaß zu ermöglichen.

    Wie genau sehen eure Ideen aus? Was machen eure Ideen so einzigartig, um den "durchgängigen Spielspaß zu ermöglichen"?


    Allgemein fehlen einige Informationen über das Projekt, die es einem erleichtern, zu entscheiden, ob das das richtige Projekt für einen ist.

    Hier könnte man jetzt auch noch überlegen, ob es nicht sogar Sinn macht, bei player_permissions, group_permissions und player_groups die IDs wegzulassen, da die in dieser n:m-Relation zwischen ihren entsprechenden Tabellen keinen Mehrwert bieten. Stattdessen könnte man hier dann eher einen mehrstelligen Primärschlüssel als Kombination aus z.B. uuid und group_id nutzen.


    Aber an für sich ist der Ansatz von LaSame natürlich auch nicht falsch und sollte zum Testen/Erkunden von MySQL ebenfalls reichen.