Oracle Fusion Middleware Blog

WebCenter Spaces ist ja bekanntlich eine ADF 11g Anwendung und kann, wie im Whitepaper „ExtendingWebCenter Spaces“ beschrieben, mit eigenem Navigationsmodell, eigenem Layout (Shell),  mit eigenen Skins,  eigener Resource Palette (Business Repository) usw. erweitert werden. Beim Customizing von WebCenter Spaces werden die Änderungen in ein eigenes Web Application Archive gepackt und zur Spaces Anwendung hinzudeployt. Somit kann durch einfaches Undeployment des eigenen WARs der ursprünglichen Zustand von Spaces wiederhergestellt werden. Das bedeutet also, dass auch ein eigenes Skin nur über das „CustomWebCenterSpacesWAR“ erstellt und der Spaces Anwendung hinzugefügt werden kann.

Man definiert also zuerst ein Skingrundgerüst, am besten durch Kopieren eines in der Customizing App vorhandenen Skins und fügt es der Spaces Anwendung wie im Whitepaper beschrieben bei. Hinweis: Bitte achten Sie genau auf die Reihenfolge und die Zeitpunkte des Stoppens und Startens des Managed Servers für Spaces.

Die Herausforderung ist nun, aus den umfangreichen ADF Faces UI Komponenten die in Spaces verwendeten herauszufinden und gezielt in einem eigenen Skin zu verändern. Dazu kann der Blogeintrag „ADF Faces Stylesheet rückverfolgen“ als Anleitung dienen. Hier wird beschrieben, das man über die web.xml der Applikation die CSS Komprimierung deaktivieren sollte, um die verwendeten Stylesheetklassen zu erkennen und dann auf den Skineintrag schließen zu können. In unserem Falle bedeutet dies, die web.xml der Spaces Anwendung zu bearbeiten und nicht in der „CustomWebCenterSpacesWAR“.

Hier die Vorgehensweise in der Übersicht. Man muß nun das webcenter.ear Archiv finden, öffnen, das darin enthaltene webcenter.war öffnen und dort die web.xml mit dem entprechenden Parameter wie im o.g. Blogeintrag beschrieben  ändern. Anschließend alle Archive wieder einpacken und das webcenter.ear updaten.

• Webcenter.ear finden

Hierzu geht man am besten auf die WLS Konsole des AdminServers und klickt auf Deployment. In der Liste der deployten Anwendungen geht man zum Eintrag webcenter, wählt den Eintrag an und klickt auf updaten.

Dort sieht man dann den Pfad des Archivs, z.B. . D:\Oracle\Middleware\Oracle_WC1\archives\applications\webcenter.ear

Bitte die Seite so stehen lassen. Hier wird dann später das Update erfolgen.

• Archiv auspacken und Web.xml bearbeiten

In dem angegebenen Pfad finden Sie dann das webcenter.ear. Bitte machen Sie eine Sicherheitskopie davon. Packen Sie das EAR File aus (zum Beispiel mit Zip). Dann finden Sie darin das webcenter.war.

Packen Sie das webcenter.war File aus und Sie finden dann im Pfad  WEB-INF die web.xml. Bearbeiten Sie diese.

Fügen Sie zwischen dem letzen Tag für <context-param> und  dem ersten Tag für <resource-ref> den <Context-param> für die CSS Dekomprimierung ein, also zum Beispiel so:

<context-param>
 <param-name>
 CpxFileName
 </param-name>
 <param-value>
 oracle.webcenter.webcenterapp.bindings.DeploymentDataBindings
 </param-value>
 </context-param>
<!-- Customize Skin-->      
 <context-param>
 <description>Disable CSS Compression</description>
 <param-name>org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION</param-name>
 <param-value>true</param-value>
 </context-param>
 <resource-ref>
 <res-ref-name>
 jdbc/WebCenterDS
 </res-ref-name>
 <res-type>
 javax.sql.DataSource
 </res-type>
 <res-auth>
 Container
 </res-auth>
 </resource-ref>

• Archive einpacken

