CMS - Der Dirigent » Entwicklung » DeDi-Entwicklung

Neue Umfrage | neues Thema | Antworten

Seiten: (2) [1] 2  ( Zum ersten neuen Beitrag )

Module: Unterscheidung Frontend - Backend

« Älteres Thema | Neueres Thema » Thema abonnieren | Thema versenden | Thema drucken

symap
  Geschrieben am: 30. Apr 2003 - 23:24


Unregistered








N'abend,

kann man unterscheiden, ob man den Code im Frontend oder Backend aufruft? Ziel ist es, den Code eines Moduls nur im Frontend aurufen zu können...konkret: ich baue gerade ein Modul, welches "die();" verwendet. Das sollte natürlich bei Bedarf nur im Frontend stattfinden, denn sonst ist das Editing des Contents im Backend nur bedingt möglich...

Thnx für Eure Hilfe...
Top
bjoern
Geschrieben am: 01. May 2003 - 02:03


Unregistered








Kannst du einfach so prüfen:

Im Backend ist die Variable $view gesetzt, die entweder auf 'preview' oder auf 'edit' steht (Damit dürfte sich auch erklären im welchem Modus dedi sich befindet)

Wenn Du etwas nur im Frontend ausführen willst, kannst Du das so abfangen:

CODE

if($view == 'preview' || $view == 'edit'){
echo 'backend';
}
else{
echo 'frontend';
}
Top
Sven777b
Geschrieben am: 01. May 2003 - 11:49


Unregistered








Finger weg von die() !!
es muss andere Mglichkeiten geben - aber brich niemals das Script ab - das verursacht dir nur unkalkulierbare Probleme. z.b. wird sämtliche Ausgabe gecached - wenn du das Script abbrichst, dann wird der Cache möglicherweise nicht ausgegeben. Ausserdem könnten andere Aktionen verlorengehen, die normalerweise nach ausführung des Contents noch durchgeführt werden.

Innerhalb von Modulen kannst du z.b. mit exit() arbeiten oder idealerweise mit einer If-Abfrage.
Top
bjoern
Geschrieben am: 01. May 2003 - 14:57


Unregistered








Jetzt bin ich aber neugierig.

Hab gerade in der Doku nachgeschaut, aber nach meiner jetzigen Auffassung machen exit() und die() genau das Gleiche, wobei bei die() noch ein Text übergeben werden kann. Oder irre ich mich da?

Top
Sven777b
Geschrieben am: 01. May 2003 - 15:49


Unregistered








exit() beendet das Script auf "relativ" normalem wege...
die() da gegen ist (wie der Name schon sagt) das brutale killen des gesamten Scriptes. Folge dessen ist ein Eintrag in der Error_log - es handelt sich immer um einen fehlerhaften Scriptabbruch

Aber du hast mich trotzdem eines Fehlers überführt Björn - ich meinte nämlich nicht exit() sondern break()
break() bricht nur den aktuellen Vorgang ab. Da Module mittels eval() ausgeführt werden, wird nur dieser Vorgang abgebrochen. Das Script macht dahinter weiter und führt somit noch ordnungsgemäß das ob_flush() aus. Nachteil: existiert keine übergeordnete Ebene, produziert break() einen Fehler "Cannot Break Level 0"

So oder so würde ich das gesamte Modul von einer If-Abfrage umschliessen, die deinen die()-Grund vorher schon abfragt und somit die Ausführung von vorneherein verhindert. Man kann alles abfragen ohne es wirklich zu tun.
Top
bjoern
Geschrieben am: 01. May 2003 - 16:14


Unregistered








besten Dank, wieder was gelernt biggrin.gif
Top
symap
Geschrieben am: 02. May 2003 - 07:36


Unregistered








Ok, verständlich, dass ein die() natürlich die krasseste Art, die Ausfürung zu unterbrechen. Ich suche nach einer Möglichkeit, die Ausführung anderer Module von einem Modul abhängig zu machen. Beispiel:

