Plugins Interfaces

[Mirko Steiner]

wie wäre es mit sowas? oder muss contenido PHP 4 kompatibel bleiben?!

Code: Alles auswählen

// Declare the interface 'plugin'
interface plugin {
    public static function getTitle();
    public static function wantedVariables();
    public static function store($array);
    public static function getValue($entity);
    public static function canonicalVariables();
    public static function display();
}

[Mirko Steiner]

idee ist halt folgende, das erstmal durch ein interface festgelegt wird wie die methoden heissen. dadurch das die methoden static sind, muss von der klasse kein objekt instanziert werden, um diese zu benutzen.

ich habe mich bissel durch den contenido code gewühlt und habe an vielen stellen gesehen das im bezug auf plugins immer erst geprüft wird, ob die funktion überhaupt vorhanden ist. finde ich persönlich unschön.

functions.general.php: 1787

Code: Alles auswählen

			if (function_exists($entity."_".$plugin."_wantedVariables") && function_exists($entity."_".$plugin."_store"))

in php lässt sich auch feststellen von welchem interface eine klasse ist http://de.php.net/manual/en/function.is-a.php#72363

man könnte das da schon schöner gestallten!

[_wiewo_]

ich habe mich bissel durch den contenido code gewühlt und habe an vielen stellen gesehen das im bezug auf plugins immer erst geprüft wird, ob die funktion überhaupt vorhanden ist. finde ich persönlich unschön.

und was ist wennse mal nicht exisitert?
mit tausend fehlermeldungen weiter machen?

[Mirko Steiner]

deswegen gibts interfaces, das garantiert das die funktion da ist.

[_wiewo_]

sind denn immer alle funktionen in klassen?

und wenn muss das interface auch der klasse wirklich zugeordnet werden
und das im gesamten core ändern das ist glaub ein stück sehr harter arbeit

[kummer]

aber eine, die längst hätte gemacht werden müsse. interfaces zu verwenden ist da der ganz normale weg, um den man auf lange sicht nicht umhin kommt.

[_wiewo_]

das ding ist nur, aus der zeit wo contenido herkommt gabs meines wissen noch keine interfaces

[Mirko Steiner]

ärgerlich ist auch das sich bei der jetzt kommenden PHP 5.3.0 version da sich was ändert was schon lange cool wäre bzw. wo die php entwickler wieder gepfuscht haben .

ab 5.3.0 möglich:

Code: Alles auswählen

class Foo {
    pubilc static function Bar() { echo("Hello World"); }
}

$test = "Foo";
$test::Bar();

immoment behelfe ich mir so:

Code: Alles auswählen

$test = "Foo";
eval($test .'::Bar();');

PS: wenn man in einem interface methodennamen definiert, ist es in der implementtation egal ob die groß oder kleingeschrieben werden, PHP meckert da (noch) nicht rum...

[Mirko Steiner]

das ding ist nur, aus der zeit wo contenido herkommt gabs meines wissen noch keine interfaces

und? who the fuck cares? meiner meinung nach sollten ,,aktuelle'' contenido versionen auch nur ,,aktuelle'' stable PHP versionen unterstützen und nicht irgend ne uralte scheisse


--> Support for PHP 4 has been discontinued since 2007-12-31. Please consider upgrading to PHP 5.2. The release below is the last PHP 4 release.

[MichFress]

Es ist ja bereits der Fall, dass Contenido PHP 5.2 voraussetzt. Aber möchtest du denn gerne an einem sonnigen Wochenende das komplette Refactoring übernehmen? ,-)

[Mirko Steiner]

naja also nichts uberstuerzen, aber bei einer neuen version waere das schon etwas was man anpeilen koennte.
wenn man das jetzt ermoeglichen will, sollte man auch dafuer sorgen das die alte systematik weiterhin problemfrei funktioniert.

gibt nix aergerilches als wenn die version von 5.9.1 auf 5.9.2 wechselt und irgendwas komplett anders ist... geht einfach net sowas

[mfweb]

und? who the fuck cares? meiner meinung nach sollten ,,aktuelle'' contenido versionen auch nur ,,aktuelle'' stable PHP versionen unterstützen und nicht irgend ne uralte scheisse

--> Support for PHP 4 has been discontinued since 2007-12-31. Please consider upgrading to PHP 5.2. The release below is the last PHP 4 release.

Tja, und dann erzähl das mal den armen Teufeln, die keinen eigenen Server besitzen und auf ihren Provider/Webhoster angewiesen sind. Der Webhoster hat garantiert keine Lust, "ständig" auf den Server-Clustern die PHP-Version auf den gerade neusten Stand zu bringen, da es garantiert zahlreiche Kunden gibt, die Anwendungen verwenden, die die ältere Version voraussetzen. Und wenn deren Anwendungen dann nicht mehr ordentlich laufen (und es kein Update gibt), dann können sie ihren Kunden hinterherwinken!

Grüße
mfweb

PS: Und jetzt komme mir nicht mit dem Argument, den Webhoster zu wechseln. Bei so einer Entscheidung sollen mehrer Faktoren eine Rolle spielen. (abgesehen davon, dass ich selbst nicht betroffen bin)

[idea-tec]

denkbar wäre ja, dass man, wie das viele tun, ein(ig)e "aktuelle" versionen und halt die "aktuellste" version auf lager hat. Natürlich offiziell und nicht nur irgendwo bei sourceforge

wer software entwickelt, killt ja nicht gleich die vorgängerversion, weil er mit der neuen version von 4.x.y auf 5.a.b wechselt. dann kann sich jeder contenido-fan die für seinen server passende version downloaden.
wenn man dann noch hin geht und die foren nach versionen besser aufbröselt, nenne ich das schon wieder professionell und man müsste fast schon geld dafür verlangen

[_wiewo_]

die für seinen server passende version downloaden.

ist das ernst gemeint?

am besten noch für jede unterversion nen eigener download?
php 5.2.3 download
php 5.2.4 download
usw....

oO

Also ein Webapp sollte es immer nur in einer Version geben.
Was machen denn die ganzen Leutz die nicht wissen was wo wie läuft?

Ein CMS sollte man benutzen können auch wenn man KEINE ahnung hat.

[mfweb]

Das ist aber auch wesentlich mehr Aufwand, mehrere Version aktuell und sicherheitstechnisch aktuell zu halten. Und dafür, dass das "nur" ein Aushängeschild für 4fb ist und sie primär mit dem Bereitstellen von Contenido kein Geld verdienen ...

Es war ja schon ein Zugeständnis, dass sie den 4.6er Zweig noch am Leben gehalten haben.

Grüße
mfweb

EDIT: _wiewo_ war schneller