Packen Sie als erstes wieder das WAR Archiv zusammen, z.B. mit Zip. Achten Sie bitte dabei auf Beibehaltung der originalen Verzeichnisstruktur. Packen Sie anschließend wieder das EAR  mit dem so geänderten WAR Archiv zusammen. Achten Sie bitte darauf, dass das EAR File im o.g. Pfad liegt und das alte EAR überschrieben wird, in unserem Beispiel D:\Oracle\Middleware\Oracle_WC1\archives\applications\webcenter.ear

• Webcenter Anwendung updaten

Sollte der Managed Server für Spaces nicht laufen, so starten Sie ihn bitte vor dem Update der Anwendung. Kehren Sie zur oben geöffneten Seite in der WLS Console (Update Webcenter Anwendung) Maske und klicken Sie nun auf „Finish“. Damit wird dann Ihre Webcenter Spaces Anwendung redeployt und Sie finden nun im Source Code der Spaces Seite die nicht komprimierten CSS Klassen vor.

Verfahren Sie nun, wie im bereits oben referenzierten Blogeintrag beschrieben, fort, um Ihren Spaces Stylesheet zu definieren.

<DM>

Problem:

Wie finde ich die entsprechende Styledefinition einer UI Komponente in einem ADF Faces Skin, um diese wie gewünscht zu gestalten.

Lösungsvariante 1:

Man kennt die ADF Faces UI Komponenten und schaut in deren Dokumentation, um die notwendigen Stylesheet Klassen in einer eigenen Skindefinition anzugeben.

Lösungsvariante 2:

Man verfolgt den im Browser ankommende Stylesheet zurück bis zur Definition im ADF Faces Skin. Aber wie ?

An dieser Stelle sei nochmal erwähnt, dass ein Skin eine auf CSS 3.0 Syntax basierende Stylesheetdefinition ist. Skins benutzen also CSS, um die Darstellung von ADF Faces und Trinidad UI Komponenten zu definieren.

Für Variante 1 ist die im Blogeintrag vom 11.Februar beschriebene Lösung ein gutes Hilfsmittel. Deshalb behandeln wir nun Variante 2. Als Beispiel dazu dient eine ADF Faces Rel. 11 Anwendung, die mit einem Standard ADF Faces Skin („blafplus-rich„) versehen ist.

Bild 1: ADF Beispielanwendung

Wir wollen nun die CSS Definition für bestimmte Oberflächenelemente ermitteln, um sie wunschgemäß anpassen zu können. Schauen wir zunächst auf den im Browser ankommenden HTML Sourceode und suchen den Link zur Stylesheet Definition, die der Browser umsetzt.

… <link rel=“stylesheet“ charset=“UTF-8″ type=“text/css“ href=“/HRSystem-ViewController-context-root/adf/styles/cache/blafplus-rich-desktop-f72ien-ltr-gecko-1.9.0.8-cmp.css“>…

Hier erkennen wir, dass dies aber nicht die eigentliche CSS Definition aus dem Skin ist, sondern ein vom ADF Faces Renderer zur Laufzeit generierter Stylesheet. Dabei liest der ADF Faces Renderer die Skindefinition aus  und erstellt eine browserspezifische CSS Datei mit dynamischen, komprimierten Klassennamen. Wie schließen wir aber aus den dynamischen CSS Klassen im Browser auf den originär im Skin definierten Style der betreffenden UI Komponente?

Über die Firefox Community gibt es ein paar nützliche Add-Ons, die wir hier gut gebrauchen können. Es empfehlt sich, die Firebug- und die Web Developer – Erweiterungen runterzuladen und zu installieren, falls nicht schon geschehen.

Nach erfolgreicher Installation der Plugins starten wir nocheinmal die ADF Anwendung, um jetzt beispielsweise die Darstellung eines Tabreiters vom Browser bis zur ursprünglichen Definition im Skin zurückzuverfolgen. Dazu klickt man mit der rechten Maustaste auf den Tabreiter und wählt „Inspect Element“ aus.

Bild 2: Aufruf Firebug Erweiterung in Firefox

Firebug öffnet sich und stellt im unteren Fenster den HTML Source Code sowie im rechten Fenster die im Browser anliegenden CSS Settings dar.

