Δυο χαρακτηριστικά του JSF 2 που είναι χρήσιμα στο ADF

Η 12c σειρά του JDeveloper (αλλά και η παλαιότερη 11g R2) υποστηρίζουν το πρότυπο JSF 2. Ανάμεσα στα πολλά νέα χαρακτηριστικά που έχει αυτή η έκδοση, σε σχέση με την 1.2, θα ήθελα να αναφέρω δυο γνωρίσματα που ίσως να φανούν χρήσιμα στους προγραμματιστές του Oracle ADF.

Το πρώτο έχει να κάνει με το ότι οι action μέθοδοι των navigation components (buttons, menus, links) επιδέχονται ορίσματα. Ενώ μέχρι το JSF 1.2 το managed bean action method signature δεν δέχονταν παραμέτρους, στο JSF 2 μπορούν να δεχτούν ορίσματα οποιουδήποτε τύπου. Ένα παράδειγμα χρήσης έχει να κάνει με το πέρασμα ως παραμέτρου της τιμής ενός attribute binding ή selected row(s) για το οποίο θα θέλαμε είτε UI components bindings είτε ADF bindings κώδικα στο managed bean μας. Στο παρακάτω απόσπασμα κώδικα, η managed bean action method χρησιμοποιεί ως παράμετρο την επιλεγμένη εγγραφή του πίνακα.

Ο δε κώδικας του managed bean μοιάζει ως εξής. Οι επιλεγμένες είναι άμεσα διαθέσιμες μέσω της κλάσης RowKeySet.

Το δεύτερο, αφορά την υλοποίηση συμπεριφοράς όταν συμβαίνουν συστεμικές ενέργειες (system events) σε UI components. Τέτοιες ενέργειες μπορούν να περιλαμβάνουν για παράδειγμα την αρχική εμφάνιση ενός στοιχείου (pre-render) σε μια σελίδα (περισσότερες πληροφορίες εδώ) Κάτι τέτοιο μπορεί να μας είναι πολύ χρήσιμο ώστε να υλοποιήσουμε λογικές τύπου "on component ή page load". Μάλιστα υπάρχει ένα παράδειγμα του ADF code corner για την προβολή ενός pop-up με την αρχική εμφάνιση ενός region. Έστω ότι θέλουμε να επηρεάσουμε το αρχικό rendering ενός πίνακα, ώστε εμφανίσουμε εξ ορισμού μια επιλεγμένη εγγραφή. Τότε μπορούμε να χρησιμοποιήσουμε το JSF component f:event, ενσωματωμένο στο component που μας ενδιαφέρει, στην περίπτωση μας ένα af:table.

 

H ιδιότητα listener μας ανοίγει το δρόμο για να προγραμματίσουμε τη συμπεριφορά του pre-render. Έτσι μπορούμε να κάνουμε μια προγραμματιστική αντιμετώπιση του event, χωρίς να καταφύγουμε σε σύνθετους κώδικες και phase listeners όπως συνέβαινε με προηγούμενες εκδόσεις.

    public void preRender(ComponentSystemEvent componentSystemEvent) {
        UIComponent tab = componentSystemEvent.getComponent();
    }

Ενσωμάτωση (integration) ενός Java applet σε μια JSF σελίδα

Αν και τα Java applets είναι εντελώς εκτός μόδας, παρουσιάστηκε η ανάγκη να χρησιμοποιήσω κάποιο από αυτά σε μια ADF JSF εφαρμογή. Πιο συγκεκριμένα, υπήρξε η ανάγκη διασύνδεσης μιας σελίδας ADF με μια web camera οπότε κατέφυγα στην τεχνολογία των Java applets σε συνδυασμό με την βιβλιοθήκη Java Media Framework (JMF - http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140239.html)

Προκειμένου να ενσωματώσουμε ένα Java applet σε μια JSF σελίδα, δεν έχουμε παρά να χρησιμοποιήσουμε την JSP tag library και πιο συγκεκριμένα το συστατικό jsp:plugin, ειδικά για applets. Περισσότερα για το JSP 2.0 tag library βρίσκονται στο: http://java.sun.com/products/jsp/syntax/2.0/syntaxref20.html

O κώδικας στην JSF σελίδα μας θα μοιάζει κάπως έτσι:

