Entschlackung der API

Fragen zur Installation von CONTENIDO 4.9? Probleme bei der Konfiguration? Hinweise oder Fragen zur Entwicklung des Systemes oder zur Sicherheit?
Antworten

API vereinfachen und für eine schreibweise entscheiden?

Ja
4
80%
Nein
0
Keine Stimmen
Egal
1
20%
 
Abstimmungen insgesamt: 5

rethus
Beiträge: 1851
Registriert: Di 28. Mär 2006, 11:55
Wohnort: Mönchengladbach
Kontaktdaten:

Entschlackung der API

Beitrag von rethus » Mo 5. Jan 2015, 10:47

In der DB-Klasse gibt es teilweise doppelte Funktionen, die das gleiche erledigen (ALIAS).
Beispiel: num_rows() und numRows().

Warum ist dass so? Ich würde es lieber sehen, wenn man sich explizit für eine Schreibweise entscheiden, und die anderen Varianten in den künftigen Versionen als "DEPRECATED" auslaufen lassen würde.
So eine Schreibweise... mal mit, mal ohne unterstrich ist total verwirrend.
Denn entweder müsste man alle Funktionen so doppelt belegen, oder gar keine. Sonst ist man immer am rätseln : Gab es da eine Funktion mit unterstrich, oder CamelCase?

Solltet Ihr es aus gründen der Abwärtskompatibilität gemacht haben finde ich es ok, dies eine Version lang als Deprecated mitzuschleifen, und dann rausfallen zu lassen. Sooo extrem viel arbeit ist es ja nicht, die Volltext-Suchen-&-Ersetzen funktion über das Projekt zu jagen, und die vorkommen von den unterstrich-Varianten gengen die CamelCase zu ersetzen.
Could I help you... you can help me... buy me a coffee . (vielen ❤ Dank an: Seelauer, Peanut, fauxxami )

xstable.com: - HighSpeed Hosting, Domains, DomainReselling, Linux-Administration
suther.de: - App-Programierung, High-Performance-Webpages, MicroServices, API-Anbindungen & Erstellung

Software... ein Blick wert: GoogleCalender Eventlist, xst_dynamic_contentType

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: Entschlackung der API

Beitrag von Faar » Mo 5. Jan 2015, 12:42

Doch.
Es ist viel Arbeit.

Sind denn num_rows() und numRows() völlig identisch? Also richtig völlig, ohne abweichende Nebenerscheinungen bei seltenen Fällen?
Wenn ja, könnte man die intern umleiten auf eine Funktion und es wirklich als deprecated bezeichnen.
Gibt oder gab es da nicht einen Programmierstil (Coding Standards)?
Dort sollte es drin stehen, was wie geschrieben wird.

Ansonsten kann man nicht ungeprüft etwas umschreiben und somit übernehmen.
Wenn auch nur ein winziges Fitzelchen Unterschied ist, kann dieses ausmachen, dass es irgendwo nicht richtig läuft oder schlimmer noch, unbemerkt Fehler produziert bis es richtig kracht.
Zum Beispiel ist preg_match() nicht gleich eregi(), das sind ganz verschiedene Funktionen und ungetestet darf man das nie austauschen.
Tests an laufenden Systemen können aber durchaus sehr aufwändig und sehr Umfangreich sein, je nachdem wie das eingebaut ist und man an die Input-Daten kommt und welchen Output man generiert.

Darum kann ich die Umfrage nicht beantworten.
Ich wäre für eine Entschlackung der API, wenn es denn so einfach ginge und nur die Schreibweise anders ist.
Egal ist es mir nicht, das möchte ich schon genauer wissen.
Hast du nicht den Code der beiden Funktionen mit deinen Erläuterungen, wenn du schon mal dabei bist?
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

xmurrix
Beiträge: 3143
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Re: Entschlackung der API

Beitrag von xmurrix » Mo 5. Jan 2015, 13:45

