Ankündigung

Einklappen
Keine Ankündigung bisher.

Pluginfähigkeit von Webanwendungen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Pluginfähigkeit von Webanwendungen

    Hi, ich weiß dass Plugins schon häufiger besprochen wurden, aber ich hab noch keinen für mich interessanten Treffer gefunden.

    Deswegen wollte ich euch mal zu meinem Fall befragen.

    Wir entwickeln Webanwendungen die für mehrere verschiedene Kunden zur Verfügung gestellt werden sollen. Jetzt ist natürlich klar, dass jeder Kunde irgendwo mit spezifischen Wünschen kommt und sich die Anwendung an eben
    diesen Wünschen orientieren muss.

    Wir hatten an dieser Stelle über eine Plugin Schnittstelle nachgedacht. Für die wir aber noch keinen richtigen Ansatz gefunden haben.

    Vorstellen könnt ihr euch das so, dass die Oberfläche der Anwendung je nach Kundenwunsch spezielle Erweiterungen aufweisen muss.

    Beispiel: eine Liste in der Kunde X zusätzlich zum Standard eine weitere Information angezeigt bekommen möchte.

    Na ich denke ihr könnt euch vorstellen was gemeint ist. Ich bräuchte hier einen Mechanismus, der ohne Änderungen am Standard mir die Möglichkeit bietet mich in den Standard einzuklinken und Ergänzungen vorzunehmen.

    Das Problem, was ich momentan habe, ist, das ich nicht weiß wie ich mich zu einem späteren Zeitpunkt in die Erzeugung der Website einklinken kann.

    Ich müsste ja zusätzlich zu der Standard-Liste eine Ergänzung vornehmen.
    Was mir in php wohl so nicht möglich ist. Wie kann ich das nun angehen ?

    Ich kenne entsprechende Ansätze aus anderen Entwicklungsumgebungen, die aber umfangreiche Frameworks für das erzeugen Grafischer Oberflächen anbieten.

    Könnte man sich hier via jQuery einklingen und nachträglich Ergänzungen vornehmen ? Technisch halte ich das für möglich, aber ist das empfehlenswert ?

    Wir würdet ihr versuchen solche Fälle abzudecken ?

    Gruß
    Jan

  • #2
    Kommt drauf an... geht es wirklich nur um die Oberfläche, so dass die unterschiedlichen Anforderungen mit jeweils individuellem JavaScript abgedeckt werden können?

    Was meinst du mit "späterer Zeitpunkt" und "Standard-Liste"?

    Geht es darum, dass die Anwendungen auf einem gemeinsamen Server laufen und auf die selbe Code-Basis zugreifen? Dann würde ich erstmal zwischen Core, Anwendung und Plugins trennen, etwa so:

    Code:
    - core (dein "Standard")
    - plugins (alle möglichen Zusatzfunktionen zentral)
     - zusatzfunktion1
     - zusatzfunktion2
    
    - app1 (eine Anwendung)
     - core (symlink)
     - plugins
      - zusatzfunktion1 (symlink)
     - app (anwendungsspezifischer Code, Bootstrap)
    Für die Entwicklung der Plugins in PHP bietet sich beispielsweise das Observer-Pattern an.
    [IMG]https://g.twimg.com/twitter-bird-16x16.png[/IMG][URL="https://twitter.com/fschmengler"]@fschmengler[/URL] - [IMG]https://i.stack.imgur.com/qh235.png[/IMG][URL="https://stackoverflow.com/users/664108/fschmengler"]@fschmengler[/URL] - [IMG]http://i.imgur.com/ZEqflLv.png[/IMG] [URL="https://github.com/schmengler/"]@schmengler[/URL]
    [URL="http://www.schmengler-se.de/"]PHP Blog[/URL] - [URL="http://www.schmengler-se.de/magento-entwicklung/"]Magento Entwicklung[/URL] - [URL="http://www.css3d.net/"]CSS Ribbon Generator[/URL]

    Kommentar


    • #3
      Ein Event-System wäre in meinen Augen ein praktikabler Ansatz,

      Kommentar


      • #4
        Was hat das denn mit Event zu tun ?

        Ein zusätzlich anzuzeigendes Feld entspricht einem Event ??

        wie ich mich zu einem späteren Zeitpunkt in die Erzeugung der Website einklinken kann.
        Du trennst doch hoffentlich Verarbeitung und Ausgabe (EVA-Prinzip).
        Also klinkst Du Dich vor jeglicher Ausgabe ein und änderst den Inhalt der Ausgabe entsprechend
        den Kundenanforderungen.

        prozedural:
        PHP-Code:
        foreach (glob("plugins/*.php") as $plugin) {

             include 
        plugin;

        OOP-Frameworks bieten andere Ansätze.

        Aber wir wissen eben nicht wie Deine Website aufgebaut ist.
        Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

        Kommentar


        • #5
          Ein zusätzlich anzuzeigendes Feld entspricht einem Event ??
          Natürlich nicht. Wie kommst Du darauf? Man könnte ein Plugin für ein Event registrieren, das beim Anzeigen der oben genannten Informationen aufgerufen wird. Als Parameter könnte z. B. dann die bisherige, auszugebenden Information übergeben werden, die dann von dem Plugin erweitert wird.

          Also klinkst Du Dich vor jeglicher Ausgabe ein und änderst den Inhalt der Ausgabe entsprechend
          den Kundenanforderungen.
          Hier machst Du es doch ähnlich.

          Kommentar


          • #6
            Eventsystem (Hooks, Callback) ist schon richtig. Fraglich ist halt, wie granular man das anlegt. Wenn das bis auf Ebene der Formulare oder Listen runtergeht, würde ja bspw. bei jeder Zeile eine Nachricht erzeugt.
            [COLOR="#F5F5FF"]--[/COLOR]
            [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
            „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
            [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
            [COLOR="#F5F5FF"]
            --[/COLOR]

            Kommentar


            • #7
              Ich würde das, so wie das klingt, auch eher mit überschriebenen Templates/Klassen arbeiten, da man vorher meist nie weiß, wie weit die Unterscheidungen gehen.

              Kommentar


              • #8
                Is irgendwie schwer zu erklären. Die Web Appl. ist keine Website im dem Sinne, sondern schon eher wie ein Desktop Programm aufgebaut.

                Der Core ist in dem Moment der Mindestfunktionsumfang der gewährleistet sein soll. Kundenspezifische Wünsche sollen jetzt als Ergänzung eingepflegt werden.

                Der "spätere Zeitpunkt" ist quasi jeder nach Entwicklung des Cores. Ich will hier vermeiden immer wieder am Core rumbasteln zu müssen, wenn ein Zusatz benötigt wird. Wohin das führt kann man sich ja ausmalen.

                Die "Standard Liste" stell dir ganz simpel als Tabelle vor. Kunde X möchte jetzt in dieser Tabelle eine spezifische Spalte angezeigt bekommen. Wie bekomme ich jetzt diese Spalte nachträglich in die Oberfläche ohne in der Basisversion also im Standard so n zeug wie if(plugin vorhanden) schreib hier was zusätzlich rein; zu hinterlegen.

                Das spricht eben gegen solche Ansätze:
                PHP-Code:
                foreach (glob("plugins/*.php") as $plugin) {

                     include 
                plugin;

                Stell dir vor Kunde Y will nur ne Überschrift oder dergleichen geändert haben.
                Da würde ich aus wenn - dann abfragen nicht mehr rauskommen.

                Ich würde das, so wie das klingt, auch eher mit überschriebenen Templates/Klassen arbeiten, da man vorher meist nie weiß, wie weit die Unterscheidungen gehen.
                Könntest du den Ansatz noch etwas genauer erläutern ?

                Kommentar


                • #9
                  Zitat von Schneidi Beitrag anzeigen
                  Wie bekomme ich jetzt diese Spalte nachträglich in die Oberfläche ohne in der Basisversion also im Standard so n zeug wie if(plugin vorhanden) schreib hier was zusätzlich rein; zu hinterlegen.

                  Das spricht eben gegen solche Ansätze:
                  PHP-Code:
                  foreach (glob("plugins/*.php") as $plugin) {

                       include 
                  plugin;

                  Ich sehe da keinen Widerspruch. Dass man zusätzliche Funktionalität mit Plugin bereitstellen kann ohne den Core zu ändern ist hier schon mehrmals gesagt worden: Observer, Events, Hooks - mit den Stichworten solltest du zumindest im Ansatz fündig werden. Prinzipiell heißt das, der Core meldet (an deinem Beispiel) "ich rendere jetzt mit folgenden Daten die Tabelle" und das Plugin, das diesem Event lauscht ändert selber diese Daten, fügt also die neue Spalte hinzu. Der Core arbeitet dann mit den veränderten Daten weiter ohne etwas vom Plugin wissen zu müssen.

                  Das geht am besten wenn du konsequent objektorientiert arbeitest, ist aber auch mit Callback-Funktionen und Referenzen umsetzbar.
                  [IMG]https://g.twimg.com/twitter-bird-16x16.png[/IMG][URL="https://twitter.com/fschmengler"]@fschmengler[/URL] - [IMG]https://i.stack.imgur.com/qh235.png[/IMG][URL="https://stackoverflow.com/users/664108/fschmengler"]@fschmengler[/URL] - [IMG]http://i.imgur.com/ZEqflLv.png[/IMG] [URL="https://github.com/schmengler/"]@schmengler[/URL]
                  [URL="http://www.schmengler-se.de/"]PHP Blog[/URL] - [URL="http://www.schmengler-se.de/magento-entwicklung/"]Magento Entwicklung[/URL] - [URL="http://www.css3d.net/"]CSS Ribbon Generator[/URL]

                  Kommentar


                  • #10
                    der Core meldet (an deinem Beispiel) "ich rendere jetzt mit folgenden Daten die Tabelle"
                    Genau das ist ja das Problem bei der Geschichte. Das bedingt, dass ich jeder Zeit bei egal welcher Aktion immer die verwendeten Daten an evtl. Plugins weiter reiche. Das würde aber darin eskalieren, dass mein Core voll von Abfragen nach möglichen Plugins wäre.

                    Es bleibt ja nicht bei, ich rendere jetzt die Tabelle... Was ist mit ich rendere jetzt die Überschrift 1, jetzt die Überschrift 2, jetzt Button 1 ... etc.

                    Da ich in der Core Entwicklung nicht weiß wo ich später evtl. Änderungen vornehmen muss.
                    PHP-Code:
                    foreach (glob("plugins/*.php") as $plugin) { 

                         include 
                    plugin

                    Dieser Ansatz bedingt, dass ich genau weiß wo ich später die Funktionalität eines Plugin greifen lassen will.

                    Kommentar


                    • #11
                      Zitat von Schneidi Beitrag anzeigen
                      Genau das ist ja das Problem bei der Geschichte. Das bedingt, dass ich jeder Zeit bei egal welcher Aktion immer die verwendeten Daten an evtl. Plugins weiter reiche. Das würde aber darin eskalieren, dass mein Core voll von Abfragen nach möglichen Plugins wäre.

                      Es bleibt ja nicht bei, ich rendere jetzt die Tabelle... Was ist mit ich rendere jetzt die Überschrift 1, jetzt die Überschrift 2, jetzt Button 1 ... etc.

                      Da ich in der Core Entwicklung nicht weiß wo ich später evtl. Änderungen vornehmen muss.
                      PHP-Code:
                      foreach (glob("plugins/*.php") as $plugin) { 

                           include 
                      plugin

                      Dieser Ansatz bedingt, dass ich genau weiß wo ich später die Funktionalität eines Plugin greifen lassen will.
                      Logischerweise gibts nur Hooks und Callbacks dort wo du dir bewusst bist, dass es solche geben könnte.

                      Ist das nicht der Fall, müsste es möglich sein deine Core-Klassen zu überschreiben und diese deinem System unterzujubeln. Dort sind dann eigene Hooks drin sozusagen...

                      Kommentar


                      • #12
                        Zitat von Schneidi Beitrag anzeigen
                        Was ist mit ich rendere jetzt die Überschrift 1, jetzt die Überschrift 2, jetzt Button 1 ... etc.
                        Da denkst du jetzt wahrscheinlich zu feingranular. Ich nehme nicht an, dass jede Überschrift von einem eigenen Objekt erzeugt wird also gehen wir mal von einer View-Klasse aus, die eine bestimmte Seite repräsentiert und u.a. folgendes enthält:

                        PHP-Code:
                        class SomePageView
                        {
                          protected 
                        $title;

                          
                        /*
                           * Hier wird die Überschrift festgelegt
                           */
                          
                        public function setTitle($title)
                          {
                            
                        $this->title $title;
                          }
                          public function 
                        getTitle()
                          {
                            return 
                        $this->title;
                          }

                        // ...

                        In einem wie auch immer gearteten Template wird $title als Überschrift 1 ausgegeben, das selbe gilt für andere Überschriften, Button-Beschriftungen, etc. Im Kern passiert dazu etwa folgendes:
                        PHP-Code:
                        $view->setTitle('Standard-Überschrift');
                        $eventBus->triggerEvent('before_render''SomePageView'$view);
                        $view->render(); 
                        Und im Event-Handler des Plugins, der durch triggerEvent() indirekt aufgerufen wird:
                        PHP-Code:
                        public function onBeforeRender(SomePageView $view)
                        {
                          
                        $view->setTitle('Neue Überschrift');

                        Das übergebene $view-Objekt ist das selbe, was anschließend gerendert wird und enthält nun eine neue Überschrift. In der selben Methode kannst du beliebig viele Attribute der View ändern ohne zusätzliche Events einbauen zu müssen.

                        In dem Beispiel wird jetzt zwar nur der Text im <h1> Element bearbeitet aber das kannst du ja so flexibel wie nötig erweitern. Denkbar wäre auch ein Event "after_render" mit DOMDocument als Parameter so dass du dort das fertige HTML nochmal beliebig manipulieren kannst.
                        [IMG]https://g.twimg.com/twitter-bird-16x16.png[/IMG][URL="https://twitter.com/fschmengler"]@fschmengler[/URL] - [IMG]https://i.stack.imgur.com/qh235.png[/IMG][URL="https://stackoverflow.com/users/664108/fschmengler"]@fschmengler[/URL] - [IMG]http://i.imgur.com/ZEqflLv.png[/IMG] [URL="https://github.com/schmengler/"]@schmengler[/URL]
                        [URL="http://www.schmengler-se.de/"]PHP Blog[/URL] - [URL="http://www.schmengler-se.de/magento-entwicklung/"]Magento Entwicklung[/URL] - [URL="http://www.css3d.net/"]CSS Ribbon Generator[/URL]

                        Kommentar


                        • #13
                          Also ich persönlich verstehe unter Core etwas anderes. Und da wird auch nicht dran geschraubt oder künstlich aufgebohrt.
                          Die Library stellt bei mir meist Basisklassen bereit, die oft noch keine konkrete Implementierung anbieten. Diese mache ich dann applikationsspezifisch per Lib-Extension. Damit hat man dann gewährleistet, dass sich z.B. auch mehrere Apps die gleiche Bibliothek teilen können. Und ganz zum Schluss pfropfe ich dort noch Module drauf, UI-Sachen, Formularverarbeitung etc. Die sind dann stark applikationsspezifisch und auch von den Bibiotheken abhängig.
                          [COLOR="#F5F5FF"]--[/COLOR]
                          [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                          „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                          [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                          [COLOR="#F5F5FF"]
                          --[/COLOR]

                          Kommentar


                          • #14
                            Okay, das ist jetzt eine Definitionsfrage. Was ich hier als Core bezeichnet habe ist eigentlich die Zusammenfassung von Core + gemeinsamen Komponenten. Es war ja die Rede von mehreren ähnlichen Anwendungen bzw. einer Basisanwendung, die mit unterschiedlichen Erweiterungen ausgestattet wird.

                            Ich hoffe, es ist trotzdem verständlich geworden.
                            [IMG]https://g.twimg.com/twitter-bird-16x16.png[/IMG][URL="https://twitter.com/fschmengler"]@fschmengler[/URL] - [IMG]https://i.stack.imgur.com/qh235.png[/IMG][URL="https://stackoverflow.com/users/664108/fschmengler"]@fschmengler[/URL] - [IMG]http://i.imgur.com/ZEqflLv.png[/IMG] [URL="https://github.com/schmengler/"]@schmengler[/URL]
                            [URL="http://www.schmengler-se.de/"]PHP Blog[/URL] - [URL="http://www.schmengler-se.de/magento-entwicklung/"]Magento Entwicklung[/URL] - [URL="http://www.css3d.net/"]CSS Ribbon Generator[/URL]

                            Kommentar


                            • #15
                              am core wird definitiv nicht gebastelt, der core untersteht idr. einem völlig unabhängigen releasezyklus und hat mit dem projekt nichts zutun. der core sollte unabhängig getestet sein.

                              Kommentar

                              Lädt...
                              X