Managed Beans
Transcription
Managed Beans
XPages Application Development for Mobile and Web Browser Applications using Java Chris Connor BSS IT Solutions Agenda for today – Developer Track Introduction Background Structure for the day What is Xpages / Where does Java fit? Why use it “above” SSJS Demonstration of Applications Review of Underlying Code / Technologies Managed Beans Excel Export Workflow Validation Deployment as OSGI Plugins as a library Resources and Next Steps Agenda for today – Developer Track Mobile Applications – Approach Demonstration of a sample web application Built with Extension Library Resources and Next Steps Introduction – Structure / format First Session is presentation based (2 Sections) Look at Xpages and Java as a subject Look at Mobile as a subject Slides / Demos Second Part – BOF Loosely based around session 1 Questions from you about whatever YOU choose! Pull apart code / discuss Introduction - Background BSS IT Solutions XPages Eclipse RCP Mobile Classic Domino Development Web / Dojo / JQuery / Java Development Sold own systems for office automation ● Time Recording, Expenses, PO Requisitions – Plans to “upgrade” Blog - XSPTalk.com OpenNTF contributor XDesk Developer since 1995 days Background - My Recent Engagements Working with Customers in the UK Mentoring ● Setting up an Xpages “Framework” ● Skills transfer / Training ● Defining Development approaches for mobilisation ● Advising where Xpages works / does not work Development of Solutions ● Knowledge Management System for Consulting Engineers Firm ● Travel authorisations system for subsidiary of British Airways ● Requisition application for Public Sector organisation Through all of this ● How do we make this easy to maintain ● How do we build TEMPLATES for the future Why “invest” in Java for XPages Makes Developers Life Easier Store code in Java Classes / Libraries ● Better Re-use ● Better Design / Extending Better Eclipse Editor for Development ● SSJS Editor is not the best… – Can “inspect classes” easier – F3 / F4 Encourages a clean design in terms of XML / Xpages design ● Less inline code Access to vast of code APIs / libraries / classes ● Documented! Access to vast network of support Why “invest” in Java for XPages Skill set that is in demand Skill set that is re-usable / transferable If you are a Java house then it makes sense If you are a consultant – more opportunities Access to other Java Developments Subversion / OSGI / Junit / Eclipse Platform RCP Plugins / Mobile Development similarities (one language) Help borrow approaches from other JSF platforms Xpages is JSF (relatively new) Can learn from other environments Many reasons – hopefully we can explore just a few today Tools and Skills you need Tools Domino Designer / Server XPages / Extension Library “Decompiler” for Java Firebug for Firefox ● Chrome / Safari Debugger Emulator (such as ripple) ● Chrome / Safari Skills HTML / JavaScript / CSS (Web Developer) XSP (XML Language based on JSF) Notes Object Knowledge (Basic Notes Developer) Java Back to Basics – What is XPages? JSF based Development Framework JavaScript (Client and Server side) AJAX Dojo Tookit Java Scripting can be applied with SSJS JavaScript (extended to work with Notes Objects and the Xpages Java Framework) Xpages / Custom Controls are compiled to Java 99% of all my code is Java Called from SSJS as managed beans Called from EL Demo Demo of example Workflow Application Simple Workflow Application ● Uses Extension Library One UI ● Workflow configured with “Config Documents” Managed Beans Export to Excel Validation Classes as OSGI Plugins XPages – What happens when we write them? How do we start writing them? Designer Drag and drop components onto palette ● Configure ● Tie business logic scripting / java to events Write / Edit XML natively Note* They are complied to JAVA and executed by the XSP runtime environment Design Representation Source (XML) Representation Complied to Java to be executed Code Walkthrough Look at “Request” XPage General Modular Construction – Custom Controls Data Bindings for document1 Framework Layout using One UI from Extension Library Code Walkthrough – General Layout Managed Beans What are “Managed Beans” POJO – configured with getters / setters Implements “Serializable” (so XSP can read / write from disk Can be scoped (in Xpages) ● Request ● View ● Session ● Application Very useful for Providing universal access to common lookups Providing “states” in an application ● e.g shopping cart / “one to many” tables Managed Beans Very Useful for • Calling your Java Libaries easily • BeanName.doMethod() or BeanName.someproperty – uk.bssuk.net.domino.data.ObjectName.doMethod() Do Not! Try to scope Domino Objects • They are C++ Objects and are subject to unpredictable garbage collection (eg NotesDocument, NotesDatabase) • Instead work with primitive types and objects such as String, ArrayLists, HashMaps etc. • Eg Where a document is required use the UNID instead (String) Managed Beans – Lookups – Use Case Most databases have lookup lists (Keywords) Should decide on which ones are common Keep in a library for sharing across all databases App Specific can reside in a class(es) Goal from Expression Language / SSJS Simple call syntax eg Lookup.Locations Cached for the appropriate Life Cycle (Good for Performance) ● Session ● Application ● Request / View Managed Beans Code – First We Declare Find and Edit the Faces-Config.xml file Go to the Java Perspective ● Package Explorer Register your bean by adding XML Contents as shown Managed Beans – Add POJO code Now Available Getter / Setter Methods Now Available for SSJS / EL A simple call to the bean will get us a cached version of whichever property we want ArrayLists Strings Objects Not Domino Objects! • More efficient than lots of @DBLookups everywhere • Deploy in an OSGI library available for all applications Managed Beans – Line Items – Use Case Many applications have one-to-many tables Order line items Expenses Line Items Managed Beans help with this Provide a flexible structure for modeling Abstract out data ● No need to worry at early development ● Could be response docs ● Related docs by key ● Relational database table(s) Managed Beans – Line Items – Use Case Use a classic MVC Create a controller class for managing the POJO objects ● Adding ● Removing ● Updating POJO objects are real life objects (the line items) ● Controlled by the controlling class The objects are then “written to disk” as appropriate by classes performing data operations ● This stage the appropriate data definitions can be defined ● Response Documents / Related Documents ● Data Structures - RDBMS Managed Beans – Line Items – Steps Find and Edit the Faces-Config.xml file Go to the Java Perspective ● Package Explorer Register your bean by adding XML Contents as shown Managed Beans – Controller Class ArrayLists for containing Person Objects An arraylist is bound to a repeat control Methods for adding / removing Person Objects When the save button is pressed on xpage these objects are “written to disk” Steps for Setting Excel Export in Library Build Java Class Package up into OSGI bundle Distribute to developers Install on Server Register as Managed Bean Request Scoped Link opens an Xpage – which has one line of code Export Class – exportViewcolumns() Class contains several methods This method exports all documents Takes a NotesView as a parameter Exports all documents Exports all columns Export Class – exportViewColumns() Export Class – writeCurrentColumnEntry Writes out the current selected Entry (document) Series of <tr><td>xxxx</td></tr> Generic Workflow Process What is a typical workflow process? Document that changes its “Status” ● Visible on the document ● Visible on views / reports Email Notifications Document Section Visibility ● Buttons (and other components such as fields) ● Sections / Areas of forms Security ● Readership ● Authorship Typically Triggered by a Button We can therefore build a generic process that ties these aspects together Benefits of Generic Workflow Process Where requirements are not clear Users often want “workflow” but have not thought about exactly how this works We can mock up and demo quickly We can change quickly as the user understands how this works by configuration and not development. Better quality and more stable Provide a uniform approach All applications behave the same Easier to maintain Extendable through sub-classing where necessary Demo Workflow Step 1 – Action Driven Typically From Buttons Example – “Submit” button – control visibility of display Visible in “Draft” mode – ie status is blank Step 2 – Execute SSJS – 1 Line Executes the following SSJS Lightweight code Attached to button onclick event DocumentOperations.writeDocument() method Important Parameters ● ArrayList to write to disk ● ArrayList to delete from disk ● Document Object ● Compare Object Step 3 – Run writeDocument() method Executes the following Lightweight code DocumentOperations.writeDocument() method Important Parameters ● ArrayList to write to disk ● ArrayList to delete from disk ● Document Object ● Compare Object Step 3 – runWriteDocument() method DocumentOperations.doButtonvalidation(ArrayList) Returns true or false to the fields required property Step 4 – Workflow Class / Object Main engine for workflow Reads configuration parameters which maps actions to ● Document Readership ● Document Authorship ● Status field setting ● Emailing ● Next page to display Step 4 – Workflow Class / Object Stored in an OSGI plugin Will deal how that’s done in a different stage Available Globally to all applications Workflow Class has various properties read from config ● Document Readership ● Document Authorship ● Status Field ● Email Subject ● Email Recipients etc The Workflow Class is registered as a managed bean and properties are available Workflow.readers Workflow.subject Workflow.status (the status that its moving to) Step 4 – Workflow Class / Object So example if the recipients field is not null Evaluate the following Formula from the config document “MailSubject” field on the current document. Step 4 – Workflow Class / Object Subject Formula = “Text”+ID+”Text” Does this with all the parameters in the config document. Step 5 – Send Email and Redirect Page Uses Email class Formats a message with a URL link in it Sets sendto, subject etc Redirects browser to “Next Page” Simple Validation Checkbox on a field Produces a nice message which is configurable The Issue Any refresh event could trigger this message Only want to target validation in certain circumstances ● Such as a specific button or event triggering Demo the issue Step 1 – Hijack “Required” In the GUI fields are “Required” – COMPUTE! We need to compute the circumstances when this field is required Run method to compute Boolean Lookup.tablebuttonids Managed Bean Property (ArrayList) Of Event ids that you want to trigger this validation DocumentOperations.doButtonvalidation(ArrayList) Returns true or false to the fields required property