Hallo zusammen,

die doppelten Funktionen sind aufgrund der Abwärtskompatibilität drin. Früher hieß es z. B. num_rows(), nun heißt es numRows(). Das wurde im Zuge der Vereinheitlichung der API auf die neue Schreibweise (camelBack Notation) umgestellt.

Es kann problematisch sein, wenn man das einfach entfernt, da viele vielleicht noch die alte Methode verwenden.

Grüße
xmurrix
CONTENIDO Downloads: CONTENIDO 4.10.1
CONTENIDO Links: Dokumentationsportal, FAQ, API-Dokumentation
CONTENIDO @ Github: CONTENIDO 4.10 - Mit einem Entwicklungszweig (develop-branch), das viele Verbesserungen/Optimierungen erhalten hat und auf Stabilität und Kompatibilität mit PHP 8.0 bis 8.2 getrimmt wurde.

rethus
Beiträge: 1851
Registriert: Di 28. Mär 2006, 11:55
Wohnort: Mönchengladbach
Kontaktdaten:

Re: Entschlackung der API

Beitrag von rethus » Mo 5. Jan 2015, 14:15

@Faar: Ja, sind identisch, weil die underscore-Variante nur ein Zeiger auf die CamelCase ist: http://api.contenido.org/con494/source- ... ml#980-988

Ich finde, dass zumindest in der Function-Description ein Hinweis hinterlegt sein sollte, dass diese Function "DEPRECATED" ist, zudem sollte ein Release festgelegt werden, ab wann es "GONE" is.
Faar hat geschrieben:Doch.Es ist viel Arbeit...Sind denn num_rows() und numRows() völlig identisch?
Du bist ne Spaßtrompete :lol: Hauptsache erstmal Bild

Ich schreibe es ja gerade, weil ich mich schon informiert habe, dass es nicht soooo viel arbeit ist. Es ist ein search&replace je doppelter Funktion (das ginge zur not sogar über ein migrations-scipt oder via "sed" auf ner Linux-Konsole. !!!
xmurrix hat geschrieben:Es kann problematisch sein, wenn man das einfach entfernt, da viele vielleicht noch die alte Methode verwenden.
Einfach entfernen geht nicht, aber in einem Release anstatt der Redirect auf die CamelCase-Function eine Fehlermessage ausgeben "cError", dann im nächsten Release verschwinden lassen. Ist in jedem größeren Softwareprojekt so gang und gäbe... Ihr kennt es doch auch von php selbst - z.B. bei erwähntem eregi(), dass es nicht mehr gibt.

In phpDoc gibt es dafür extra ein Flag: http://www.phpdoc.de/kongress/deprecated.html
Could I help you... you can help me... buy me a coffee . (vielen ❤ Dank an: Seelauer, Peanut, fauxxami )

xstable.com: - HighSpeed Hosting, Domains, DomainReselling, Linux-Administration
suther.de: - App-Programierung, High-Performance-Webpages, MicroServices, API-Anbindungen & Erstellung

Software... ein Blick wert: GoogleCalender Eventlist, xst_dynamic_contentType

Oldperl
Beiträge: 4250
Registriert: Do 30. Jun 2005, 22:56
Wohnort: Eltmann, Unterfranken, Bayern
Kontaktdaten:

Re: Entschlackung der API

Beitrag von Oldperl » Mo 5. Jan 2015, 15:11

rethus hat geschrieben:Ist in jedem größeren Softwareprojekt so gang und gäbe...
Wie du schon so schön sagst... "größeren" :roll:

Ein frohes Neues in die Runde! :D

Gruß aus Franken

Ortwin
ConLite 2.1, alternatives und stabiles Update von Contenido 4.8.x unter PHP 7.x - Download und Repo auf Gitport.de
phpBO Search Advanced - das Suchwort-Plugin für CONTENIDO 4.9
Mein Entwickler-Blog

rethus
Beiträge: 1851
Registriert: Di 28. Mär 2006, 11:55
Wohnort: Mönchengladbach
Kontaktdaten:

Re: Entschlackung der API

Beitrag von rethus » Mo 5. Jan 2015, 15:21

Ok, ich verbessere mich, in jedem "soliden" ;)
Could I help you... you can help me... buy me a coffee . (vielen ❤ Dank an: Seelauer, Peanut, fauxxami )

