Warning: Constant ABSPATH already defined in /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-config.php on line 28 Warning: Cannot modify header information - headers already sent by (output started at /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-config.php:28) in /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-includes/rest-api/class-wp-rest-server.php on line 1723 Warning: Cannot modify header information - headers already sent by (output started at /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-config.php:28) in /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-includes/rest-api/class-wp-rest-server.php on line 1723 Warning: Cannot modify header information - headers already sent by (output started at /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-config.php:28) in /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-includes/rest-api/class-wp-rest-server.php on line 1723 Warning: Cannot modify header information - headers already sent by (output started at /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-config.php:28) in /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-includes/rest-api/class-wp-rest-server.php on line 1723 Warning: Cannot modify header information - headers already sent by (output started at /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-config.php:28) in /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-includes/rest-api/class-wp-rest-server.php on line 1723 Warning: Cannot modify header information - headers already sent by (output started at /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-config.php:28) in /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-includes/rest-api/class-wp-rest-server.php on line 1723 Warning: Cannot modify header information - headers already sent by (output started at /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-config.php:28) in /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-includes/rest-api/class-wp-rest-server.php on line 1723 Warning: Cannot modify header information - headers already sent by (output started at /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-config.php:28) in /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-includes/rest-api/class-wp-rest-server.php on line 1723 {"id":594,"date":"2012-10-04T14:14:53","date_gmt":"2012-10-04T13:14:53","guid":{"rendered":"http:\/\/www.florian-oeser.de\/?p=594"},"modified":"2013-07-03T13:48:56","modified_gmt":"2013-07-03T12:48:56","slug":"wissenschaftliches-arbeiten","status":"publish","type":"post","link":"http:\/\/www.florian-oeser.de\/2012\/10\/04\/wissenschaftliches-arbeiten\/","title":{"rendered":"Wissenschaftliches Arbeiten (Updated: 03.07.13)"},"content":{"rendered":"

Blog-Eintrag zum Modul Wissenschaftliches Arbeiten<\/em><\/a> an der Beuth Hochschule f\u00fcr Technik im Semester SS13.<\/p>\n

Allgemeine Informationen<\/h4>\n

Name: Florian Oeser
\nMatrikelnummer: 780586
\nGruppe: B
\neMail: florian.oeser(at)gmail.com<\/p>\n

Gew\u00e4hlter Artikel<\/h4>\n
\n

Wolfinger, Reinhard, et al. „Adding genericity to a plug-in framework.“\u00a0ACM SIGPLAN Notices.<\/em>Vol. 46. No. 2. ACM, 2010.<\/p>\n

Abstract<\/h4>\n

Im Bereich der Softwareentwicklung spricht man von einem Plug-in, wenn eine oder mehrere Softwarekomponenten eine bestehende Anwendung um eine bestimmte Funktionalit\u00e4t erweitern (ohne Neustart). Dadurch lassen sich Anwendungen optimal und kosteneffizient skalieren.<\/p>\n

Im Kern basiert das Paper auf einem Plug-in Framework f\u00fcr Microsoft .NET<\/em>, welches ebenfalls von einem Teil der Autoren entwickelt wurde. Das Plux.NET<\/em> getaufte Framework erm\u00f6glicht Software-Kompositionen durch eine Art „Plug & Play“-Mechanismus.<\/p>\n

Plux.NET<\/em> definiert ein Kompositionsmodel und f\u00fchrt dabei die \u201eSlot & Plug\u201c-Metapher ein. Ein Slot spezifiziert einen Vertrag (Interface) und eine Liste von Parametern mit deren Namen und Typen. Dies geschieht deklarativ \u00fcber .NET-Attribute<\/em> (Metadaten), welche sp\u00e4ter zur Laufzeit \u00fcber Reflection ausgelesen werden k\u00f6nnen. Ein Plug stellt eine konkrete Implementierung des korrespondierenden Slot-Interfaces dar. Die Angabe des passenden Slots sowie die Angabe konkreter Parameterwerte, geschieht wieder deklarativ.<\/p>\n

Plux.NET<\/em> selbst ist Plug-in basiert. Das bedeutet, das die eigene Anwendung ebenfalls als Plug-in implementiert werden muss. Das Framework definiert einen entsprechenden Slot (Interface), welcher mit einem passenden Plug in der eigenen Anwendung implementiert wird. Wird nun Plux.NET<\/em> gestartet, sucht dieses nach eben solchen Plug’s und startet seinerseits die eigentliche Anwendung, da diese den besagten Slot implementiert hat. Weiterhin muss die Anwendung einen Slot definieren (\u00f6ffnen), welches wieder einen konkreten Plug aufnehmen kann. Findet nun das Plux.NET<\/em>-Framework zur Runtime ein entsprechendes Plug, welches zu dem definierten Slot passt, wird dieses geladen und der Anwendung \u00fcbergeben. Der Anwendung wurde also ein Plug-in hinzugef\u00fcgt.<\/p>\n

Zusammenfassend besitzt Plux.NET<\/em> ein Kompositionsmodel, welches eine Anwendung aus Komponenten zusammenf\u00fcgt, welche wiederum aus einer definierten Anforderung (Slot) und einer passenden Implementierung (Plug) bestehen. Das Framework verbindet diese automatisch anhand der deklarierten Metadaten.<\/p>\n

Sollen nun aber Komponenten an unterschiedlichen Stellen oder zu unterschiedlichen Zwecken in der Anwendung zum Einsatz kommen (wiederverwendet werden), br\u00e4uchte man verschieden ausgepr\u00e4gte Metadaten. Beispielsweise k\u00f6nnte man sich zwei Grids in zwei verschiedenen Views vorstellen, welche beide wiederum an zwei verschiedene Datenquellen gebunden werden sollen. Implementiert man die Grid’s als Slot’s und die Datenquellen als Plug’s, w\u00fcrde das Kompositionsmodel automatisch beide Datenquellen an beide Grid’s binden. Dies ist nicht gew\u00fcnscht, schlie\u00dflich sollte das Grid in einer bestimmten View auch nur an die f\u00fcr es vorgesehene Datenquelle gebunden werden.<\/p>\n

Die Plug’s m\u00fcssten also selektiv mit den Slot’s verbunden werden. Ohne einen generischen Ansatz m\u00fcssten die Kompositionen programmatisch definiert werden. Es w\u00e4re auch denkbar die Metadaten anzupassen und f\u00fcr jede View ein spezifisches Grid (Slot) zu definieren, zu welchem dann nur genau eine Datenquelle (Plug) implementiert ist. Beide Wege w\u00e4ren mit dem Plux.NET-<\/em>Framework m\u00f6glich, sind aber aus vielen Gr\u00fcnden ungeeignet. Beispielsweise w\u00fcrde das Anpassen der Metadaten immer auch zur Folge haben, das neue Subklassen (f\u00fcr die jeweiligen Slots\/Plugs) angelegt werden m\u00fcssten, obwohl eben eine \u00c4nderung der Metadaten hinreichend w\u00e4re.<\/p>\n

Die Autoren beschreiben in ihrem Paper einen Template-basierten Ansatz f\u00fcr die Metadaten, welcher ebenfalls im Plux.NET<\/em>-Framework implementiert wurde. Die entsprechenden Slot- und Plugnamen und die Parameterwerte werden mit Platzhaltern ersetzt. Die Metadaten sind somit unvollst\u00e4ndig und werden erst zur Laufzeit parametrisiert, sobald eine Komponente verbunden wird und deren konkrete Auspr\u00e4gung bekannt ist. Die Informationen dar\u00fcber k\u00f6nnen aus einer externen Quelle wie einer Konfigurationsdatei stammen.<\/p>\n

Ausarbeitung Beta<\/strong><\/p>\n

Adding genericity to a plug-in framework<\/a>\u00a0(.pdf, 438KB)<\/p>\n

Ausarbeitung Final<\/strong><\/p>\n

Adding genericity to a plug-in framework<\/a>\u00a0(.pdf, 325KB)<\/p>\n

Pr\u00e4sentation<\/strong><\/p>\n

Link zur Pr\u00e4sentation in Google Docs<\/a><\/p>\n

Adding genericity to a plugin framework_Pr\u00e4sentation_Florian Oeser<\/a>\u00a0(.pdf, 527KB)<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Blog-Eintrag zum Modul Wissenschaftliches Arbeiten an der Beuth Hochschule f\u00fcr Technik im Semester SS13. Allgemeine Informationen Name: Florian Oeser Matrikelnummer: 780586 Gruppe: B eMail: florian.oeser(at)gmail.com Gew\u00e4hlter Artikel Wolfinger, Reinhard, et al. „Adding genericity to a plug-in framework.“\u00a0ACM SIGPLAN Notices.Vol. 46. No. 2. ACM, 2010. Abstract Im Bereich der Softwareentwicklung spricht man von einem Plug-in, wenn […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/www.florian-oeser.de\/wp-json\/wp\/v2\/posts\/594"}],"collection":[{"href":"http:\/\/www.florian-oeser.de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.florian-oeser.de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.florian-oeser.de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.florian-oeser.de\/wp-json\/wp\/v2\/comments?post=594"}],"version-history":[{"count":14,"href":"http:\/\/www.florian-oeser.de\/wp-json\/wp\/v2\/posts\/594\/revisions"}],"predecessor-version":[{"id":608,"href":"http:\/\/www.florian-oeser.de\/wp-json\/wp\/v2\/posts\/594\/revisions\/608"}],"wp:attachment":[{"href":"http:\/\/www.florian-oeser.de\/wp-json\/wp\/v2\/media?parent=594"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.florian-oeser.de\/wp-json\/wp\/v2\/categories?post=594"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.florian-oeser.de\/wp-json\/wp\/v2\/tags?post=594"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}