CommandFramework #107
Keine Reviewer
Label
Kein Label
Bug
Codeverbesserung
Einsteiger Freundlich
Idee
In Arbeit
Neues Feature
Prio A
Security Breach
Überprüfung notwendig
Verbesserung
Zu Beobachten
Kein Meilenstein
Niemand zuständig
2 Beteiligte
Fällig am
Kein Fälligkeitsdatum gesetzt.
Abhängigkeiten
Keine Abhängigkeiten gesetzt.
Referenz: SteamWar/SpigotCore#107
Laden…
In neuem Issue referenzieren
Einen Benutzer sperren
Keine Beschreibung angegeben.
Branch "CommandFramework" löschen
Das Löschen eines Branches ist permanent. Obwohl der Branch für eine kurze Zeit weiter existieren könnte, kann diese Aktion in den meisten Fällen NICHT rückgängig gemacht werden. Fortfahren?
compileJava.options.compilerArgs << '-parameter'
Damit das help System ordentlich funktioniert mit den Parameter Namen muss das compiler Argument '-parameter' mit angefügt werden. Sonst werden die Nachrichten aus 'arg1, arg2...' bestehen.
Bei description kann man auch übersetzten lassen, wenn man ein field in der Klasse hat mit dem namen 'MESSAGE' und dieses auch ein Message objekt hält
Das wirkt mir eher, als sei das Multilingual-System nicht verstanden worden. Es gibt keinen Grund, im Messagesystem irgendwas mit Reflections zu machen. Geschweige denn irgendwelche Compilation-Parameter zu nutzen, das schreit förmlich nach "diese Lösung ist falsch".
@ -88,0 +97,4 @@
errors.add("The method '" + method.toString() + "' is lacking the varArgs parameters of type '" + String.class.getTypeName() + "' as last Argument");
}
if (!errors.isEmpty()) {
errors.forEach(s -> Bukkit.getLogger().log(Level.WARNING, s));
Warum nicht direkt die WARNINGS printen bzw. sind das nicht Programmierfehler, also müssten nicht Exceptions fliegen?
Kann ich gerne als Exception fliegen lassen, aber ich will es gesamt halt sagen.
Programmierfehler sollst du nicht mehr oder weniger silent verstecken, sondern korrekt werfen, was wiederum zum einen Logeinträge hinterlässt, Stacktraces und ggf. den Nutzer über die fehlgeschlagene Operation informiert. Exceptions sind sprichwörtlich dafür gemacht.
@ -125,0 +148,4 @@
private void messageSystem() {
try {
Field field = getClass().getDeclaredField("MESSAGE");
Nope nope nope. Lass dir beim Erstellen des Commands ein Message-Objekt übergeben.
Doch, Doch, Doch, weil ich will kein Sache übergeben bekommen! Ich will es auch optional halten usw usw!
Dann nutze einen Setter.
Ist nicht einfach so da, ich will das ich nichts dafür aufrufen oder sonst machen muss! So wie das Register und Mapper und so.
Der Einsatz von Reflections zu diesem Grund ist einfach nur unangemessen. Ein Objekt MESSAGE zur Verfügung zu stellen, ist genauso. Warum nicht einfach message als protected Parameter im SWCommand haben, dann kann das auch einfach problemlos gesetzt werden....
Lixfel dieses System kann man so noch einfach aus dem SpigotCore kopieren und woanders verwenden, wenn ich das verdrahte nicht mehr!
Wohin hast du denn vor, dieses System eins zu eins zu kopieren?
Zeanon verwendet es in einem seiner Projekte.
Njoa, Also das Message-System ist exakt eine Klasse mehr. Ich glaube, es ist komplexer, Support für mit und ohne Message-System vorzuhalten, als einfach das Message-System mit dranzuhängen.
@ -166,12 +218,64 @@ public abstract class SWCommand {
SWCommandUtils.commandMap.register("steamwar", this.command);
}
public void inject(Plugin plugin) {
Warum muss das jetzt wieder plötzlich injected werden?
Weil wichtig und so und API, welche uns bei zeiten helfen kann.
@ -169,0 +234,4 @@
help = new ArrayList<>();
commandList.forEach(subCommand -> {
StringBuilder st = new StringBuilder();
st.append("§8/§7").append(command.getName()).append(" ");
Sämtliche Color-Codes sind auch Teil des Message-Systems. Farben haben in anderen Sprach- und Kulturkreisen andere Bedeutungen.
Haben nicht die SteamwarFarben aus einem Grund?
? Deutsch? Wir haben die Farben aus dem Grund, dass wir Stil haben und nicht wie nahezu jeder andere Server einfach einen kunterbunten flashy Colorstyle haben.
*wir
Können wir nicht dann trotzdem unser Style in jede Message setzten?
Ja genau, in die Message, und nicht in den Code.
Ok und wie soll ich dies deiner Meinung dann machen?
Also wie soll ich die keys nennen, wo soll ich dies dokumentieren und was soll ich machen, wenn diese nicht existieren?
@ -169,0 +260,4 @@
}
String string = "/" + command.getName() + " " + String.join(" ", args);
sender.sendMessage("§7----==== §e" + command.getName() + " §7====----");
sender.sendMessage("§7Aliases§8:§e " + String.join("§8,§e ", command.getAliases()));
Nicht übersetzt....
@ -169,0 +263,4 @@
sender.sendMessage("§7Aliases§8:§e " + String.join("§8,§e ", command.getAliases()));
help.forEach(s -> {
if (s.replaceAll("§[0-9A-Z]", "").startsWith(string)) {
sender.sendMessage(s);
Du nutzt nicht das Message-System, um dann die Nachricht mit sendMessage rauszuschicken. Dafür nutzt man Message.send()
Ich baue aber die Nachrichten vorher zusammen, also geht dies hier nicht!
Du sollst die Nachrichten auch vom Message-System zusammenbauen lassen...
Geht zu einem TEIL nicht also vergiss es!
Dann erläutere mir einen Fall, warum es geht nicht?
Weil ich die Nachrichten zusammenbaue, weil diese nicht durch das Message System einfach erzeugt werden können.
Nicht überzeugt, mein CommandFramework (was ich noch in den BungeeCore integrieren möchte) hatte schließlich auch schon Multilinguale Fehler- und Hilfsmeldungen.
...
Und ich weiß wie man das Message System an der Stelle verwendet.
So schaut es mir als Entwickler des Message-Systems in diesem PR nicht einmal ansatzweise aus.
Gut. Sorry das ich irgendwie was mir überlege.
Das ist ja auch richtig und wichtig, aber ich gebe dir nach meinem NACK ja auch Lösungsvorschläge.
@YoyoNow Inwiefern ist das hier noch aktuell bzw. gewünscht?
Naja an sich etwas outdatet und damit definitiv nicht mehr aktuell, aber wünschen würde ich mir die Anpassung schon noch.