Christoph Barchnicki

Am 17. April haben wir uns zu einem ersten Workshop im technischem Rathaus Köln getroffen, dessen Thema war, einen offenen Standard für Ratsinformationssysteme zu schaffen. Das Hauptziel dabei war eine gemeinsame Schnittstelle oder einen gemeinsamen Standard zu finden, um RIS-Informationen leichter austauschbar zu machen. Es wurde vereinbart, bis zum 30. Juni 2013 eine erste Version zu verabschieden.

Anwesend waren Politiker, Vertreter der Kommunen und der Wissenschaft, sowie die führenden Hersteller von Ratsinformationssystemen. Da wir uns in dem letzten halben Jahr intensiv (vorallem aus Nutzersicht) mit der Thematik beschäftigt hatten (und es noch weiterhin tun), ergab sich eine offizielle Einladung zum Workshop. Die 30 Teilnehmer hörten sich zuerst spannende Impulsvorträge zu bestehenden Aktivitäten und Interessen aus der Sicht von Nutzern und IT-Dienstleistern an. Anschließend folgte eine Diskussion über Chancen und Risiken – bis es am Abend zu einem ersten Entwurf kam.

Die erste Version der offenen Schnittstelle hat auch schon einen Namen: “OParl.

oparl

 „OParl ist eine Initiative zur Standardisierung des offenen Zugriffs auf parlamentarische Informationssysteme in Deutschland. Das exakt definierte Ziel von OParl. ist die Schaffung einer Standard-API für den Zugang zu öffentlichen Inhalten in kommunalen Ratsinformationssystemen, damit die Inhalte daraus im Sinne von Open Data für möglichst viele verschiedene Zwecke eingesetzt werden können.“ (Quelle OParl.de)

Alle weiteren Informationen über diesen Standard finden Sie auf OParl.de. Wer den Tag bei Twitter nachvollziehen möchte, kann das unter dem Hashtag #RISWS tun.