xstable.com: - HighSpeed Hosting, Domains, DomainReselling, Linux-Administration
suther.de: - App-Programierung, High-Performance-Webpages, MicroServices, API-Anbindungen & Erstellung

Software... ein Blick wert: GoogleCalender Eventlist, xst_dynamic_contentType

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: Entschlackung der API

Beitrag von Faar » Mo 5. Jan 2015, 17:44

xmurrix hat geschrieben: Froher hieß es ...
Nun, dann lasst uns froh und lustig sein :lol:

Gutes Neues Jahr, Xmurrix :D
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

Faar
Beiträge: 1915
Registriert: Sa 8. Sep 2007, 16:23
Wohnort: Brandenburg
Kontaktdaten:

Re: Entschlackung der API

Beitrag von Faar » Mo 5. Jan 2015, 17:55

rethus hat geschrieben:Du bist ne Spaßtrompete :lol: Hauptsache erstmal Bild

Ich schreibe es ja gerade, weil ich mich schon informiert habe, dass es nicht soooo viel arbeit ist.
Naja, ich bin Ingenieur, das steckt noch irgendwie drin, nichts ungeprüft zu verwenden. :roll:
Aber im Quelltext steht es ja drin, kann also ausgetauscht werden.
In dem Fall bin ich dafür... dass es entschlackt wird.

Aber Schrittweise, wie sonst in größeren Projekten auch.
Zuerst in der Doku, dann mit Warnhinweis und dann weg damit. :arrow:

@Oldperl Läster nicht so. Andere machens nicht besser, nur anders. :wink:

Und natürlich ein Gutes neues Jahr an alle!

P.S. Mich hatte das Wort "doppelte Funktion" irritiert.
Mag zwar technisch wie eine Funktion aufgebaut sein aber genau genommen wird nur auf eine einzige Funktion gezeigt. num_rows() macht nichts weiter als auf numRows() zu verweisen.
"Doppelte Funktion" ist das in meinen Augen nicht.
Fliegt der Bauer übers Dach, ist der Wind weißgott nicht schwach.

xmurrix
Beiträge: 3143
Registriert: Do 21. Okt 2004, 11:08
Wohnort: Augsburg
Kontaktdaten:

Re: Entschlackung der API

Beitrag von xmurrix » Di 6. Jan 2015, 09:54

@Faar & @all:
Auch euch ein frohes neues Jahr :)
rethus hat geschrieben:In phpDoc gibt es dafür extra ein Flag: http://www.phpdoc.de/kongress/deprecated.html
Der deprecated Flag wurde schon öfters in CONTENIDO verwendet, warum das hier nicht der Fall ist, müsste man mal nachprüfen, entweder man hat es vergessen oder es gab einen Grund dafür.

Bin auch für die Entschlackung der API, je weniger Schnittstellen es gibt, desto einfacher ist es für die Anwender...

Grüße
xmurrix
CONTENIDO Downloads: CONTENIDO 4.10.1
CONTENIDO Links: Dokumentationsportal, FAQ, API-Dokumentation
CONTENIDO @ Github: CONTENIDO 4.10 - Mit einem Entwicklungszweig (develop-branch), das viele Verbesserungen/Optimierungen erhalten hat und auf Stabilität und Kompatibilität mit PHP 8.0 bis 8.2 getrimmt wurde.

dominik.ziegler
Beiträge: 437
Registriert: Do 19. Jun 2008, 09:09

