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