<jsp:plugin type="applet" code="mypackage.CameraApplet"
archive="cameraapplet.jar,jmf.jar,mediaplayer.jar" height="300"
width="400" align="bottom"
codebase="../../applet">
<jsp:fallback>
This browser does not support Applets.
</jsp:fallback>
</jsp:plugin>

Σε περίπτωση που θέλουμε να περάσουμε παραμέτρους στο applet, για παράδειγμα κάποια τιμή από τα ADF bindings μας, θα πρέπει να χρησιμοποιήσουμε το tag jsp:params και να ορίσουμε κατάλληλα την παράμετρο μας ώστε να διαβαστεί από το tag library. Μπορούμε λοιπόν, στην αρχή της σελίδας να κάνουμε τη δήλωση:

<c:set var="adfParamNbr"
value="#{bindings.ParamNbr.inputValue}"/>

που δείχνει σε μια μεταβλητή που αφορά τα bindings. Συνεπώς, η δήλωση του applet θα μεταβληθεί ως εξής ώστε να συμπεριλαμβάνει αυτή την παράμετρο μέσω Unified Expression Language.

<jsp:plugin type="applet" code="com.mni.mednext.view.applet.CameraApplet"
archive="cameraapplet.jar,jmf.jar,mediaplayer.jar" height="300"
width="400" align="bottom"
codebase="../../applet">
<jsp:params>
<jsp:param name="param1" value="${adfParamNbr}" />
</jsp:params>
<jsp:fallback>
This browser does not support Applets.
</jsp:fallback>
</jsp:plugin>

Εμφανίζοντας παραμετρικά μηνύματα στο JSF

Στο ADF έργο στο οποίο συμμετέχω αυτό τον καιρό, τα μηνύματα λαθών είναι αποθηκευμένα σε property files, με την εξής ιδιοτροπία για τις παραμέτρους: ξεκινούν από την τιμή ένα (1). Για παράδειγμα:

errorMsg.1001=Cannot assign value:{1} to field:{2}

Ένα από τα JSF components που υποστηρίζουν παραμέτρους, είναι το outputFormat για την εμφάνιση κειμένου. Εάν γράφαμε τον εξής κώδικα:

<h:outputFormat value="#{viewcontrollerBundle['errorMsg.1001']}" id="of1">
<f:param value="20.2" id="p1"/>
<f:param value="Salary" id="p2"/>
</h:outputFormat>

Τότε θα εμφανιζόνταν το ακόλουθο αποτέλεσμα.

Με άλλα λόγια, μόνο μια παράμετρος λαμβάνεται υπόψη. Αυτό έχει να κάνει με το γεγονός, ότι το JSF περιμένει τις παραμέτρους να ξεκινούν από την τιμή μηδέν. Ένα τέχνασμα προκειμένου να επιτύχουμε σωστή συμπεριφορά, είναι να προσθέσουμε άλλη μια (άχρηστη) παράμετρο στη λίστα μας, ώστε να καταλάβει τη θέση μηδέν. Δηλαδή:

<h:outputFormat value="#{viewcontrollerBundle['errorMsg.1001']}" id="of1">
<f:param value="dummy" id="p0"/>
<f:param value="20.2" id="p1"/>
<f:param value="Salary" id="p2"/>
</h:outputFormat>

Αντιμετωπίζοντας μηνύματα λαθών HTTP-404 και exceptions σε JSF εφαρμογές

H κατασκευή ενός δημόσιου, δομημένου, φιλικού site δεν είναι είναι εύκολη υπόθεση. Απεναντίας, χρειάζεται μεγάλη φροντίδα τόσo για χαρακτηριστικά ασφάλειας, όσο και για την εν γένει λειτουργικότητα και την ευκολία πρόσβασης στην πληροφορία. Για παράδειγμα, υπάρχουν περιπτώσεις που οι χρήστες μας διατηρούν bookmarks σε κάποιες σελίδες, που πιθανώς μελλοντικά να αλλάξουν. Στην περίπτωση αυτή, αντί να τους παρουσιαστεί ένα ξερό μήνυμα "HTTP 404 - Page not found" μπορούμε να διαμορφώσουμε τη JSF εφαρμογή μας ώστε να αντιμετωπίσει αυτού του είδους τις καταστάσεις, με μια μικρή προσθήκη στο web.xml, όπως:

<error-page>
<error-code>404</error-code>
<location>/faces//pagenotfound.jsp</location>
</error-page>

όπου ορίζουμε την σελίδα που θα διαχειριστεί αυτό το ενδεχόμενο. Κάτι ανάλογο μπορεί να συμβεί και με uncaught exceptions που δεν θα θέλαμε σε καμία περίπτωση να εμφανιστούν στους τελικούς χρήστες. Η μόνη παρέμβαση που κρίνεται απαραίτητη είναι να προσθέσουμε τις ακόλουθες γραμμές στο web.xml, δίχως να χρειάζεται να ορίζουμε errorPage ανά σελίδα.

<error-page>
<error-code>500</error-code>
<location>/faces/pages/common/errorPage.jsp</location>
</error-page>

Προσθέτοντας πλαίσια (borders) σε JSF components

Μια από τις παλαιές συνήθειες σε client-server εφαρμογές ήταν το να περικλείει κανείς κάποια στοιχεία που εμφανίζονται στην οθόνη μέσα σε πλαίσια προκειμένου να προκύπτει ένα ομαδοποιημένο αποτέλεσμα. Παρόλο που υπάρχουν διάφοροι τρόποι προκειμένου να οργανωθεί πληροφορία σε μια σελίδα (όπως για παράδειγμα με την χρήση menu tabs) δεν λείπουν οι περιπτώσεις που θα θέλαμε να εντάξουμε κάποια στοιχεία σε μια μορφή οπτικής οργάνωσης. Τα ADF Faces (που διανέμονται με τον JDeveloper 10.1.3.x) αλλά και τα ADF Rich Client components του 11g προσφέρουν τις κατάλληλες CSS ιδιότητες (attributes) προκειμένου να ορίσουμε είτε ένα panel, είτε ένα μεμονωμένο στοιχείο πως περικλείεται από ένα πλαίσιο.

Ειδικότερα στον JDeveloper 11g, από όπου τα επόμενα screenshots, αυτές οι ιδιότητες περιλαμβάνονται σε μια ξεχωριστή κατηγορία που ονομάζεται "Box".

Κατάλογος παραδειγμάτων JSF Tomahawk

Για όσους έχουν ξεκινήσει τον προγραμματισμό χρησιμοποιώντας το Apache MyFaces σε συνδιασμό με τις βιβλιοθήκες Tomahawk (που σύντομα θα εμπλουτιστούν με την προσφορά της Oracle των ADF Faces), μια χρήσιμη διεύθυνση με παραδείγματα (jsf tomahawk examples) του Apache Group είναι η:

http://people.apache.org/builds/myfaces/nightly/

Μεταφορά εφαρμογών Struts σε Java Server Faces

Αναμφίβολα, η δημιουργία πλούσιων διεπαφών με εύκολο και γρήγορο τρόπο αποτελεί μια από τις μεγαλύτερες προκλήσεις ακολουθώντας το πρότυπο J2EE (ή μάλλον καλύτερα Java EE εφεξής) και ένα προφανές σημείο που υπολείπεται σε σχέση με άλλα προγραμματιστικά πρότυπα (όπως το Microsoft .NET) Δείγμα αυτού του προβληματισμού είναι η ύπαρξη πολλών πλαισίων ανάπτυξης που καταπιάνονται με αυτό το θέμα.