Modul1: Head
Modul2: Textarea
Modul3: Prüfung, ob nachfolgende Module angezeigt werden dürfen (Systemvariable=false)
Modul4: Textarea; aber nicht angezeigt, da Systemvariable im Modul3=false gesetzte wurde
Modul5: Bild; aber nicht angezeigt, da Systemvariable im Modul3=false gesetzte wurde

Ähnlich VB, bei dem man z.B. mit continue=false die Ausführung des Events unterbrinden kann, wäre eine solche Systemvariable doch recht hilfreich. Man kann das zwar alles zu Fuß in die Module reinbrigen, aber wäre eine solche Funktion nicht generell interessant?

BTW, können Variablen innerhalb eines Moduls in anderen Modulen weiterverwendet werden? Oder wird der Scope zwischen den Modulen neu initiiert (d.h. z.B. innerhalb einer Function)?
Top
symap
Geschrieben am: 02. May 2003 - 08:42


Unregistered








btw, ist sichergestellt, dass $view im Frontend nicht gesetzt ist? Die Abfrage
CODE
if (!view) {...}
bzw.
CODE
if ($view) {...}
gefällt mit etwas besser wink.gif
Top
Sven777b
Geschrieben am: 02. May 2003 - 11:40


Unregistered








das $view gesetzt wird ist ziemlich sicher und funktioniert auch recht gut. Ich bin mir nur nicht sicher, ob $view nicht auch beim preview gesetzt bleibt. Wenn ich mich jetzt recht erinnere kann $view verschiedene Values haben.

Zwischen den Modulen kannst du Variablen weiterreichen - sie werden nicht gelöscht.
Top
symap
  Geschrieben am: 02. May 2003 - 12:29


Unregistered








QUOTE (Sven777b @ May 2 2003, 11:40 AM)
Zwischen den Modulen kannst du Variablen weiterreichen - sie werden nicht gelöscht.

...das ist gut, aber was haltet Ihr von dem Vorschlag, eine standardisierte Variable für die ausführung von Modulen zu verwenden...mit einer standardisierten Variable muss man als admin nicht alle Modul auf diese Variablenabfrage anpassen, sondern kann interne mechanismen verwenden.

Mit einer solchen Variablen könnte die ordnungsgemäße Darstellung des Designs zumindest sichergestellt werden, da dann die weitere Verarbeitung nicht durch die() oder Konsorten abgebrochen werden muss. Die Variable müsste im Output gesetzt werden können und durch DEDI vor der Anzeige oder sogar Ausführung aller nachfolgenden Module ausgewertet werden. Das erstmalige Setzen auf "True" müsste für alle folgenden Module verbindlich sein und darf nicht nachträglich durch Module umgesetzt werden (können). Aber wenn die Auswertung vor dem Interpretieren des Output stattfindet, dann ist ein nachträgliches Zurücksetzen eh nicht mehr möglich. Die Gefahr "böswilliger" Module sollte idealerweise über eine Option in den allgemeinen DEDI-Einstellungen zu vermeiden sein (z.B. eine Option "Module immer anzeigen/interpretieren").





Ich bin der Meinung, dass die Module von DEDI für die spätere Akzeptanz des Systems entscheidend beitragen werden. Aus diesem Grund wären m.E. derartige Optionen Anreiz für Modul-Entwickler, das System attraktiver zu gestalten. Hierfür sind allerdings noch viele Dinge zu erledigen:

- definierte Schnittstellen
- möglichst standardisierte, modulübergreifende Optionen, damit eine Kommunikation/Interaktion zwischen den Modulen stattfinden kann
- Dokumentation der Modulerstellung (SEHR wichtig)
- Import/Export von Modulen (SEHR wichtig für die Verteilung von Modulen).
- weitere Felder für Module wie z.B. Autor, Website, eMail, Historie, SQL-Statements des Moduleintrags, Modul-spezifische SQL-Stements
- dediziertes Modul-Verzeichnis, in dem Modul-spezifische Daten, z.B. Grafiken, abgelegt werden können (z.B. /backend/moduls/<Modulname>)

