UNICON Warlock Portlets A.K.A. toro-portlets Andrew Wills JA-SIG 2007 Summer Conference, Denver Tuesday June 26th, 2007 © Copyright Unicon, Inc., This work is the intellectual property of Unicon, Inc. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of Unicon, Inc. To disseminate otherwise or to republish requires written permission from Unicon, Inc.

1.Introduction & History 2.Deployment 3.Demos 4.About Warlock

Introduction & History

Introduction The Warlock Portlets are a collection of JSR-168 Portlets developed by UNICON for its Academus Portal product “Warlock” is the name for a home-grown MVC & Rendering framework used by these portlets UNICON has released its Academus technology into open source The portlets based on Warlock are available as toro- portlets

History of Warlock Portlets Academus Portal 1.5, March 2005 –Based on uPortal 2.3 –Warlock Introduced –Briefcase Portlet Academus Portal 2.0, October 2005 (EDUCAUSE) –Based on uPortal –Notification Portlet –Permissions Portlet –Gateway (SSO) Portlet –Blogging Portlet –WCM Portlet

Warlock Present & Future Academus Portal 2.1, March 2007 –Based on uPortal Open Toro, Q –Targets uPortal 2.6 –Includes several components toro-portlets toro-channels toro-ipaq toro-sdk toro-resource-pool

toro-portlets on the Web Project Home Page GoogleGroups Discussion Installation Instructions

Makeup of toro-portlets toro-portlets is composed of several modules: academus-api (portal-to-portlet communication) academus-apps (portlet implementations) alchemist (smaller utilities) civis (groups & group memberships API) demitrius (file system like structures API) mercury (messaging API) warlock (MVC & Rendering)

Deployment

toro-portlets Deployment Covered in greater detail at this address: Prerequisites: JDK 5 or later JSR-168 compliant portlet container (uPortal) Subversion Jakarta Ant

toro-portlets Deployment (Cont.) Deployment Summary 1.Download toro-portlets from Source 2.Configure toro-portlets properties 3.Compile & Deploy 4.Create the database schema 5.Configure your portal

1. Download toro-portlets Use Subversion to obtain toro-portlets source code from GoogleCode You will need the academus-api component and the academus-apps component svn checkout svn checkout

2. Configure toro-portlets academus-api/build.properties –tomcat.home (location of Tomcat installation) academus-apps/build.properties (15 total settings) –tomcat.home (as above) –portal.name (name of portal webapp) –ACADEMUS_WEBAPP_NAME (same as portal.name) –HOSTNAME –WEBSERVER_HOST_NAME (same as HOSTNAME) –WEBSERVER_FULLHTTPPORT academus-apps/properties/rdbm.properties –Database connection settings –Hibernate dialect

3. Compile & Deploy From academus-api: > ant deploy From academus-apps*: > ant deploy * uPorta-specific logic

4. Create Database Schema You must place a copy of your database driver JAR in the academus-apps/lib/ directory From academus-apps: > ant db WARNING: Invoking the ‘db’ target again will reset the toro-portlets database!

5. Configure Your Portal You must support the user.login.id attribute Add the uPortalAcademusApiImpl.jar archive the WEB-INF/lib/ directory in uPortal Add the following to properties/services.xml You must re-deploy your portal for the changes to take effect uPortal Academus Facade net.unicon.academus.api.uportal.UPortalAcademusFacade register

Demos

Briefcase Portlet

Notifications Portlet

Warlock Overview

What is Warlock? “Warlock is a framework for Java applications developed by, designed for, and employed by UNICON” Warlock has two essential responsibilities –State Machine (MVC) –Templating (Rendering Markup)

Why Warlock? In essence, Warlock was created because the Academus team was experiencing a Warlock-shaped gap in their tool belt Most web development frameworks couldn’t handle portlets Spring Portlet MVC wasn’t seriously considered because –It was a sandbox project (no GA release) –Early examples weren’t impressive

Goals of Warlock We aimed to… 1.Empower the UE team to take ownership of the UI 2.Create an environment where Java & UE professionals could collaborate each in their own time 3.Promote application states & actions to first-class objects (MVC) 4.Break out of the 1:1 ratio of applications screens to XSL files 5.Model user input in a richer set of types (not Map ) 6.Discover inconsistencies between UI & Controller data sets at the earliest possible time

Developing in Warlock First you… 1.“Skin” your Warlock with a master XSLT (a.k.a Modulo) And then you… 1.Prepare Screen Definition Files (team UE) 2.Develop IAction implementations 3.Develop IStateQuery implementations 4.Bootstrap a StateMachine in a class that extends WarlockPortlet

Screen Definition Files These files declare the contents of a screen in an XML syntax Warlock consumes some elements to create IScreen objects Everything else is consumed by the master XSLT (Modulo) Use XPath expressions ad-hoc within {} delimiters to render application data from an IStateQuery implementation

Example Screen Definition Welcome to your Briefcase

Was Warlock a Success? If you ask me… “Yes – we accomplished our goals.” But that doesn’t mean Warlock is the right choice for your project, because: –Academus development employed a separate, dedicated team of UE professionals –We hit our targets for flexibility, but didn’t make accessibility enough of a priority

Presenter Name Questions?