Δυο από τα επικρατέστερα, είναι το παλαιότερο Apache Struts καθώς και το νεώτερο Java Server Faces (JSF) Το μεν πρώτο φαίνεται να οπισθοχωρεί, παραχωρώντας τη θέση στο δεύτερο ή σε ενδιάμεσες λύσεις (πχ project Shale - http://shale.apache.org/) Το δε δεύτερο, μετά από πολλές συζητήσεις προσπαθεί να βρει το δρόμο του και να κερδίσει την αποδοχή της Java κοινότητας, αποτελώντας μέρος του προτύπου Java EE 1.5. Στο επόμενο χρονικό διάστημα αναμένεται να είναι αρκετοί αυτοί που θα προχωρήσουν στα νέα τους έργα σε επένδυση στο JSF, ενώ δεν θα λείπουν οι περιπτώσεις μεταφοράς μιας εφαρμογής από το Struts στο περιβάλλον του JSF, που προσφέρει τυποποίηση, ένα επεκτάσιμο πλαίσιο ανάπτυξης συστατικών στοιχείων (UI components) και χειρισμού της εφαρμογής (πχ υποστήριξη διαφορετικών συσκευών τελικού χρήστη) Ερευνώντας αυτό το ενδεχόμενο το τελευταίο διάστημα, έχω καταλήξει πως υπάρχουν κάποια βασικά, κοινά στοιχεία που μπορούν να βοηθήσουν την μετάπτωση, όπως:

• Τα δυο πλαίσια ανάπτυξης ακολουθούν τις σχεδιαστικές επιταγές του Model View Controller, που απομονώνει τα δεδομένα από τον τρόπο παρουσίασής τους, ενώ ένα ενδιάμεσο συστατικό στοιχείο της αρχιτεκτονικής αναλαμβάνει την επικοινωνία μεταξύ τους (Controller)
• Συνέπεια του προηγούμενου, είναι πως αρχιτεκτονικά παρουσιάζουν αρκετές ομοιότητες, για παράδειγμα με την ύπαρξη ενός Servlet που παραλαμβάνει τις αιτήσεις HTTP, ενός αρχείου XML που περιγράφει την μετάβαση μεταξύ των σελίδων, ένα κεντρικό αρχείο μηνυμάτων ανάλογα με το locale, κλπ
• Την προσφορά ειδικών tags ώστε να δομηθεί μια σελίδα JSP

ενώ διαφοροποιούνται σημαντικά ως προς:

• Την απεικόνιση, εσωτερική υλοποίηση και διαχείριση των στοιχείων που εισάγονται ή εμφανίζονται σε μια σελίδα (το Struts χρησιμοποιεί ειδικές κλάσεις που κληρονομούν από το (Dyn)ActionForm ενώ τα JSF απλά αντικείμενα Java (POJOs))
• Τον μηχανισμό επικύρωσης (validation) των στοιχείων που έχει εισάγει ο χρήστης
• Τη διαχείριση των γεγονότων (events) που συμβαίνουν σε μια σελίδα

Έχοντας όλα αυτά κατά νου, η μετάβαση μιας εφαρμογής Struts στο περιβάλλον JSF μπορεί, ανάλογα με την περίπτωση, να είναι μια εύκολη ή δύσκολη διαδικασία. Μια απλή, ενδεικτική μεθοδολογία μετάπτωσης, που θα μπορούσε να βοηθήσει στην εκτίμηση αυτού του κόστους, αποτελείται από τα ακόλουθα βήματα:

1. Μετατροπή όλων των υφιστάμενων Struts Form Beans σε απλά POJOs (στην ουσία Value Objects). Σε περίπτωση που υπάρχουν διαδικασίες αρχικοποίησης (μέθοδος reset() του Struts) τότε προσθέστε τον κώδικά της στον constructor του αντίστοιχου POJO. Σε περίπτωση που χρησιμοποιείτε validators (μέθοδος validate()), τότε μπορείτε να την κρατήσετε στο POJO που μόλις δημιουργήσατε και να την καλέσετε από το Backing Bean που θα παραλάβει το γεγονός (βλέπε επόμενο βήμα)
2. Μετατροπή όλων των Struts Actions σε απλά POJOs που θα περιλαμβάνουν μεθόδους που θα απευθύνονται στην διαχείριση του event που συνέβη Ας ονομάσουμε τα τελευταία ως εvent handling beans. Στην πραγματικότητα πρόκειται για αντιγραφή όλου του προηγούμενου κώδικα που βρισκόταν κάτω από την μέθοδο execute() σε μια ξεχωριστή μέθοδο του backing bean (πχ public String onSubmitClick()) Τα δεδομένα που έχουν εισαχθεί από τον χρήστη (τα Value objects του βήματος 1) θα μπορούν να γίνουν διαθέσιμα στα event handling beans διαμέσου της EL των JSF (ανατρέξτε στο άρθρο μου - JSF - Πρόσβαση στα Managed Beans)
3. Δήλωση όλων των κλάσεων του βήματος 1) και 2) στο αρχείο faces-config.xml ως backing beans.
4. Αντικατάσταση των Struts tags στις σελίδες, με τα τα κατάλληλα JSF tags. Για τους περισσότερους τύπους πεδίων δεν υπάρχει καμία ουσιαστικά διαφορά, ενώ για τη δημιουργία List Of Values (LOVs) θα πρέπει να ακολουθήσετε τις επιταγές των JSF και να κατασκευάσετε εσείς τις μεθόδους που θα τα γεμίζουν κατάλληλα. Τέλος, στα submit buttons, θα γίνει η κλήση διαμέσου EL, της κατάλληλης μεθόδου του event handling bean (πχ )

