unicon warlock portlets a.k.a. toro-portlets andrew wills ja-sig 2007 summer conference, denver...

28
UNICON Warlock Portlets A.K.A. toro-portlets Andrew Wills JA-SIG 2007 Summer Conference, Denver Tuesday June 26th, 2007 © Copyright Unicon, Inc., 2006. 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.

Upload: beryl-matthews

Post on 27-Dec-2015

216 views

Category:

Documents


0 download

TRANSCRIPT

UNICON Warlock PortletsA.K.A. toro-portlets

Andrew WillsJA-SIG 2007 Summer Conference, Denver

Tuesday June 26th, 2007

© Copyright Unicon, Inc., 2006. 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 2.4.2

– Notification Portlet

– Permissions Portlet

– Gateway (SSO) Portlet

– Blogging Portlet

– WCM Portlet

Warlock Present & Future

• Academus Portal 2.1, March 2007

– Based on uPortal 2.5.3

• Open Toro, Q2 2007

– 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

http://code.google.com/p/toro-portlets

• GoogleGroups Discussion

http://groups.google.com/group/toro-projects

• Installation Instructions

http://code.google.com/p/toro-portlets/wiki/Deployment_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:

http://code.google.com/p/toro-portlets/wiki/Deployment_Instructions

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 http://toro-portlets.googlecode.com/svn/trunk/academus-api/

svn checkout http://toro-portlets.googlecode.com/svn/trunk/academus-apps/

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

<!-- Registers a uPortal-based Academus Facade for the Academus Portlets -->

<service>

<name>uPortal Academus Facade</name>

<class>net.unicon.academus.api.uportal.UPortalAcademusFacade</class>

<method type="static">register</method>

</service>

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<String,String[]>)

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

<screen handle="welcome">

<layout> <section type=“header”><h2>Welcome to your Briefcase</h2></section> <section type=“pagetext”> <choice-collection handle=“content”> <choice handle=“goLocation” min-selections=“0” max-selections=“1”> <ul class=“no-bullet no-pad”> <call-template handle=“drive” select=“/state/briefcase/drive”/> </ul> </choice> </choice-collection> </section> </layout> <template> <li><link><action handle=“nav” impl=“net.unicon.academus.briefcase.GoToFolderAction”> <label><value-of select=“label”/></label> <option handle=“{@handle}” complement-type=“net.unicon.penelope.TypeNone”/> </action></link></li> </template>

</screen>

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 [email protected]

www.website.com

Questions?