PHP oder SSI

[Helmut]

Hallo,
ich möchte eine Site erstellen, wo einige Dinge ausgelagert werden, zum schnellen bearbeiten, z. B. Navigation, etc.

Jetzt ist die Frage, ob ich die Auslagerung besser in SSI oder in PHP machen soll. Was ist sinnvoller?

Gruss
Helmut

[wahsaga]

hi,

Jetzt ist die Frage, ob ich die Auslagerung besser in SSI oder in PHP machen soll. Was ist sinnvoller?

die möglichkeit SSI zu nutzen, dürfte in den ganz billigen webspace-paketen idR. eher zur verfügung stehen, als PHP.

allerdings ist der funktionsumfang von SSI wirklich auf sehr wenige elementare sachen wie includes beschränkt.
so bald du "mehr" brauchst, wirst du dich einer serverseitigen scriptsprache wie php, perl o,ä, zuwenden wollen.

dann geht allerdings die umstellerei wieder los, die alten SSI-includes auf die neue technik umstellen, ggf. seitenendungen ändern, etc.
(denn sowohl SSI als auch PHP parsen zu lassen, ist a) nicht so ganz trivial zu bewerkstelligen, und b) geht natürlich unnötig auf die performance.)

ich würde dir bei der wahl zwischen SSI und PHP also eher zu PHP raten.

gruss,
wahsaga

[Jeena Paradies]

Hallo,

ich würde dir bei der wahl zwischen SSI und PHP also eher zu PHP raten.

Ich würde zu SSI raten weil er ja konkret gesagt hat dass er sachen wie Menüs auslagern will. Wenn es nichts weiter ist dann reicht SSI IMHO auf jeden Fall.

Grüße
Jeena Paradies

[wahsaga]

hi,

Ich würde zu SSI raten weil er ja konkret gesagt hat dass er sachen wie Menüs auslagern will.

_noch_ will er nur das machen.

Wenn es nichts weiter ist dann reicht SSI IMHO auf jeden Fall.

_noch_ würde es reichen, ja.

gruss,
wahsaga

[SabineP]

_noch_ würde es reichen, ja.

gruss,
wahsaga

Hi,

das Modul mod_include kann weit mehr als nur ein paar Seiten einbinden.

http://httpd.apache.org/docs/mod/mod_include.html

Ich würde auch zu SSI raten, weil es keinen Sinn macht einen Scriptinterpreter für etwas zu benutzen
was der Apache selbst schon kann.

Gruß Sabine

[wahsaga]

hi,

das Modul mod_include kann weit mehr als nur ein paar Seiten einbinden.

es kann mehr, ja.
_weit_ mehr halte ich allerdings auch schon wieder für übertrieben.

Ich würde auch zu SSI raten, weil es keinen Sinn macht einen Scriptinterpreter für etwas zu benutzen
was der Apache selbst schon kann.

wenn er sich jetzt darauf festlegen kann, dass der funtkionsumfang von SSI ihm alles bietet, was er je an dynamik brauchen wird, dann soll er es ruhig nehmen.

wenn aber nicht ausgeschlossen ist, dass später noch weitere dynamische/interaktive features hinzukommen sollen, dann würde ich gleich zu php, perl, o.ä. raten.

gruss,
wahsaga

[XaraX]

Hallo Helmut,

der Argumentation von wahsaga kann ich mich nur bedingungslos anschließen. Selbst ein etwaiges Argument, das auf den recht häufigen Gebrauch von PHP über CGI und den damit verbundenen Performanceverlust abzielt, würde für mich den Einsatz von SSI alleine nicht rechtfertigen.
Sicher ist auch hier das Einbinden von scripting möglich, wenn die Site im Zuge des Bedarfs dynamisch werden soll, aber, wie bereits treffend bemerkt, kann man sich diese Tür doch gleich mit PHP offen lassen.

Gruß aus Berlin!
eddi

[Jeena Paradies]

Hallo,

der Argumentation von wahsaga kann ich mich nur bedingungslos anschließen. Selbst ein etwaiges Argument, das auf den recht häufigen Gebrauch von PHP über CGI und den damit verbundenen Performanceverlust abzielt, würde für mich den Einsatz von SSI alleine nicht rechtfertigen.
Sicher ist auch hier das Einbinden von scripting möglich, wenn die Site im Zuge des Bedarfs dynamisch werden soll, aber, wie bereits treffend bemerkt, kann man sich diese Tür doch gleich mit PHP offen lassen.

Wozu gibt es denn dann überhaupt SSI wenn man es eigentlich nie benutzen kann weil man sich dann was verbaut?