Εφαρμόζοντας τα προηγούμενα βήματα, θα πρότεινα ανεπιφύλακτα σε οποιονδήποτε ενδιαφέρεται για μια περίπτωση μετάπτωσης, να δοκιμάσει τη δοκιμαστική μεταφορά μιας σελίδας ή καλύτερα ενός use case Struts, στο περιβάλλον JSF, ώστε να αποτιμήσει το κόστος. Από τη δική μου εμπειρία, το συνεπαγόμενο κόστος είναι σχετικά μικρό, πράγμα που κάνει την απόπειρα μεταφοράς εξαιρετικά συμφέρουσα. Αλλά όπως ήδη είπαμε, αυτό ποικίλλει από περίπτωση σε περίπτωση.

JSF - Πρόσβαση στα Managed Beans

Ένας από τους βασικούς στόχους των JSF, καθώς και κριτήριο επιτυχίας τους, είναι η ευκολία της παρουσίασης δεδομένων στο Web. Για την εμφάνιση στοιχείων στις σελίδες μας και τη διαχείριση τους γίνεται χρήση απλών Java κλάσεων, που ονομάζονται Managed Beans, γιατί ακριβώς η αρχικοποίηση, ενημέρωσή τους καθώς και ο χρόνος που θα συμβεί αυτή σύμφωνα με το scope που ανήκουν, αναλαμβάνονται από το ίδιο το πλαίσιο. Πάρτε για παράδειγμα μια οθόνη εισαγωγής στο σύστημα που περιλαμβάνει δυο πεδία, κωδικό και συνθηματικό. Τα δυο αυτά δεδομένα θα πρέπει να έχουν οριστεί σε μια κλάση (για παράδειγμα AuthenticationBean), κατόπιν να έχουν οριστεί στο αρχείο διαμόρφωσης του JSF σε κάποιο scope (πχ request ή session) και στο τέλος μπορούν να ενσωματωθούν σε μία σελίδα, για παράδειγμα ως text boxes, με την βοήθεια της Expression Language (EL) με μια μορφή όπως: #{authBean.username}

Αυτά λίγο ως πολύ είναι γνωστά σε όσους έχουν ξεκινήσει τους πειραματισμούς τους με JSF. Αυτό που όμως έχει περισσότερο ενδιαφέρον είναι πως μέσα από κώδικα, για παράδειγμα ενός συμβάντος όπως το click σε ένα κουμπί, μπορούμε να ανατρέξουμε στις τιμές των Managed Beans της εφαρμογής μας. Μια συνήθης απαίτηση είναι μετά από ένα click σε ένα κουμπί login, να γίνεται ανάθεση ορισμένων βασικών τιμών σε ένα session object (έστω UserBean) που θα τηρεί πληροφορία σχετικά με τις ιδιότητες και τα προνόμια του αυθεντικοποιημένου χρήστη.

Καταρχήν, ο κώδικας που πρέπει να ενεργοποιηθεί θα βρίσκεται πίσω από το κουμπί Login. Κάτι τέτοιο μπορεί να συμβεί απλά με το να κάνουμε διπλό click σε ένα command button στον JDeveloper, που θα μας παραπέμψει στο αρμόδιο Managed Bean (έστω backing_login.java για την περίπτωσή μας). Στις επόμενες παραγράφους, θα παραθέσουμε εναλλακτικές μεθόδους άντλησης και ανάθεσης τιμών από / σε ένα Managed Bean (εδώ μια μικρή παρένθεση για υπενθυμίσουμε πως όταν θα εκτελεστεί ένα συμβάν, έχει ήδη γίνει ενημέρωση του μοντέλου σε πρότερη φάση ώστε να είναι διαθέσιμες οι έγκυρες του τιμές κατά την διαδικασία επεξεργασίας του συμβάντος):