Das Export-Format der Module könnte wie eine W16-INI-Datei aussehen:
CODE

[TITLE]
Mein erstes Modul

[DESCRIPTION]
Dies ist die Beschreibung des Moduls.

[AUTHOR]
Hinz und Kunz

[WEBSITE]
http://www.hinzundkunz.de

[EMAIL]
mein_erstes_modul@hinzundkunz.de

[DATE]
28.04.2003

[INPUT]
...hier kommt der Inpu-Code rein...

[OUTPUT]
...und der Output-Code...

[SQL]
SQL-Statement, das zum Einrichten des Moduls in DEDI notwendig ist...


Mit diesen Daten könnten Module dann als ZIP verteilt werden. Der manuelle Aufwand liesse sich für den Admin minimieren. Der Admin sollte sich zwar mit der Einrichtung von Modulen auskennen, aber den Leuten nicht das Leben etwas leichter machen ;-)

Naja, sind meine 2 Cents zu der Sache.
Top
Sven777b
Geschrieben am: 02. May 2003 - 12:54


Unregistered








ob ein Modul ausgeführt wird oder nicht, kann man bei der Template-konfiguration auswählen.
Eine Interaktion zwischen den Modulen ist meines Erachtens nach nicht empfehlenswert, weil es zu extremen Problemen führen kann. z.b. wenn ich ein Modul einsetze, welches ein Abbruch-Signal liefert und anschliessend eines , welches ich aber so oder so sehen will... Da nutzt auch keine Admin-Konfiguration.

Wer unbedingt solche Funktionen haben will, der kann die Modulintern lösen - aber ich bin der Meinung das der Festeinbau einer solchen Funktion nur eine weitere Fehlerquelle bedeutet und die Modulentwicklung unnötig kompliziert. Entscheidend ist aber , was Björn und Eppi dazu sagen.
Ich persönlich sehe es immernoch so, dass ich bei einem CMS gerne selber bestimmen möchte was es tut und was nicht. Es soll ja ein CMS und keine AI sein wink.gif

Zum System des Modulaufbaus: ich finde das sehr schön wenn die Module auf diese Weise präsentiert werden. Das ist in der Tat eindeutig und übersichtlich.
Dennoch blicke ich mal unnauffällig nach vorne und sehe da eine export/import Funktion für Module&Layouts wink.gif (wenns kein anderer macht, dann mach ich es. Denn das copy&paste geht mir auf den Keks)
Top
symap
Geschrieben am: 02. May 2003 - 13:36


Unregistered








QUOTE

ob ein Modul ausgeführt wird oder nicht, kann man bei der Template-konfiguration auswählen.
Eine Interaktion zwischen den Modulen ist meines Erachtens nach nicht empfehlenswert, weil es zu extremen Problemen führen kann. z.b. wenn ich ein Modul einsetze, welches ein Abbruch-Signal liefert und anschliessend eines , welches ich aber so oder so sehen will... Da nutzt auch keine Admin-Konfiguration.


okay, man kann es in der template-config einstellen, aber damit ist es statisch, und nicht dynamisch.

Das ein Modul immer angezeigt werden soll, könnte dann über eine Option (Checkbox "Modul immer anzeigen") im Template für das eingebundne Modul gelöst werden. Damit hätte der Admin noch voll Kontrolle über die nachfolgenden Module.


QUOTE
Wer unbedingt solche Funktionen haben will, der kann die Modulintern lösen - aber ich bin der Meinung das der Festeinbau einer solchen Funktion nur eine weitere Fehlerquelle bedeutet und die Modulentwicklung unnötig kompliziert.