Bild 3: Ansicht Firebug Erweiterung in Firefox

Bewegt man nun den Mauszeiger im Source Code Fenster über andere Codpassagen, so wird im oberen Darstellungsfenster die betreffende HTML Komponenten markiert.

Eine schöne Möglichkeit, gleich an Ort und Stelle in der laufenden Anwendung verschiedene CSS Attribute auszutesten, bietet die Web Developer Erweiterung. Mit Ctrl + Shift + E gelangt man in den CSS Editor und sieht nocheinmal den geladenen Stylesheet.

Bild 4: Ansicht Web Developer Erweiterung - Stylesheet Editor

Man kann in dieser Liste Attribute von CSS Klassen verändern und gleich die Auswirkungen auf der Seite sehen.

Über Firebug findet man also die gültige CSS Klasse der betreffenden UI Komponente (hier Tabreiter) und über Web Developer kann man diese gezielt verändern. In unserem  Beispiel möchten wir den Text des Tabreiters ShowDetailItem1 rot einfärben. Wir klicken daher im Browserfenster mit der rechten Maustaste auf den Text ShowDetailItem1 und wählen Inspect Element aus. Wir sehen, dass hier die CSS Klasse .xs4 verwendet wird.

Bild 5: Ad-Hoc Änderungen von Stylesheet Attributen im Web Developer