1) Χρησιμοποιώντας το external context της εφαρμογής. Για να έχουμε πρόσβαση είτε στο request scope της εφαρμογής είτε στο session, αρκεί να γράψουμε:

FacesContext.getCurrentInstance().getExternalContext().getSession(true);
FacesContext.getCurrentInstance().getExternalContext().getRequest();

οπότε μπορούμε να ανακτήσουμε σύνδεση στα low-level servlet APIs των HttpServletRequest και HTTPSession και να βρούμε ή να ενημερώσουμε τα αντικείμενα που μας ενδιαφέρουν (το authBean και το UserBean στην συγκεκριμένη περίπτωση)

2) Διαμέσου της Expression Language (EL) Την EL μπορούμε να την αξιοποιήσουμε όχι μόνο στις σελίδες μας, αλλά ακόμα και στον κώδικά μας. Για παράδειγμα στη μέθοδο που εκτελείται με το πάτημα ενός κουμπιού, μπορούμε να αντλήσουμε την τιμή ενός πεδίου ως εξής:

FacesContext context = FacesContext.getCurrentInstance();
Application app = context.getApplication();
String username = (String)app.createValueBinding("#{authBean.username}").getValue(context);

ή ακόμα καλύτερα ολόκληρου του object ως εξής:

FacesContext context = FacesContext.getCurrentInstance();
Application app = context.getApplication();
AuthenticationBean authBean = (AuthenticationBean)app.createValueBinding("#{authBean}").getValue(context);

και φυσικά με τα δεδομένα που πήραμε, μπορούμε να μεταβάλλουμε τιμές ανάλογα:

app.createValueBinding("#{userBean.username}").setValue(context, username);

3) Ενσωματώνοντας (encapsulate) το αντικείμενο που μας ενδιαφέρει μέσα στο Managed Bean που θα αναλάβει την διαχείριση του συμβάντος. Στην προκειμένη περίπτωση, δηλώνοντας αρχικά στο faces-config.xml για το backing_login.java (η κλάση που θα αναλάβει την διαχείριση του click του κουμπιού login) ότι θα περιλαμβάνει ως Managed Bean property, ένα αντικείμενο με όνομα ίδιο με το AuthenticationBean και με την αρχική τιμή: #{authBean} Ένα από τα ισχυρά χαρακτηριστικά του JSF είναι ότι επιτρέπεται η χρησιμοποίηση EL ακόμα και μέσα στο configuration file. Σε αυτήν την περίπτωση, δηλώσαμε ένα καινούργιο πεδίο στο managed bean, που θα έχει ως τιμή, την request τιμή του αντικειμένου authBean. Το μόνο που απομένει είναι να ορίσουμε στο backing_login.java τα getters/setters για το authBean και μετά είμαστε σε θέση να το αξιοποιήσουμε μέσα στην μέθοδο εκτέλεσης του συμβάντος ως:

authBean.getUsername();





Ο τελευταίος τρόπος είναι ιδιαίτερα χρήσιμος αν πρόκειται να αναφερθούμε εκτεταμένα σε ένα αντικείμενο, καθώς επίσης μας απαλλάσσει από λάθη στο όνομα του Managed Bean που θέλουμε να κάνουμε reference, όπως θα συνέβαινε στις περιπτώσεις 1) και 2)

JSF - Δημιουργία Data Bindings στον Property Inspector

Κατά τη διάρκεια της εργασίας μας με σελίδες JSF είναι δυνατόν να θέλουμε να αναθέσουμε σε κάποια στοιχεία, όπως για παράδειγμα πεδία εισαγωγής (input fields) ή πεδία εμφάνισης (output fields), τιμές από το binding context της εφαρμογής ή της σελίδας. Για να γίνει αυτό από τον Property Inspector, απλά πηγαίνουμε στο πεδίο που μας ενδιαφέρει και πληκτρολογούμε "#{}" και μετά πατάμε Enter.













Τότε, θα εμφανιστεί ένα κουμπάκι με 3 τελείες που κάνοντας το click, θα μας οδηγήσει στον Data Binding Editor.