Das Problem ist aber, dass in naher Zukunft DEDi mit verschiednen Modulen angereichert sein wird. Da viele Köche bekanntlich den Brei verderben, werden derartige Lösungen dann auf Einzelsystemen umgesetzt. damit besteht die Gefahr, dass Innovationen nicht verbreitet werden...m.E. eine Bremse für das Core-System... aber vielleicht ist da auch schon zu viel reininterpretiert...

QUOTE
Ich persönlich sehe es immernoch so, dass ich bei einem CMS gerne selber bestimmen möchte was es tut und was nicht. Es soll ja ein CMS und keine AI sein


...sehe ich auch so, aber ich sehe da ehrlich gesagt keine gefahr drin...und da wäre ja keine böse AI, die den Benutzer schlechtes will, es wäre eine Steigerung der Automation. Wenn Sie denn gut dokumentiert ist, dann ist da nichts geheimnisvolles dran...

QUOTE
Denn das copy&paste geht mir auf den Keks)


...ach, sag bloß ;-) für die Distribution von Modulen ist das Copy&Paste-Handling der absolute Tod...ich würde mich ja gerne für die Implementierung anbieten. das wäre mal wieder eine aufgabe mit ziel tongue.gif wenn ihr denn einen nervkeks mehr ertragen könnt rolleyes.gif
Top
bjoern
Geschrieben am: 02. May 2003 - 19:49


Unregistered








QUOTE
...ach, sag bloß ;-) für die Distribution von Modulen ist das Copy&Paste-Handling der absolute Tod...ich würde mich ja gerne für die Implementierung anbieten. das wäre mal wieder eine aufgabe mit ziel  wenn ihr denn einen nervkeks mehr ertragen könnt


OK, kannst Dich an der Alpha2 gleich dran versuchen.... aber merke Dir: Nichts ist nerviger als Eppi und Björn als Projektleiter wink.gif

Zu Deinen weiteren Überlegungen:

Ja, wir sind Neuerungen immer aufgeschlossen. Momentan sind wir aber erst mal dabei, vorhandenes rund für die Final zu machen. Da ist noch eine Menge zu tun... wie soll ich mich ausdrücken, vielleicht so: In DEDI vorhandenen Sachen optimieren und verbessern (Beispiel Modulimport/ Export) ist ok, große Änderungen am System (z.B. globale Variablen) aber erst, wenn die 1.0 draussen ist, sonst wird die nämlich nie fertig. rolleyes.gif
Top
symap
  Geschrieben am: 02. May 2003 - 22:42


Unregistered








QUOTE (bjoern @ May 2 2003, 07:49 PM)
große Änderungen am System (z.B. globale Variablen) aber erst, wenn die 1.0 draussen ist, sonst wird die nämlich nie fertig. rolleyes.gif

okay, ich nehm' dich beim wort wink.gif
Top
bjoern
Geschrieben am: 03. May 2003 - 04:34


Unregistered








biggrin.gif

Mir ist noch eingefallen bei dem Importformat: Es sollte XML sein und keine Win- ini. Wir haben jetzt mit unseren DEDI- Tags damit angefangen und wollen das auch weiter durchziehen. Dürfte aber kein Problem sein, da es z.B. bei PEAR sehr gute XML- Parser gibt. Von dem PHP- eigenen Parser Sablaton möchte ich noch Abstand nehmen, um eine Abwärtskompatibilität zu haben. Beispiel:


CODE

<modul name="xyz">
<title>Mein Modul</title>
<author>Mein Name</author>
<input><b>"Hallo Welt"</b></input>
.......
</modul>
Top

Thema wird von 0 Benutzer gelesen (0 Gäste und 0 Anonyme Benutzer)
0 Mitglieder:

16 Antworten seit 30. Apr 2003 - 23:24

Thema abonnieren | Thema versenden | Thema drucken


Seiten: (2) [1] 2 

<< Zurück zu DeDi-Entwicklung

Neue Umfrage | neues Thema

Home | Das Projekt | Download | Entwicklung | Dokumentation | Forum | Impressum