Grüße
Jeena Paradies

[XaraX]

Hallo Jeena,

Ich bitte das nicht falsch zu verstehen, zu mal Deine Argumentation, daß SSI gerade für die von Helmut geäußerten Bedürfnisse die einfachste, naheliegenste und für diesen Zweg geschaffene Möglichkeit ist, auch meine Unterstützung genießt.

Prinzipiell stehe ich wirklich allen Technologien offen gegenüber (sogar JS [bitte nicht hauen] ;).

Die Frage "ob SSI oder PHP" scheidet sich für mich hier nicht im Grundsatz sondern nur im Hinblick auf die Zukunft der Site, die Helmut umgestallten möchte. Der Blick in künftig anstehende Anpassungen ist aber strikt von der Frage her betrachtet, nicht definiert worden, doch meiner Meinung (und um Meinungen wurde gebeten) lohn diese Blick, um sich viel Arbeit zu ersparen.

Wozu gibt es denn dann überhaupt SSI wenn man es eigentlich nie benutzen kann weil man sich dann was verbaut?

|
Wer sagt, das man es nicht benutzen kann?
Meiner Meinung nach sollte man es aber nicht, und sicher wird es auch ein noch nicht dargelegts Argument geben, was mich genauso schnell wieder umstimmen läßt. Ein Argument, daß ich nun SSI benutzen muß, nur weil es diese Technik gibt, tut es allerdings nicht.

Gruß aus Berlin!
eddi

[Jeena Paradies]

Hallo,

Wer sagt, das man es nicht benutzen kann?

Nein soll war die Frage.

Meiner Meinung nach sollte man es aber nicht, und sicher wird es auch ein noch nicht dargelegts Argument geben, was mich genauso schnell wieder umstimmen läßt. Ein Argument, daß ich nun SSI benutzen muß, nur weil es diese Technik gibt, tut es allerdings nicht.

Ich habe mich bisher auch noch nie so richtig mit SSI beschäftigt weil mir auch genau dieses Argument gefehlt hat, und nun hoffte ich es zu erfahren. Das einzige wäre dass man SSI aber PHP nicht zur verfügung hat. Es muss aber doch noch andere Argumente für SSI geben oder nicht?

Grüße
Jeena Paradies

[willie.de]

hallö,

nach meinem scheinbar gegenstandslosen komentar [pref:t=80729&m=468891] melde ich mich trotzdem nochmal zu wort.

Das einzige wäre dass man SSI aber PHP nicht zur verfügung hat. Es muss aber doch noch andere Argumente für SSI geben oder nicht?

nach meiner erfahrung spricht dafür, dass der funktionsumfang von SSI sehr begrenzt ist: es ist möglich, externe dateien (die der user immerhin nicht neu laden muss) sowie ein, zwei infos zur seite etc. einzubinden. das begrenzt den lernaufwand enorm.

• und genau das spricht auch dagegen... datenbankabfragen etc.: dafür ist SSI nicht gemacht.

grüße aus Leipzig
willie.de

[willie.de]

hallö,

ich würde dir bei der wahl zwischen SSI und PHP also eher zu PHP raten.

dito. hinzuzufügen wäre, dass SSI die links auf anker im dokument verhindert, was insbesondere auf längeren seiten sehr nervt...

grüße aus Leipzig
willie.de

[MudGuard]

Hi,

ich würde dir bei der wahl zwischen SSI und PHP also eher zu PHP raten.
dito. hinzuzufügen wäre, dass SSI die links auf anker im dokument verhindert, was insbesondere auf längeren seiten sehr nervt...

???

cu,
Andreas

[willie.de]

hallö,

dito. hinzuzufügen wäre, dass SSI die links auf anker im dokument verhindert, was insbesondere auf längeren seiten sehr nervt...

???

grübel... trügt mich da die erinnerung oder gibt es evtl. konfigurationen, die solche effekte verursachen?

ich bin mir _eigentlich_ ziemlich sicher, dass ich vor jahren den SSI-plan wieder über bord gehaunen hatte, weil das mit den ankern nicht funxte. ist aber ziemlich lange her. (und ich kanns nicht mehr nachvollziehen, weil der f...... provider mittlerweile meine domain (s. name) verschlampt hat. :-((( )

falls ich mich da irrte und SSI keine nachteile mit sich bringt, muss ich selbstmurmelnd meine meinung ändern...

grüße aus Leipzig
willie.de

[|project-sms.at|]

Ich rate dir zu PHP, da SSI nicht so viele Funktionen hat.

lg DJ Kamp