Re: Entschlackung der API

Beitrag von dominik.ziegler » Di 6. Jan 2015, 15:16

Generell sind wir natürlich auch für eine Entschlackung der API. Die Funktionen sind in der Tat bewusst nicht als deprecated markiert worden. Damals haben wir bei solchen Markierungen als deprecated immer einen Aufruf durch cDeprecated mitgeführt, um solche Aufrufe zu loggen. Das erschien uns bei diesen Datenbankfunktionen als etwas zu viel - wir befürchteten somit in kürzester Zeit das Log voll zu schreiben. Mit der Zeit haben wir allerdings auch die Silent Deprecations (keinen Eintrag im Logfile) eingeführt, genauso wie die Extended Deprecations, die nach 12 anstatt 6 Monaten "ablaufen".

Mehr Infos hierzu gibt es hier: https://docs.contenido.org/pages/viewpa ... Id=6258767

Übrigens sind die Deprecations der Versionen 4.9.0 (teilweise), 4.9.1 und 4.9.3 entgegen des Fristablaufs noch nicht entfernt worden. Das werden wir aber ggf. mit Version 4.9.7 nachholen, in welcher wir vermutlich weitere Funktionen deprecaten werden.

Aus genau dem gleichen Grund heißen die Generic DB Klassen Item und ItemCollection übrigens auch noch nicht cItem und cItemCollection. Wir behalten uns da vor, einige weitreichendere Änderungen einzuführen, wenn wir den neuen Klassennamen benutzen. Dazu gibt es aber aktuell noch keine konkreten Überlegungen.

Ich hoffe, ich konnte da etwas Licht ins Dunkel bringen. ;-)
Viele Grüße
Dominik

rethus
Beiträge: 1851
Registriert: Di 28. Mär 2006, 11:55
Wohnort: Mönchengladbach
Kontaktdaten:

Re: Entschlackung der API

Beitrag von rethus » Di 6. Jan 2015, 15:54

ja, danke Domenik,
nur zur Beseitigung aller Mis(st)verständnisse, ich meinte hier nur den Hinweis in der Methoden-Beschreibung (Doku: @deprecated: 2014-12-31), so dass die Entwickler wissen.... Ahhh, besser direkt an den anderen Funktionsnamen gewöhnen.

Eine Message aller im Core-Code als "bald veraltet" markierten Klassen auch in die Logs zu schreiben finde ich unnötig, zumindest wenn man nicht explizit auf LogLevel "PreMerge" gesetzt hat.
Ich finde es besser, im Step 2, wenn die Funktion deprecadet IST, eine aussagekräftige Fehlermeldung zu geben.

Ich erinnere mich auch schon des öfteren > 1GB Logs von Contenido auf nem Server gelöscht zu haben ⇒ ☠ :motz:
Daher gut, das Ihr sensibel mit dem Thema umgeht.
Ein schönes Benefit wäre übrigens im Backend den Loglever einstellen zu können... gibt es sowas schon?


In diesem Sinne, macht weiter so.
Keep the code clean!
Could I help you... you can help me... buy me a coffee . (vielen ❤ Dank an: Seelauer, Peanut, fauxxami )

xstable.com: - HighSpeed Hosting, Domains, DomainReselling, Linux-Administration
suther.de: - App-Programierung, High-Performance-Webpages, MicroServices, API-Anbindungen & Erstellung

Software... ein Blick wert: GoogleCalender Eventlist, xst_dynamic_contentType

dominik.ziegler
Beiträge: 437
Registriert: Do 19. Jun 2008, 09:09

Re: Entschlackung der API

Beitrag von dominik.ziegler » Di 6. Jan 2015, 15:58

Im Backend nicht, aber es gibt bereits ein paar Einstellmöglichkeiten über die PHP-Konfiguration.
https://docs.contenido.org/display/COND ... figuration
Viele Grüße
Dominik

Antworten