Aus technischer Sicht werden definierte Datenmodelle (siehe auch https://github.com/OParl/specs) über einen Aufruf der URL erreichbar sein. Geplant ist, dass eine externe Testsuite die Entwickler hier unterstützt und die Schnittstelle auf ihre Korrektheit testet.

 

Tags: ,

Die Portal-Navigation gehört seit den Anfängen von OpenSAGA zu den Standard-Modellen. Optisch vielfältig anpassbar, war die Navigation zur Laufzeit allerdings relativ statisch in ihrer Form. In OpenSAGA 3.0 haben wir nun auch den Bereich der Navigation ein wenig überholt und dynamisiert.

Die Grundlage der Navigation sind und bleiben die zusammengeführten Navigations-Modelle aller Erweiterungen. Diese Modelle bilden nun den Basis-Stand, den Auslieferungszustand, der per Benutzeroberfläche editiert werden kann — auch und vor allem punktuell, während diese Änderungen jederzeit automatisch mit Änderungen der Basis-Modelle zusammengeführt werden können.

Es ist auch möglich, Änderungen an der Navigation per Manipulation der zu Grunde liegenden Domänen-Objekte zu ändern.

Content-Mappings als Navigations-Ziel

Neben Start-Zuständen und externen URLs kann nun auch eine dritte Ziel-Art von einem Navigationseintrag aus angesprungen werden, nämlich die Content-Mappings, die ja wie bereits erwähnt als logische Link-Ziele fungieren.

Parallel zu der Parametrisierung von Start-Zustandseinsprüngen kann dabei die Navigation ein Input-Value-Set definieren, das Eigenschaftswerte und Fachobjekt-Referenzen an das Content-Mapping / den eigenständingen View übergibt.

Neu: Graphische Navigation

Wir haben einige deklarative Neuerungen in der Navigation eingeführt. Zum Beispiel ist es jetzt möglich eine Graphik anstelle eines Labels zu definieren.

<image-item
    id="cms-test.n_applications.qs-nav" 
    resource="media/qs.png" 
    external-target="http://www.quinscape.de"
    title="Link to Quinscape website" />

Hier wird die OpenSAGA-Ressource “media/qs.png” als Navigationsgraphik eingebunden und mit einem Titel versehen.

Neu: Navigations-Domänen-Listen

Wie bereits erwähnt, wurde die Navigation in OpenSAGA 3.0 dynamisiert und kann nun per Benutzeroberfläche oder Manipulation der zu Grunde liegenden Domänen-Objekte angepasst werden. So können generelle, auch strukturelle Änderungen vorgenommen werden.

Daneben gibt es auch die Möglichkeit, dynamische Unterpunkte innerhalb einer Navigation zu definieren. Dies kann mit dem neuen <navigation-domain-list /> Element erreicht werden.

<item id="myext.n_applications.cms-nav" label="Contents">
    <item-list>
        <navigation-domain-list 
            id="myext.n_applications.cms-nav2"
            domain-type-ref="myext.d_content" 
            label-property-ref="myext.d_content.title"
            content-mapping-ref="myext.cm_content">
            <input-value-set>
                <input-value 
                    name="object" 
                    source-scoped-domain-object-ref="current-domain-object"/>
            </input-value-set>
            <sort-order-list>
                <sort-order property-ref="myext.d_content.title"/>
            </sort-order-list>
            <filter-specification>
                <equals>
                    <property property-ref="myext.d_content.draft"/>
                    <constant value="false"/>
                </equals>
            </filter-specification>
        </navigation-domain-list>
    </item-list>
</item>

Hier sehen wir die Definition einer Navigation-Domain-List. Unterhalb eines Oberknotens mit dem Label “Contents” wird eine dynamische Liste von Navigationseinträgen deklariert.

Alle dynamischen Navigationseinträge beziehen sich auf denselben Domänen-Typen. Eine gefilterte Liste wird so definiert, dass sie nur Objekte enthält, die sich nicht im Entwurfsmodus befinden.

Die Objeke der Liste werden nacheinander, jeweils als eigener parametrisierter Navigations-Link ausgegeben. Die Objekt-Identität des aktuellen Objekts wird dabei als Parameter “object” and das Content-Mapping “myext.cm_content” weitergegeben.

@CustomNavigation

Um eine möglichst große Freiheit bei der Gestaltung von Navigationen zu erreichen, haben wir auch eine weitere, Custom-Logic basierte Darstellung der Navigation realisiert.Die bereits erwähnten graphischen Navigationseinträge und die Navigations-Domänen-Listen basieren intern ebenfalls auf diesem neuen System und erlauben so auch, die voreingestellte Custom-Navigation zu ändern.

Um eine eigene @CustomNavigation zu erstellen muss eine Klasse mit der Java-Implementation zu den Projekt-Klassen hinzugefügt werden, und zwar in einem Java-Paket, dass in der jeweiligen Erweiterung als Custom-Logic-Package definiert ist.

Die Interaktion erfolgt über die Klasse CustomNavigationContext, die in Custom-Navigation-Methoden zur Verfügung steht und eine kleine programmatische DSL zur Darstellung von Navigationslinks bereitstellt.

@CustomLogic
public class BaseNavigationLogic
{
    @CustomNavigation("myextension.example-navigation")
    public void renderExampleNavigation(CustomNavigationContext context)
    {
        context.openListItem();  
        context.renderLink()
            .toExternalURL("http://opensaga.org")
            .withLabel("OpenSAGA")
            .close();
        context.closeListItem();
    }
}

In diesem Beispiel benutzen wir den automatisch herein gereichten Kontext um zuerst den umgebenden Listen-Eintrag des Navigations-Links zu erzeugen. Dann geben wir mit Hilfe der renderLink-Methode einen Link zur OpenSAGA-Website aus. renderLink gibt einen NavigationLinkBuilder zurück, der eine sprechende Schnittstelle zur Navigationslink-Darstellung bereitstellt.

So kann auf einfache Weise die OpenSAGA-Navigation um eigene Navigations-Elemente und/oder Strukturen erweitert werden.

Tags: , ,

Neben vielen punktuellen Erweiterungen und Verbesserungen in OpenSAGA 3.0 sind zwei grundsätzlich neue Bereiche hinzu gekommen. Bisher lag der Fokus von OpenSAGA hauptsächlich in der Umsetzung von Fachanwendungen mit Webtechnologien, besonders im Intranet-Bereich. Die zugrunde liegenden Technologien wurden im Bezug auf ihren Komfort und ihre möglichst inklusive Benutzerfreundlichkeit gewählt.

Zwar lässt sich auf diese Art und Weise grundsätzlich jede Anwendung abbilden, für bestimmte Anwendungsbereiche ist die Umsetzung aber gleichzeitig zu überdimensioniert und für speziellen Anforderungen doch nicht ausreichend. Dies betrifft im Grunde alle Anwendungsbereiche, bei denen der Anwendungscharakter weniger im Vordergrund steht sondern vielmehr die klassische informationelle Internet-Seite als Ganzes oder als Teil eines größeren Portal-Konzepts.

Hier greifen viele der klassischen Überlegungen zum Informations-Design im Internet. Inhalte sind strukturiert und korrelieren mit einer möglichst permanenten URL-Struktur. Es gibt zwar einen klassischen Einstiegspunkt — üblicherweise an der Wurzel-URL, aber auch tiefe Verlinkungen durch Partner, Suchmaschinen und/oder Dritte. URLs und Verlinkungen folgen der Informationsstruktur und nicht Anwendungsregeln.

Um diese Bereiche besser für OpenSAGA zu erschließen, haben wir in OpenSAGA 3.0 zwei neue Konzepte eingeführt.

Content-Mapping

Bisher ergaben sich die URLs einer OpenSAGA-Applikation aus Details der Implementation und Modell-Ids. Mit OpenSAGA 3.0 kann man in großen Teilen frei bestimmen, welche URLs in der Applikation verwendet werden. Hierzu wurde das Konzept der Content-Mappings eingeführt. Im portal.xml einer Extension kann ein <content-mapping-set /> angegeben werden, dass die Content-Mapping-Deklaration enthält.

<content-mapping-set>
    <content-mapping id="cms-test.cm_mapped" location="/mapped/" process-ref="cms-test.p_mapped"/>
</content-mapping-set>

Die Content-Mappings deklarieren für ein bestimmtes URL-Muster, welche Inhalte dort verfügbar sind, ob es Zusatzparameter oder Fachobjekt-Bezüge gibt. Für Prozesse können sowohl die Basis-URL des Prozesses während er läuft bestimmt werden, wie auch Startzustands-URLs. Für Prozesse kann dies erfolgen, muss aber nicht. Wenn kein Content-Mapping für einen Prozess oder einen Startzustand existiert, so wird ein Default verwendet.

Standalone-Views

Zusätzlich zu den Prozessen gibt es nun auch eigenständige Views. Standalone-Views sind den bisherigen OpenSAGA-Views sehr ähnlich, sie sind aber nicht nur ein Teil eines Prozesses und von dessen Logik gesteuert, sondern existieren für sich und werden mit Hilfe von Content-Mappings mit relativen URLs verbunden.

Im einfachsten Fall sieht eine Content-Mapping-Deklaration für einen Standalone-View dann so aus:

<content-mapping id="cms-test.cm_page" location="/page" view-ref="cms-test.sv_page"/>

Das location Attribut definiert die relative URL, das view-ref Attribut referenziert einen standalone view. Die Standalone-View-Modelle können jeweils als Datei unterhalb des Extension-Pfades “models/standalone-views” deklaratiert werden.

Die Content-Mapping-Deklarationen fungieren für Standalone-Views auch als Ziele für logische Links.

Vom Aufbau her sind Standalone-View-Modelle den traditionellen View-Modellen sehr ähnlich, sie haben lediglich ein anderes Wurzel-Element.

<standalone-view id="base.sv_test"
    title="Standalone Test View"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://www.opensaga.org/schema/model/standalone-view-3.0.xsd">    
    <part-set>
        <part id="base.sv_test.main_part">
            <content>
                <heading value="Hello from the View"/>
            </content>
        </part>
    </part-set>
</standalone-view>

Laufzeit-Pflege

Um von diesem generellen Strukturänderungen wirklich zu Content-Management-Funktionalität zu kommen, können bestimmte Teile des Modells nun auch zur Laufzeit per Adminstrations-Oberfläche, wie auch deklarativ oder programmatisch als Fachobjekte bearbeitet werden. Dazu gehören alle Content-Mapping-Definition, wie auch die Portal-Navigation. Präsentierte Inhalte können auch zur Laufzeit gepflegt werden.

Links:

Tags: , , ,

Ich freue mich, die Freigabe von OpenSAGA 3.0.0M1 bekanntzugeben.

Es handelt sich bei diesem Release um eine echte Alpha-Version, die nicht für den produktiven Einsatz geeignet ist, sondern einen Eindruck von kommenden Features verschaffen soll. Wesentliche Neuerungen sind:

  • vielfältige neue Widgets,
  • deutlich erweiterte Möglichkeiten zur deklarativen Erweiterung von OpenSAGA,
  • die Möglichkeit zur ressourcenbasierten Verwaltung von Inhalten (URL-basiert, mit Möglichkeiten zur Erweiterung zur Laufzeit), die insbesondere CMS-Funktionalitäten (CMS= Content Management System) für OpenSAGA 3 bereitstellen werden,
  • viele Bugfixes und Detailverbesserungen.

Offen sind aber auch wichtige Punkte:

  • Viele der neuen Funktionalitäten sind noch nicht dokumentiert.
  • Es fehlen Beispiele.
  • Das neue Rechtesystem ist noch nicht enthalten.
  • Viele Testfälle fehlen noch.
  • Die neuen Funktionen sind noch nicht hinreichend stabil – es kann und wird beim Testen also zu Fehlern kommen!

Tags: , , ,

Wie bereits hier angekündigt nähert sich OpenSAGA langsam aber sicher dem 3.0-Release. OpenSAGA 3.0 ist zum Teil eine Weiterführung des bisherigen OpenSAGA Weges, teils eine Neuorientierung resultierend aus den bisherigen Erfahrungen aus und Anforderungen von Projekten, die mit OpenSAGA betrieben wurden. Einige Teile wurden konzeptionell überarbeitet (zum Beispiel das Deklarative Rechtesystem) und andere Teile sind neu hinzugekommen.

Wie bereits hier erwähnt, ist einer der Teile die Unterstützung von Content-Management-System Funktionalität. Dies betrifft gleich mehrere Bereiche und Aspekte von OpenSAGA.

Neben den traditionellen OpenSAGA-Prozessen, gibt es nun eine zweite Art von Inhaltsdarstellung in OpenSAGA, nämlich Einzelseiten oder -sichten. Diese gehören nicht zu einem Prozess, sind nicht Teil eines UI-Flusses, sondern existieren einzeln unter einer bestimmten URL. Sie dienen hauptsächlich der Präsentation von Daten und Inhalten, können aber auch als Übersicht und Einsprung in klassische Prozesse verwendet werden. Obwohl sich die technische Form von Einzelseiten und Prozess-Sichten stark unterscheidet, unterscheiden sie ich auf Modell-Ebene kaum. Die Präsentationskomponenten von OpenSAGA (zum Beispiel Datagrid oder List-Iterator) können eins zu eins übernommen werden. Innerhalb von Einzelseiten werden einfache Formulare unterstützt, auch wenn nicht der volle Komfort des normalen OpenSAGA-Objekt-Lebenszyklus zur Verfügung steht.

Die URL-Adressen innerhalb einer OpenSAGA-Anwendung sind nun zu einem großen Teil Benutzer-definierbar. Dies betrifft die eben erwähnten Einzelseiten, wie auch die Einsprungadressen zu Startzuständen beziehungsweise laufenden Prozessen.

Verschiedene Konzepte, die vorher als rein statisches Modell vorhanden waren, führen nun eine Doppelexistenz. Zum Einen gibt es einen aus dem Modell vorgegebenen Teil, zum Anderen kann der Anwendungs-Administrator diese Objekte während die OpenSAGA-Anwendung läuft neu definieren beziehungsweise umdefinieren.Dies betrifft einen Teil der neuen Sicherheitsmodelle, die Navigation und die URL-Zuordnungen von Prozessen und Einzelseiten, wie auch die Definition der Einzelseiten selbst.

Neben diesen großen strukturellen Änderungen gab es auch eine große Menge von kleinen Detailänderungen, die entweder für die Administrationsoberflächen nötig waren, oder sich einfach aus der neuen Struktur ergaben. Einige dieser Änderungen werde ich hier in der nächsten Zeit noch im Detail vorstellen.

Tags: , ,

Terstiege_85x112

Das bisher in OpenSAGA 2.x verwendete Rechtesystem hat sich zwar in der Praxis bewährt, die Konfiguration erforderte aber eine Menge Kleinarbeit. Zusätzlich war die Trennung zwischen Modellen (z.B. Prozesse, Views und Transitionen) und deren anschließende (manuelle) Zuordnung zu Rollen manchmal ein wenig mißverständlich.

OpenSAGA 3.0 wird daher erstmalig ein modellbasiertes Rechtekonzept bieten, das eine deklarative Spezifikation des Rechtesystems erlaubt. Dies hat einige Vorteile:

  • das Rechtesystem ist komplett im Modell beschrieben
  • Rollen, Gruppen und Organisationseinheiten und deren Zuordnung untereinander können im Modell definiert werden
  • Zugriffsbeschränkungen werden direkt an der Stelle angegeben wo sie benötigt werden (z.B. im Prozess oder an einer Transition)
  • die manuelle Konfiguration beschränkt sich auf die Zuordnung von Benutzern zu Rollen
  • bei Bedarf kann das Rechtesystem einfach ausgetauscht werden, ohne dass eine komplette Neukonfiguration stattfinden muss

In einem der nächsten Blog-Einträge werden wir die neuen Modelle genauer beschreiben und einige Beispiele zeigen.

 

 

Tags: , ,

Nach viel zu langer Sendepause bringen wir nun in den kommenden Wochen OpenSAGA 3 auf die Zielgerade. Eine große Zahl aufregender Neuerungen warten auf OpenSAGA-Nutzer und wir werden viele davon in kleinen Artikeln in den nächsten Wochen bis zum Release vorstellen. Zu den aufregenden Neuerungn gehören u.a.:

  • leistungsfähige CMS-Komponenten, um echte Content-Management-Szenarien mit OpenSAGA abzubilden (angefangen bei der Verwaltung URL-basierter Resourcen bis hin zur Laufzeitanpassung und -pflege von Navigation und Inhaltsseiten)
  • ein modellbasiertes Rechtekonzept, dass eine deklarative Spezifikation des Rechtesystems erlaubt
  • umfassende Erweiterungen des Dialogsystems, so dass wesentlich komplexere Dialoge mit vielfältigen Inhalten realisiert werden können
  • umfassende Erweiterungen zur Individualprogrammierung
  • umfangreiche Performance-Verbesserungen
  • hunderte von Detailverbesserungen

Auf diese und weitere Details werden wir in den nächsten Wochen eingehen, während wir intern allmählich den vollständigen geplanten Umfang der 3er-Version erreichen, Dokumentation und Beispiele überarbeiten, OSclipse im Hinblick auf die Neuerungen fertigstellen und die vielen anderen Dinge tun, die ein großer Versionssprung mit sich bringen.

Wir freuen uns bereits sehr darauf, nach fast anderthalb Jahren mit vielen Projekten und aufregenden internen Neuerungen endlich das rundum erneuerte OpenSAGA 3 der Öffentlichkeit zu präsentieren!

Tags: ,

Christoph Barchnicki

Ein etwas exotischerer Blogeintrag: Einer unserer studentischen Mitarbeiter hat für sein Studienprojekt unter anderem ein Portalsystem realisiert, das Studenten ermöglicht, sich für Praktika, Übungen und weitere Kurse an einer Hochschule anzumelden. Das System sollte mit Hilfe von Grails umgesetzt werden. Nachdem dies weitestgehend erledigt war, ist aufgefallen, dass bei diesem öffentlichen Portalsystem die Barrierefreiheit grundlegend auf der Strecke blieb. Nach Recherche ist leider aufgefallen, dass Grails dem Entwickler diesbezüglich auch nicht wirklich unter die Arme greift.

Kurzerhand fiel die Entscheidung, die Zusatzbibliothek DSS von OpenSAGA in Grails einzubinden und zu untersuchen, wie einfach oder schwer die Integration der Komponente wird.

Warum? Read the rest of this entry »

Tags: , , , , , , , ,

Gegenwärtig prüfen wir die Integration von CKAN in die OpenGovernment Suite OGS. CKAN ist die führende Open-Source-Lösung für die Bereitstellung und Anreicherung offener Daten (Open Data) und wird bereits in sehr vielen Projekten eingesetzt.

Read the rest of this entry »

Tags: , , , , , , ,

Christoph Barchnicki

Am Dienstag, dem 24. Juli fand in unserem Hause die erste Grundlagenschulung (Modellieren mit OpenSAGA I: Grundlagen) für Mitarbeiter der Technischen Universität Clausthal (Lehrstuhl für Software-Systems-Engineering) statt.

Die erste Workshop zu diesem Thema verlief nicht nur gefühlt sehr gut, sondern bekam auch von den Workshopteilnehmern eine positive Resonanz.

Was wurde gemacht?

Nach einer kleinen allgemeinen Einführung in die OpenSAGA-Initiative und SAGA haben die Teilnehmer die Aufgabe bekommen, ein funktionsfähiges “Hotel-Buchungs”-Portal auf Basis des OpenSAGA-Frameworks zu erstellen. Dabei wurde der Buchungs-UseCase nur exemplarisch zur Erläuterung von OpenSAGA-Konzepten umgesetzt.

Schritt für Schritt modellierten die Teilnehmer die Applikation bis zum Ende – teilweise ehrgeizbedingt und motiviert durch die schnellen Ergebnisse darüber hinaus.

Der Workshop ging mit einem kleinem Ausblick auf eine künftige Layout- und Designschulung in OpenSAGA zu Ende. Den Teilnehmern wurde ihr umgesetztes Portal mit einem individuellen Design präsentiert, dass vom Workshopteam (mir ;-) ) vorbereitet wurde.

Am Ende des Tages hatte jeder Teilnehmer ein funktionsfähiges Hotel-Buchungs-Portal in OpenSAGA modelliert, welches die Teilnehmer zusammen mit einem ausführlichem Handbuch mit nach hause nehmen durften.

OpenSAGA-Academy Schulungsprogramm

OpenSAGA-Academy

Tags: , , ,

« Older entries