Coding-Guides und lange Links
M.
- programmiertechnik
Mahlzeit,
Div. Coding-Guides empfehlen ja eine Zeilenlänge von 90 und schreiben eine maximale Länge von 120 Zeichen vor.
Wie setzt ihr das üblicherweise bei Links um, wenn die z.B. so aussehen: (Smarty-Syntax)
<a href="index.php?module=images&image={$image.name}&action=delete&token={$token}">
Bei ein paar Einrückungen werden das schonmal mehr als 120 Zeichen. Umbrechen kann ich ja den Link nicht. Die Major-Browser kommen damit zwar zurecht (sowei ich das testen konnte) aber es ist weder valide noch schön.
Ignoriert ihr hier die Conding-Guides oder wie löst ihr das? Der automatische Umbruch im Editor ist zwar eine Alternative aber halt nur ne optische Anpassung ;)
Und nein, das generelle Ignorieren von Coding-Guides ist keine Alternative :D
Moin M.,
<a href="index.php?module=images&image={$image.name}&action=delete&token={$token}">
Ich breche dann das href nochmal um und habe es zwei einrückungen tiefer als die Ebene, auf der das <a> startet. Z.B. so:
~~~html
<li><a
href="index.php?module=images&image={$image.name}&action=delete&token={$token}">
Blub</a>
Das wird dann zwar immer noch manchmal länger als 90-120 Zeichen, aber in dem Fall interessierts mich dann nicht mehr: Lesbarkeit > Konvention.
LG,
CK
Hallo,
Ich stelle den Lint auf »Warnung« hinsichtlich der Zeilenlängenbegrenzung. Das Problem versuche ich zu umgehen. Im Programmcode geht das meist. Das Probleme habe ich also selten für seiteninterne Links, die ohnehin mit Helferfunktionen generiert werden.
Wenn ich das richtig sehe, dann werden Zeilenumbrüche im href-Attribute vom Parser ignoriert:
<a href="a
b
c">
wird interpretiert wie
<a href="abc">
Siehe http://www.w3.org/TR/html4/types.html#type-cdata, in HTML5 habe ich eine entsprechende Regel noch nicht gefunden.
Mathias
Moin molily,
Das Probleme habe ich also selten für seiteninterne Links, die ohnehin mit Helferfunktionen generiert werden.
Ja, die Einführung von Helfer-Funktionen war wirklich ein Segen für die Web-Entwicklung. Ich trauere der Zeit, als man die Links noch von Hand generiert hat, kein Stück hinterher…
LG,
CK
Mahlzeit,
Wenn ich das richtig sehe, dann werden Zeilenumbrüche im href-Attribute vom Parser ignoriert:
<a href="a
b
c">
>
> wird interpretiert wie
>
> `<a href="abc">`{:.language-html}
Das stimmt, aber dabei geht die Einrückung verloren, was der Lesbarkeit schadet. Dann ist es IMO besser die Zeile vom Editor (nutze Sublime Text) umbrechen zu lassen und die Zeilenlänge zu ignorieren.
Eine Einrückung macht Probleme, weil die im Link dann vorhanden ist.
--
42
Hi,
Wenn ich das richtig sehe, dann werden Zeilenumbrüche im href-Attribute vom Parser ignoriert:
<a href="a
b
c">
>
> wird interpretiert wie
>
> `<a href="abc">`{:.language-html}
>
> Siehe <http://www.w3.org/TR/html4/types.html#type-cdata>,
Das gilt aber explizit nur für LF – “Ignore line feeds,”
nicht für CR, denn direkt darunter steht dann “Replace each carriage return or tab with a single space.”
Das scheint mir reichlich fehleranfällig – insb. wenn mehrere Personen am Projekt mitarbeiten, mit ggf. unterschiedlichen IDEs/mit unterschiedlichen Einstellungen bzgl. welche Bytewerte tatsächlich für einen „Zeilenumbruch“ geschrieben werden. Und ein FTP-Upload, bei dem im Client eingestellt ist, dass für „ASCII-Dateien“ Zeilenumbrüche zwischen den verschiedenen Systemen automatisch umgewandelt werden sollen, ist ein weiterer potentieller Fehlerfall.
MfG ChrisB
--
Autocomplete has spoiled me to a point where it happens every so often that I encounter a CAPTCHA, and I just type in the first character … and then wait for the rest of the code to be automatically suggested :/
Hi,
Bei ein paar Einrückungen werden das schonmal mehr als 120 Zeichen. Umbrechen kann ich ja den Link nicht. Die Major-Browser kommen damit zwar zurecht (sowei ich das testen konnte) aber es ist weder valide noch schön.
Was hat die Zeilenlänge mit der Validität zu tun?
Man kann komplette HTML-Dokumente in eine Zeile schreiben, ohne daß die Validität beeinträchtigt würde.
cu,
Andreas
Hallo,
Umbrechen kann ich ja den Link nicht. Die Major-Browser kommen damit zwar zurecht (sowei ich das testen konnte) aber es ist weder valide noch schön.
Was hat die Zeilenlänge mit der Validität zu tun?
Ich glaube, es war speziell das Umbrechen in der URL gemeint.
Das ist tatsächlich nicht valide:
»Error: Bad value http://mo↩li↩ly.de for attribute href on element a: Tab, new line or carriage return found.
From line 7, column 4; to line 9, column 7
<body>↩<p><a href="http://mo↩li↩ly.de"></a></
Syntax of URL:
Any URL. For example: /hello, #canvas, or http://example.org/. Characters should be represented in NFC and spaces should be escaped as %20.«
Mathias
Mahlzeit,
Was hat die Zeilenlänge mit der Validität zu tun?
Gar nichts. Aber Zeilenumbrüche mit Einrückung haben was damit zu tun ;)
hi,
<a href="index.php?module=images&image={$image.name}&action=delete&token={$token}">
Prüfe, welche Parameter tatsächlich übern URI geschleift werden müssen. Außerdem:
action=delete;image=%imname%
sind zwei Parameter, da würde ich meinen, dass dafür einer reicht
delete=%imgid%
[Action-Parameter](http://rolfrost.de/action.html)
Und schon hast Du kürzere URLs.
--
Wussten Sie schon: Wolkenbildung lässt sich auch am Himmel beobachten.
Hallo,
<a href="index.php?module=images&image={$image.name}&action=delete&token={$token}">
>
> Prüfe, welche Parameter tatsächlich übern URI geschleift werden müssen.
Wenn wir schon dabei sind:
Nicht idempotente Requests mit serverseitigen Nebeneffekten sollten nicht mit GET gemacht werden, sondern mit POST/PUT/DELETE usw. Der CSRF-Token ist dann Teil des Request-Bodys. Der sollte nämlich nicht Teil der URL sein, denn die URL leakt gerne.
Mit »resourceful« URLs (auch »RESTful« genannt), würde obige URL auf /images/{id} zusammendampfen, das passende HTTP-Verb ist DELETE. Das wird in der Regel mit einem POST-Formular und einem \_method=delete-Parameter oder ähnlich emuliert.
Mathias
hi,
Wenn wir schon dabei sind:
Nicht idempotente Requests mit serverseitigen Nebeneffekten sollten nicht mit GET gemacht werden, sondern mit POST/PUT/DELETE usw. Der CSRF-Token ist dann Teil des Request-Bodys. Der sollte nämlich nicht Teil der URL sein, denn die URL leakt gerne.
Mit »resourceful« URLs (auch »RESTful« genannt), würde obige URL auf /images/{id} zusammendampfen, das passende HTTP-Verb ist DELETE. Das wird in der Regel mit einem POST-Formular und einem _method=delete-Parameter oder ähnlich emuliert.
Ja, schön :)
Noch schiel vöner, mal ausgehend davon, dass der Admin ein Backend vor sich hat, wo _mehrere_ Bildobjekte bearbeitet werden sollen... also anstatt für jedes einzelne Objekt einen Action-Request zu feuern (z.B. delete), könnte der Bearbeiter alles zusammen fix und fertig im Browser vorbereiten, z.B. Title und Beschreibung für jedes Image editieren oder ein Häkchen zum jeweiligen Löschen setzen und dann mit einem einzigen Klick die ganze Sache serverseitig auf den neuesten Stand bringen. So würde ich das machen :)
Mahlzeit,
Prüfe, welche Parameter tatsächlich übern URI geschleift werden müssen. Außerdem:
action=delete;image=%imname%
sind zwei Parameter, da würde ich meinen, dass dafür einer reicht
delete=%imgid%
Nein, da reicht nicht nur einer. Innerhalb des Frameworks werden per module= das Modul und per action= die Methode in der Modul-Klasse festgelegt. Alles, was danach kommt ist optional bzw. Abhängig von der Extension.
hi,
delete=%imgid%
Nein, da reicht nicht nur einer. Innerhalb des Frameworks werden per module= das Modul und per action= die Methode in der Modul-Klasse festgelegt.
Wie ählich sich doch die Frameworks sind, aber es gibt Unterschiede, die nicht unbedeutend sind :)
Hier ist der Unterschied zu meinem FW: Der Name für das Modul wird NICHT übder den URL geschleift, sondern INTERN über ein in der Konfiguration festgelegtes Attribut "class".
Alles, was danach kommt ist optional bzw. Abhängig von der Extension.
Nachdem ein Benutzer den Namen des Moduls im URL geändert hat, könnte das, was danach kommt, ein böses Erwachen sein. Und ja: Es gibt Kunden, die riechen solche Sicherheitslöcher :)
MfG
Mahlzeit,
Nachdem ein Benutzer den Namen des Moduls im URL geändert hat, könnte das, was danach kommt, ein böses Erwachen sein. Und ja: Es gibt Kunden, die riechen solche Sicherheitslöcher :)
In meinem Fall handelt es sich um einen Adminbereich. Wenn der Benutzer da den Modulnamen ändert, ist er erstens selber schuld, wenns nicht funktioniert und zweitens bekommt er ne Fehlermeldung, dass das Modul nicht existiert.
Der Modulname ist gleichzeitig der Dateiname der Datei, die die Klasse enthält. Wenn das Modul existiert, wird vorher erstmal geprüft ob der User das Modul überhaupt aufrufen darf.
Also nix Sicherheitsloch. ;)
hi,
Der Modulname ist gleichzeitig der Dateiname der Datei, die die Klasse enthält.
Ok, trotzdem hat eine solche Information nichts im URL zu suchen, weil das an dieser Stelle manipulierbar ist. Auch sog. Pseudoklassen, was ich in anderen Frameworks gesehen habe, machen diese Angelegenheit nicht besser.
Wenn das Modul existiert, wird vorher erstmal geprüft ob der User das Modul überhaupt aufrufen darf.
Das ist unnötig kompliziert. Die Entwicklung von Anwendungen erweist sich als effizienter, wenn Zugangsberechtigungen komplett aus dem Code raus sind, wie das funktioniert habe ich auf meiner umfangreichen FW-Dokumentation beschrieben, kurzum: Je nach Anmeldung wird eine der Benutzergruppe zugewiesene RoutingTable geladen (Content-Negotiation).
Keine Anmeldung, keine Schokolade, http://example.com/cacao.html, Status: 404 Not Found
Dem Locator wird intern eine Klasse zugewiesen, die von außen nicht veränderbar ist, fertig. Ein angemeldeter Benutzer sieht auf der Domain eine komplett andere Website, als ein normaler Besucher.
Die Prüfung, ob ein Anwender die Klasse benutzen darf, entfällt, weil es eine Zuordnung von URLs zur Anwendergruppe gibt, wobei die jeweiligen Klassen per Konfiguration an die URLs gebunden sind.
Also nix Sicherheitsloch. ;)
Zweifelhaft, dass solche Konstrukte sicherheitsrelevant überschaubar sind und es ist meine über 10jährige Erfahrung im Programmieren von Webanwendungen, die mir das Recht geben, ein solches Statement hier abzuliefern. Wenn ACL-Issues aus dem Code raus sind, gibt es hier auch kein Fehlerpotential.
Schöne Grüße!
Mahlzeit,
Das ist unnötig kompliziert. Die Entwicklung von Anwendungen erweist sich als effizienter, wenn Zugangsberechtigungen komplett aus dem Code raus sind, wie das funktioniert habe ich auf meiner umfangreichen FW-Dokumentation beschrieben, kurzum: Je nach Anmeldung wird eine der Benutzergruppe zugewiesene RoutingTable geladen (Content-Negotiation).
Also ich weise dem User eine Gruppen-ID zu. Die steht in $_SESSION und wird dann mit der Gruppe verglichen, die das Modul aufrufen darf, also ein simples if()
Und das nennst du komplizierter als nen Routing-Table?
Dem Locator wird intern eine Klasse zugewiesen, die von außen nicht veränderbar ist, fertig. Ein angemeldeter Benutzer sieht auf der Domain eine komplett andere Website, als ein normaler Besucher.
In meinem Framework ist weder die Anzahl noch die Namen der Module grundsätzlich festgelegt und/oder bekannt. Der Anwender stellt sich sein System nach Wunsch selbst zusammen. Die Installation erfolgt automatisch per Zip-File und Web-Frontend.
Das es auch 3rd-Party Erweiterungen gibt, ist es völlig unmöglich, Modulnamen fest zu vergeben und zuzuweisen.
Die Prüfung, ob ein Anwender die Klasse benutzen darf, entfällt, weil es eine Zuordnung von URLs zur Anwendergruppe gibt, wobei die jeweiligen Klassen per Konfiguration an die URLs gebunden sind.
Da die Anwendung multilingual ist, kann ein Modul beliebig viele URLs besitzen, da der Modulname, je nach Sprache, variieren kann. Wie sollen alle theoretischen Möglichkeiten vorher erfasst werden?
Zweifelhaft, dass solche Konstrukte sicherheitsrelevant überschaubar sind
Du kannst gerne daran zweifeln, aber solange du es nicht für unmöglich hällst (was ich dir wiederlegen könnte) ist doch alles ok ;)
und es ist meine über 10jährige Erfahrung im Programmieren von Webanwendungen, die mir das Recht geben, ein solches Statement hier abzuliefern. Wenn ACL-Issues aus dem Code raus sind, gibt es hier auch kein Fehlerpotential.
Ich will dir deine Erfahrung nicht absprechen, aber wir wissen beide, das du gerne mal das Rad neu erfindest und es dabei viel komplizierter machst als nötig ;)
Grundsätzlich werde ich mir deine Ausführungen aber nochmal zu Gemüte führen und sehen, was ich davon brauchen kann. Ich halte dich in jedem Fall für einen Fachmann in Sachen Programmierung.
Moin;
also, um Dein eigentliches Problem "lange URL-Strings" zu lösen: Nutze die Möglichkeit der TemplateEngine zum Verarbeiten von Listen, so können die einzelnen Elemente im Editor untereinenander stehen, in Perl würde das z.B. so aussehen:
$self->createUrl(
url => $self->{URL},
module => 'images',
imagename => 'gartenzwerg.jpg',
action => 'delete'
);
Was auch mit dem CGI-Modul möglich ist, u.a. können damit QUERY_STRINGS mit mehreren gleichnamigen Parametern erzeugt werden und das Percent-Encoding erfolgt automatisch.
Deine Entwickler freuten sich über den schönen Code und hätten weitere Möglichkeiten zum Erzeugen dynamischer URLs. Wie das Template dazu aussehen muss, hängt von der Engine ab.
Schönes Wochenende ;)
hi again,
Grundsätzlich werde ich mir deine Ausführungen aber nochmal zu Gemüte führen und sehen, was ich davon brauchen kann. Ich halte dich in jedem Fall für einen Fachmann in Sachen Programmierung.
Das hast Du aber schön gesagt, Danke Dir!!!
ACL: Der Begriff "RoutingTable" klingt aufwändig, am Ende werden jedoch viele Sachen einfacher, u.a. auch die Mehrsprachigkeit, wenn es um Content-Negotiation geht. Damit ist es u.a. möglich, auf einer produktiven Kiste ein Staging einzurichten, so kann z.B. eine Artikelbestellung auf dem Lifesystem getestet werden, ohne dass der Produktivbetrieb beeinträchtigt wird oder gar Daten in produktiven DBs anfallen.
Rad neu erfinden: Dieser Satz ist einfach nur unpassend im Kontext dessen, was ein Programmierer macht, dieser Satz ist eine völlige Fehleinschätzung. Natürlich sind wir als Programmierer ständig auf der Suche nach mehr Effizienz und gucken, wie die Anderen bestimmte Dinge lösen, das halte ich genauso wie jeder andere Programmierer. So wirst Du in meinem Framework (was ich auch für PHP entwickelt habe) absolut keine neuen Räder finden, ganz im Gegenteil, hier ein Code-Beispiel für eine komplette Anwendung, die an Einfachheit wohl kaum übertroffen werden kann, was den Code betrifft ;)
Zum Serialisieren meiner RoutingTable in eine bei jedem Request performant einzulesende Binary nutze ich uralte Algorithmen, die viele heutige Programmierer gar nicht kennen und wenn, es nicht lohnenswert finden, darüber nachzudenken.
Natürlich erfinde ich nicht den 'zigtausendsten Serializer neu, das wäre Zeitverschwendung, aber zyklische Datenstrukturen server- wie clientseitig kompatibel zu machen, darüber lohnt es sich schon nachzudenken, gerade in Hinblick auf die neuen Features moderner Browser, die so neu nun auch wieder nicht sind.
Gerade wir als Programmierer sollten ja nicht denken, dass alle Räder der Welt bereits erfunden sind und ordentlich rund laufen.
Viele Grüße!
Grundlage für Zitat #1973.
hi,
Ich will dir deine Erfahrung nicht absprechen, aber wir wissen beide, das du gerne mal das Rad neu erfindest und es dabei viel komplizierter machst als nötig ;)
Nochn Tipp: Was glaubst Du wohl, warum ich lieber mit Perl entwickle als mit PHP? Genau: Weil es da seit Jahren schon so viel gibt, was ich in PHP erst neu entwicklen müsste. Wie z.B. eine Methode des CGI-Moduls zum Erzeugen dynamischer Query_Strings.
Anderes Beispiel für einen uralten Hut:
array_merge
=> %merged = (%foo, %bar);
Da haben PHP-Porter das Mischen von Arrays neu erfunden :)
array_combine
=> geht in Perl mit einem Hash-Slice und ist auch nur eine Zeile
Oder _toString, mein Gott was für einen Hype PHP-Programmierer daraus machen, in Perl-OOP (overload) geht das seit Version 5.6 im Jahr 2000.
Oder nehmen wir uns des Thema an, wie eine PHP-Klassenhierarchie überschaubar im Dateisystem abgebildet werden kann, das ist in Perl von Anfang an einheitlich geregelt (Name der Package, Name der Datei, Doppelpunkt als Verzeichnistrenner) in PHP muss sich das jeder Entwickler selbst überlegen...
MfG ;)
hi,
Ich will dir deine Erfahrung nicht absprechen, aber wir wissen beide, das du gerne mal das Rad neu erfindest und es dabei viel komplizierter machst als nötig ;)
Nochn Tipp: Was glaubst Du wohl, warum ich lieber mit Perl entwickle als mit PHP?
Schade, dass Perl keine statische strenge Typisierung hat. =/
Für die regulären Ausdrücke muss man dennoch dankbar sein.
Mahlzeit,
Nochn Tipp: Was glaubst Du wohl, warum ich lieber mit Perl entwickle als mit PHP? Genau: Weil es da seit Jahren schon so viel gibt, was ich in PHP erst neu entwicklen müsste. Wie z.B. eine Methode des CGI-Moduls zum Erzeugen dynamischer Query_Strings.
Wenn ich immer die Wahl der Sprache hätte, meine Webanwendungen würden wohl zu 95% in C++ umgesetzt. Die restlichen 5% dann in Bash, wenn C++ oversized ist ;)
Viele wollen Java, wo es mir die Haare aufstellt. Das darf dann ein freier Programmierer machen, mehr als die nötigsten Grundlagen in Java verweigere ich :D
Div. Coding-Guides empfehlen ja eine Zeilenlänge von 90 und schreiben eine maximale Länge von 120 Zeichen vor.
Wenn ich einen Bildschirm habe auf den locker 200 Zeichen passen, ist mir so eine "Vorschrift" herzlich egal :-)
Mahlzeit,
Wenn ich einen Bildschirm habe auf den locker 200 Zeichen passen, ist mir so eine "Vorschrift" herzlich egal :-)
Dummerweise gibt es aber Kunden, denen das nicht egal ist. Ebenso hab ich Projekte, bei denen mal locker 20 Programmierer und mehr zusammenarbeiten müssen. Wenn da jeder sagt "ist mir egal, wie der Code aussieht", ist das Chaos vorprogrammiert.
Deshalb auch meine Aussage "Und nein, das generelle Ignorieren von Coding-Guides ist keine Alternative". Ich bin kein Hobbyprogrammierer, der ein paar Besucherzähler und Gästebücher für die eine kleine Webseite zusammenzimmert.
BTW: Mit deiner Einstellung hättest du bei mir nie eine Chance, einen Auftrag zu bekommen.
Dummerweise gibt es aber Kunden, denen das nicht egal ist.
Dann frag sie wie sowas gehandhabt werden soll, wenn sie schon drauf bestehen dass auch in unsinnigen Ausnahmefällen jede Regel eingehalten werden muss.
Wer motzt muss auch Lösungen anbieten.
Wenn da jeder sagt "ist mir egal, wie der Code aussieht", ist das Chaos vorprogrammiert.
Es soll ja nicht alles völlig egal sein. Aber in manchen Fällen geht die Realität eben über die Regel hinaus. Es heißt nicht umsonst "coding guideline" = Richtlinie. Nicht Gesetz.
Das macht man da wo es passt, was meistens der Fall ist. Aber nicht immer. Wer so eine Richtlinie auch da einsetzt wo sie negative Effekte hat (hier: die Lesbarkeit beeinflusst) der hat sie in meinen Augen den Sinn von sowas nicht verstanden.
Im Ernst, du fragst hier nach ob und wie du einen Link zerstückeln kannst, wie du ihn damit unleserlich machst damit du eine Regel einhältst die in diesem Fall ausnahmsweise sowas von unangebracht ist. Du machst gerade wegen wenigen Zeilen in deinem Quellcode Zeit und Geld kaputt und beschäftigst dich mit einer unglaublichen Lapalie, nur weil dein Kunde dich lieber für Regulierungswahn und blinden Gehorsam bezahlt als für vernünftiges und durchdachtes Handeln.
BTW: Mit deiner Einstellung hättest du bei mir nie eine Chance, einen Auftrag zu bekommen.
Wenn ich mich in deine momentane Lage versetze wäre mein erster Gedanke, einen so stressigen Kunden nicht zu haben wäre vielleicht gar nicht so schlimm :-)
Mahlzeit,
Dann frag sie wie sowas gehandhabt werden soll, wenn sie schon drauf bestehen dass auch in unsinnigen Ausnahmefällen jede Regel eingehalten werden muss.
Sie bestehen ja nicht darauf, dass es keine Ausnahmen gibt. Sie wollen einfach einen bestimmten Codeguide, weil entweder ein Teil der Anwendung schon damit existiert oder dieser bereits durch die internen Programmierer verwendet wird. Dadurch entsteht ein einheitliches Code-Bild.
Wer motzt muss auch Lösungen anbieten.
Auch die haben keine optimale Lösung für exakt dieses Problem ;) Deshalb würde mich ja interessieren, wie das andere Programmierer lösen.
Es soll ja nicht alles völlig egal sein. Aber in manchen Fällen geht die Realität eben über die Regel hinaus. Es heißt nicht umsonst "coding guideline" = Richtlinie. Nicht Gesetz.
Eben. Und bei meinem konkreten Beispiel geht es eben darum, diese Richtlinie sinnvoll umzusetzen.
Im Ernst, du fragst hier nach ob und wie du einen Link zerstückeln kannst,
Ja
wie du ihn damit unleserlich machst damit du eine Regel einhältst die in diesem Fall ausnahmsweise sowas von unangebracht ist.
Nein, ich frage ob es eine Möglichkeit gibt, den Guider einzuhalten ohne dass die Lesbarkeit leidet.
nur weil dein Kunde dich lieber für Regulierungswahn und blinden Gehorsam bezahlt als für vernünftiges und durchdachtes Handeln.
Wie kommst du da drauf? Hab ich das irgendwo geschrieben?
Wenn ich mich in deine momentane Lage versetze wäre mein erster Gedanke, einen so stressigen Kunden nicht zu haben wäre vielleicht gar nicht so schlimm :-)
Da wärst du der Erste, der einen Auftrag von mir als stressig empfindet ;)
Und du hast meine Lage völlig missverstanden. Es geht nicht darum, dass mich ein Kunde unter Druck setzt, ich muss das machen, mich interessiert einfach nur ob jemand eine sinnvolle und schöne Lösung kennt.
Aktuell liebäugel ich mit der Lösung, ein Smarty-Plugin zu schreiben, dass aus den Parametern einen Link zusammenbastelt. Sind maximal 20 Zeilen Code und richtig umgesetzt kann ich auch noch Features einbauen, die sonst zusätzliche Logik im Template erfordern. Dadurch wird wieder ein Stück Logik aus dem Template in den PHP-Code verschoben ;)
nur weil dein Kunde dich lieber für Regulierungswahn und blinden Gehorsam bezahlt als für vernünftiges und durchdachtes Handeln.
Wie kommst du da drauf? Hab ich das irgendwo geschrieben?
Nicht direkt, es klang nur danach. Solche Diskussionen gibts immer wieder, u.a. in der Realität. Manche sehen eine Regelung nur als Erfüllung einer Vorschrift. Darüber nachdenken und den eigentlichen Zweck sehen? Kommt nicht in Frage. Erkennen wann die Regel einem nicht hilft sondern eher einschränkt? Kann nicht sein!
Kunden gibts natürlich auch die so denken. Da ist es noch schwieriger die um umdenken zu bewegen.
Und du hast meine Lage völlig missverstanden.
Das passiert leider ab und zu. Tut mir leid wenns so ist.
Also eine Möglichkeit wäre es ja noch, den Link in einem String zusammenzubauen. Den kannst du in mehrere Zeilen umbrechen
"..." +
"...";
und dann als ganzes ausgeben.
Allerdings fehlt dann schon wieder die Durchgängigkeit beim Lesen.
Mahlzeit,
Kunden gibts natürlich auch die so denken. Da ist es noch schwieriger die um umdenken zu bewegen.
Ich bin in der glücklichen Lage, wenn mir ein Kunde nicht passt, lehne ich ihn ab ;)
Wenn einer auf die strikte Einhaltung irgendwelcher Regeln besteht, obwohl sie keinen Sinn machen oder sogar noch kontraproduktiv sind, mach ich halt nen anderen Auftrag.
Mahlzeit,
Div. Coding-Guides empfehlen ja eine Zeilenlänge von 90 und schreiben eine maximale Länge von 120 Zeichen vor.
Wie setzt ihr das üblicherweise bei Links um, wenn die z.B. so aussehen: (Smarty-Syntax)
<a href="index.php?module=images&image={$image.name}&action=delete&token={$token}">
Das versteht man ja so auch kaum...
Warum nicht eine Funktion bereitstellen, die die entsprechende URL generiert? Das kann Smarty doch hoffentlich wohl. Also etwa so:
~~~html
<a href="{$indexUrlGenerator.createDeleteImgsParams($ImagesToDelete)}">
Mahlzeit,
Warum nicht eine Funktion bereitstellen, die die entsprechende URL generiert? Das kann Smarty doch hoffentlich wohl. Also etwa so:
Hab ich grad geschrieben, bevor ich deinen Post gelesen hab :)
Ich schreib ein kleines Plugin für Smarty, das per Parameter den Link zusammenbaut.
Muss mir nur noch überlegen, wie ich sie am flexibelsten gestalte. Der Vorteil dabei, ich hab die Wrapper-Tabelle die die Keywords in Methodennamen übersetzt (wollte mal ein Kunde, angeblich besser für Google und ein echt gefragtes Feature) voll integrieren.
Ja, dieser Thread hat zwar "nur" indirekt die Lösung gebracht, aber die löst mir dafür mindestens 2 weitere Probleme :)
Auf jeden Fall danke an alle für die Anregungen