Im CSS Editorfenster links suchen wir nun die CSS Klasse  .xs4. p_AFSelected und deren Attribut [color:#000000], welches wir dann auf [color:#FF0000] ändern. Man sieht sofort, dass sich der Text des Tabreiters rot färbt.

Bleibt nur noch die Frage, wie man von der dynamisch erzeugten CSS Klasse .xs4 im Browser auf die tatsächliche Styledefinition im ADF Faces Skin schließt? Dort werden ja die für die jeweilige UI Komponente festgelegten CSS Klassen definiert, die nicht xs4 oder ähnlich heissen, sondern irgendwie den Komponentennamen enthalten. Man muss zuerst in der web.xml der JSF Anwendung die Kompression der CSS Klassen deaktivieren. Damit werden keine dynamischen Klassennamen vom Renderer generiert, sondern die Klassennamen des Skins verwendet. Man öffnet im JDeveloper im Projekt der JSF unter Web-INF die web.xml und fügt unter Context Initialization Parameters einen neuen Parameter org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION mit dem Wert True hinzu.

Bild 6: Einschalten der CSS Dekompression in der web.xml

Nun startet man die Anwendung neu und schaut über Firebug auf den Tabreiter. Die Stylesheet Klasse des Tabreitertextes heißt in unserem Beispiel nun .af_PanelTabbed _tab-text-link (Zur Erinnerung: vorher war der CSS Klassenname .xs4)

Bild 7: dekomprimierte Stylesheet Klassenamen

Auf OTN kann man sich die Skindefinition dieser UI Komponente anschauen und weiß nun, welche Klassen in der CSS Datei des eigenen Skins definiert werden müssen, um ein gewünschtes Layout der Komponente zu erhalten. Man kann aber auch aus aus dem im Browser anliegenden Klassennamen auf die CSS Klasse im Skin schließen, in dem man .af_ mit .af| und dann jedes weitere _ mit :: ersetzt. In gegebenen Beispiel würde man .af_PanelTabbed _tab-text-link mit .af|PanelTabbed ::tab-text-link ersetzen und hätte ohne nachzuschauen den Klassennamen für die eigene Skindefinition.

Wie man eine eigene ADF Faces Skindefinition anlegt,  ist in der ADF Faces Doku beschrieben oder in diversen BLOG Postings zu finden.

<DM>

Mit der Version 3.2 von Oracle Application Express (APEX) ist ein Converter für Oracle Forms verfügbar. Zunächst müssen die existierenden  Anwendungsdateien für den Import in das APEX-Repository vorbereitet werden:

• Konvertieren der binären Forms-Module (fmb, olb, mmb) mit dem Utilty frmf2xml.bat in das XML-Format
• Konvertieren der PL/SQL-Bibliotheken (pll) im Forms Builder oder im Batch in das Textformat (pld)
• Konvertieren der Reports-Module (rdf) im Reports Builder oder im Batch in das XML-Format

Danach können die Dateien in einen APEX-Workspace geladen werden. Interessant sind die vielfältigen Möglichkeiten der Analyse, die dem Entwickler  nach dem Laden der Applikation zur Verfügung stehen.
Anschließend kann aus den geladenen Metadaten eine APEX-Applikation generiert werden.
Das Vorgehen ist in einem Dokument an Hand eines Beispiels beschrieben.

Man sollte sich allerdings darüber im Klaren sein, dass mit diesem Schritt keinerlei Integration der Anwendung mit dem Desktop mehr möglich ist, wie sie heute in vielen Forms-Applikationen noch üblich ist  (MS Office, lokale Treiber etc.).

Wenn man langfristig über Alternativen zu Oracle Forms nachdenkt, sollte man für größere und komplexe Forms-Anwendungen das Oracle Application Development Framework (ADF) in die engere Wahl ziehen.

<JM>

Viele Oracle-Anwender haben einen Teil der Geschäftslogik als PL/SQL Stored Procedures in der Datenbank abgelegt. Wie kann man diese Logik weiterhin nutzen, wenn statt Oracle Forms und Reports zukünftig Oracle ADF in der Anwendungsentwicklung zum Einsatz kommt?

Ein gangbarer Weg besteht darin, die Stored Procedure als Web Service zu kapseln und ADF Data Controls für den Web Service zu erzeugen.
Soll das Framework ADF Business Components (ADF BC) eingesetzt werden, so gibt es derzeit keine deklarative Funktionalität, um zum Beispiel ein Entity Object (EO) auf Basis einer Stored Procedure zu definieren.  Eine Integration von Stored Procedures ist aber programmatisch möglich.
Die Dokumentation beschreibt dazu zwei Wege:

• den Aufruf von Stored Procedures/Functions mit unterschiedlichen Parameter-Konstellationen (siehe Doc) an beliebiger Stelle im Framework ADF BC.
• den Aufruf von Insert/Update/Delete-Prozeduren, die den Zugriff auf DB-Tabellen kapseln und im Entity Object aufgerufen werden (siehe Doc).

Der im zweiten Weg beschriebene prozedur-basierte Tabellenzugriff wird in vielen Forms-Anwendungen genutzt; häufig wurde dazu der Table API Generator des Oracle Designer eingesetzt. Will man diese Prozeduren weiter verwenden, muss die doDML()-Methode der EntityImpl-Klasse überschrieben werden. Die Dokumentation enthält Beispiele für den Programmcode und beschreibt auch die Möglichkeit, Select- und Lock-Funktionalität hinzuzufügen.

<JM>

Wer sich mit komponentenbasierter Oberflächenentwicklung beschäftigt, wird mit Sicherheit bei JSF, MyFaces und ADF Faces landen. Die Frage, die sich dabei immer wieder stellt ist, welche Komponente nun für das zu bearbeitende Anwendungsdetail geeignet ist. Die mit jedem Release wachsende Zahl an Komponenten in den jeweiligen UI Frameworks kann man kaum noch soweit verinnerlichen, dass man, ohne nachzuschauen, weiß, welche Komponente in der IDE ausgewählt werden soll. Entweder schaut man in irgendwelche statischen Dokumentationen oder man nutzt mehr oder weniger immer die selben Komponenten, die man kennt (Oder man erinnert sich an diesen Blogeintrag ).

Man benötigt also eine irgendwie geartete Übersicht aller Komponenten und deren Anwendungsbereiche und Gestaltungsmöglichkeiten. Für ADF Faces Release 11 ist seit geraumer Zeit eine solche Übersicht in Form einer interaktiven Anwendung entweder Online oder als Offline Version zum Downloaden verfügbar.

Hier kann man gut strukturiert auf Layoutkomponenten und deren Gestaltungsmöglichkeiten schauen. Eine sehr schöne Hilfe und Erleichterung für jeden ADF Entwickler.

<DM>