WIN
REGISTER YOUR BOOK
ibmpressbooks.com/ibmregister
REGISTRATION ENTITLES YOU TO:• Supplemental materials that may be available • Advance notice of forthcoming editions
• A coupon that can be used on your next purchase from ibmpressbooks.com
IBM PRESS NEWSLETTER
Sign up for the monthly IBM PRESS NEWSLETTER at
ibmpressbooks.com/newsletters
LEARN
•
NEW PODCASTS
from your favorite authors
•
ARTICLES & INTERVIEWS
with authors
•
SPECIAL OFFERS
from IBM Press and partners
•
NOTICES & REMINDERS
about author appearances and conferences
Visit ibmpressbooks.com
for all product information
Sign up for the IBM PRESS NEWSLETTER and
you will be automatically entered into a
QUARTERLY GIVE-AWAY
for 3 months access to Safari Books Online –
online access to more than 5000 books
A $150 VALUE!
Service-Oriented
Architecture (SOA) Compass
Business Value, Planning,and Enterprise Roadmap by Norbert Bieberstein, Sanjay Bose, Marc Fiammante, Keith Jones, and Rawn Shah ISBN: 0-13-187002-5
In this book, IBM® Enterprise Integration Team
experts present a start-to-fi nish guide to plan-ning, implementing, and managing Service-Oriented Architecture. Drawing on their extensive experience helping enterprise customers migrate to SOA, the authors share hard-earned lessons and best practices for architects, project manag-ers, and software development leaders alike. Well-written and practical, Service-Oriented Architecture Compass offers the perfect blend of principles and “how-to” guidance for transitioning your infrastructure to SOA. The authors clearly explain what SOA is, the opportunities it offers, and how it differs from earlier approaches. Using detailed examples from IBM consulting engage-ments, they show how to deploy SOA solutions that tightly integrate with your processes and operations, delivering maximum fl exibility and value. With detailed coverage of topics ranging from policy-based management to workfl ow implementation, no other SOA book offers comparable value to workingIT professionals.
WebSphere Business
Integration Primer
Process Server, BPEL, SCA, and SOA by Ashok Iyengar, Vinod Jessani, and Michele Chilanti
ISBN: 0-13-224831-X
Using WebSphere® Business Integration (WBI)
technology, you can build an enterprise-wide Business Integration (BI) infrastructure that makes it easier to connect any business resources and functions, so you can adapt more quickly to the demands of customers and partners. Now there’s an introductory guide to creating standards-based process and data integration solutions with WBI.
WebSphere Business Integration Primer
thoroughly explains Service Component Architecture (SCA), basic business processes, and complex long-running business fl ows, and guides you to choose the right process integration architecture for your requirements. Next, it intro-duces the key components of a WBI solution and shows how to make them work together rapidly and effi ciently. This book will help developers, technical professionals, or managers understand today’s key BI issues and technologies, and streamline business processes by combining BI with Service Oriented Architecture (SOA).
Related Books of Interest
Related Books of Interest
InThe New Language of Business, senior IBM executive Sandy Carter demonstrates how to leverage SOA, Web 2.0, and related technologies to drive new levels of operational excellence and business innovation.
Writing for executives and business leaders inside and outside IT, Carter explains why fl exibility and responsiveness are now even more crucial to success — and why services-based strategies offer the greatest promise for achieving them. You’ll learn how to organize your business into reusable process components — and support them with cost-effective IT services that adapt quickly and easily to change. Then, using extensive examples — including a detailed case study describing IBM’s own experience — Carter identifi es best practices, pitfalls, and practical starting points for success.
Listen to the author’s podcast at: ibmpressbooks.com/podcasts
Executing SOA
A Practical Guide for the Service-Oriented Architect
by Norbert Bieberstein, Robert G. Laird, Dr. Keith Jones, and Tilak Mitra ISBN: 0-13-235374-1
InExecuting SOA, four experienced SOA implementers share realistic, proven, “from-the-trenches” guidance for successfully delivering on even the largest and most complex SOA initiative. This book follows up where the authors’ best-selling Service-Oriented Architecture Compass
left off, showing how to overcome key obstacles to successful SOA implementation and identifying best practices for all facets of execution— technical, organizational, and human. Among the issues it addresses: introducing a services discipline that supports collaboration and information process sharing; integrating services with preexisting technology assets and strategies; choosing the right roles for new tools; shifting culture, governance, and architecture; and bringing greater agility to the entire organizational lifecycle, not just isolated projects.
Related Books of Interest
Sign up for the monthly IBM Press newsletter at
ibmpressbooks/newsletters
Enterprise Java
Programming with
IBM WebSphere
Second Editionby Kyle Brown, Dr. Gary Craig, Greg Hester, David Pitt, Russell Stinehour, Mark Weitzel, Jim Amsden, Peter M. Jakab, and Daniel Berg ISBN: 0-321-18579-X
Enterprise Java™ Programming with IBM
WebSphere, Second Edition is the defi nitive guide to building mission-critical enterprise systems with J2EE™, WebSphere, and WebSphere
Studio Application Developer. Fully updated for Versions 5.x of WebSphere Application Server and WebSphere Studio Application Developer, it combines expert architectural best practices with a case study that walks you through constructing an entire system.
Rapid Portlet
Development
with WebSphere
®Portlet Factory
IBM WebSphere
[SUBTITLE ]
Deployment and Advanced
Configuration
Roland Barcia, Bill Hines, Tom Alcott, and Keys Botzum
Rapid Portlet
Development with
WebSphere
®
Portlet Factory
Step-by-Step Guide for Building
Your Own Portlets
David Bowley
IBM Press Pearson plc
Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York • Toronto • Montreal • London • Munich • Paris • Madrid Cape Town • Sydney • Tokyo • Singapore • Mexico City
The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.
© Copyright 2009 by International Business Machines Corporation. All rights reserved.
Note to U.S. Government Users: Documentation related to restricted right. Use, duplication, or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corporation.
IBM Press Program Managers: Tara Woodman, Ellice Uffer Cover Design: IBM Corporation
Associate Publisher: Greg Wiegand Marketing Manager: Kourtnaye Sturgeon Publicist: Heather Fox
Acquisitions Editor: Katherine Bull Development Editor: Kevin Howard Managing Editor: Kristy Hart Designer: Alan Clements Senior Project Editor: Lori Lyons Copy Editor: Deadline Driven Publishing Indexer: WordWise Publishing Services Compositor: Nonie Ratcliff
Proofreader: Water Crest Publishing Manufacturing Buyer: Dan Uhrig Published by Pearson plc Publishing as IBM Press
IBM Press offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact:
U. S. Corporate and Government Sales 1-800-382-3419
corpsales@pearsontechgroup.com For sales outside the U.S., please contact:
International Sales
The following terms are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both: IBM, the IBM logo, IBM Press, DB2, Domino, Domino Designer, Lotus, Lotus Notes, Rational, and WebSphere. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of the Microsoft Corporation in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds. Intel, Intel Inside (logo), MMX, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.
Library of Congress Cataloging-in-Publication Data
Bowley, David.
Rapid portlet development with WebSphere portlet factory : step-by-step guide for building your own portlets / David Bowley.
p. cm. Includes index.
ISBN 0-13-713446-0 (hardback : alk. paper) 1. Web portals—Computer programs. 2. User interfaces (Computer systems) Computer programs. 3. Web site development. 4. WebSphere. I. Title.
TK5105.8885.W43B69 2008 006.7’6—dc22
2008029014
All rights reserved. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to:
Pearson Education, Inc
Rights and Contracts Department 501 Boylston Street, Suite 900 Boston, MA 02116
Fax (617) 671 3447 ISBN-13: 978-0-13-713446-5 ISBN-10: 0-13-713446-0
xi
Contents at a Glance
Foreword xxvii
Preface xxix
Acknowledgments xxxiii
About the Author xxxv
Chapter 1 Introduction to WebSphere Portlet Factory 1
Chapter 2 Providing and Consuming Services 37
Chapter 3 Using Data from a Relational Data Source 53
Chapter 4 Using Domino Data 77
Chapter 5 Customizing Portlet Appearance 107
Chapter 6 Adding Basic User Interface Controls to Your Portlets 149
Chapter 7 Communicating Between Portlets 165
Chapter 8 Using Java in Portlets 195
Chapter 9 Using Web Services and Manipulating XML 239
Chapter 10 Using Charts in Portlets 267
Chapter 11 Field Validation, Formatting, and Translation 293
Chapter 12 Profiling Portlets 323
Chapter 13 Using Ajax and Dojo 345
Chapter 14 Error Handling, Logging, and Debugging Portlets 371
Chapter 15 Performance and Process Optimization 393
Chapter 16 More Techniques for Domino 413
Appendix A Setting Up your Environment 439
Appendix B Portlet Factory Properties 461
Glossary 475
xiii
Contents
Foreword xxvii
Preface xxix
Acknowledgments xxxiii
About the Author xxxv
Chapter 1 Introduction to WebSphere Portlet Factory 1
What Is a Portal and What Are Portlets? 2
Portal Key Benefits 3
What Is WPF? 4
WPF Key Benefits 4
WPF Architecture 5
Builders 5
Models 6
Profiles 7
Generating and Executing the WebApp 7
Portlet Factory WAR Files 11
Deployment Configurations 12
Introduction to the WebSphere Portlet Factory Designer 13
The User Interface 13
Folder Structure 17
Building Your First Portlet 21
Creating a Project 21
Manual Deployment 26
Creating a Model 30
Testing the Application 31
Summary 35
Chapter 2 Providing and Consuming Services 37
The Service Provider/Consumer Pattern 37
Creating a Service Provider 39
Creating a Model 40
Defining the Service 41
Adding Roster Data 42
Adding an Action to Retrieve a Roster 43
Adding a Service Operation 43
Testing the Service Provider 44
Creating a Service Consumer 45
Creating a Model 46
Configuring the Portlet Adapter 47
Testing the Service Consumer 47
Creating a Stub Service 48
Applying the Service Provider/Consumer Pattern 49
Summary 51
Important Points 51
Chapter 3 Using Data from a Relational Data Source 53
Using Data Services 53
Creating a Service Provider 54
Creating a Model 54
Defining the Service 55
Specifying the First Operation 55
Specifying the Second Operation 55
Specifying the Third Operation 56
Specifying the Fourth Operation 57
Specifying the Fifth Operation 58
Testing the Service Provider 60
Testing the retrieveContactsView Operation 61 Testing the getContactDetail Operation 62
Testing the createContact Operation 63
Testing the setContact Operation 63
Testing the deleteContact Operation 63
Creating a Contacts Portlet 63
Creating a Model 64
Configuring the Portlet Adapter 65
Adding Update Functionality 65
Adding Delete Functionality 66
Adding Create Functionality 69
Testing the Contacts Portlet 72
Summary 74
Important Points 75
Chapter 4 Using Domino Data 77
Portalizing Notes Functionality 78
Configuring Your Environment 79
Configuring the Domino Properties File 80
Testing the Connection to Domino 81
Creating a Service Provider 82
Creating a Model 82
Defining the Service 83
Specifying Operations 83
Adding a Delete Operation 85
Testing the Service Provider 88
Testing the readSupplierView Operation 88 Testing the readSupplierDocument Operation 89 Testing the updateSupplierDocument Operation 90 Testing the createSupplierDocument Operation 90 Testing the deleteSupplierDocument Operation 90
Creating a Suppliers Portlet 91
Creating a Model 91
Configuring the Portlet Adapter 93
Adding Update Functionality 94
Adding Delete Functionality 94
Adding Create Functionality 97
Removing Unwanted Fields 99
Testing the Service Consumer 100
Using a Stub Service 102
Creating a Stub Model 103
Using the Stub Model 104
Summary 105
Important Points 105
Chapter 5 Customizing Portlet Appearance 107
Customizing Portlet Appearance 108
Creating a Service Provider 108
Creating a Model 109
Defining the Service 109
Adding an Asset Schema 109
Adding Asset Data 110
Adding an Action to Retrieve a List of Assets 112 Specifying the getAssetsList Operation 112
Testing the Service Provider 113
Creating an Assets Portlet 114
Creating a Model 114
Adding a Portlet Adapter 114
Consuming the Service 114
Displaying Assets Data 114
Testing the Assets Portlet 117
Pagination 119
Turning on Pagination 120
Modifying the Paging Buttons 120
Data Modifiers 122
The Data Column Modifier Builder 122
The Data Hierarchy Modifier Builder 124
The Data Field Modifier Builder 124
The Form Layout Builder 127
Working with Web Pages 132
HTML Builders 133
JSP Builders 135
JavaScript 135
HTML Templates 137
Cascading Style Sheets 142
Adding a Style Sheet 144
Summary 146
Important Points 146
Chapter 6 Adding Basic User Interface Controls
to Your Portlets 149
User Interface Controls in WPF 149
Creating a Survey Portlet 151
Creating a Model 151
Modifying the Page 152
Adding a Portlet Adapter 153
Testing the Survey Portlet 160
Summary 163
Important Points 164
Chapter 7 Communicating Between Portlets 165
The Benefits of Inter-Portlet Communication 166
The WebSphere Property Broker 166
Creating a Service Provider 167
Creating a Model 168
Defining the Service 168
Adding Loan Data 168
Adding an Action to Retrieve a List of Loans 169 Specifying the getLoansList Operation 170 Adding a Method to Retrieve a Specific Loan 170 Specifying the getLoanDetail Operation 171
Testing the Service Provider 171
Creating a List Portlet 173
Creating a Model 173
Specifying the Service 173
Specifying List and Detail Operations 174
Configuring the Portlet Adapter 175
Defining the Portlet as a Cooperative Source 176
Testing the List Portlet 177
Creating a Detail Portlet 177
Creating a Model 178
Adding a Default Message Page 179
Adding a main Action 179
Adding an Interface for Loan Details 179
Defining the Portlet as a Cooperative Target 180 Handling an Inter-Portlet Communication Event 181
Testing the Detail Portlet 182
Configuring the WebSphere Property Broker 183
Testing Inter-Portlet Communication 184
Alternative Communication Methods 184
Property Broker Action 185
WPF Event Model 186
Shared Variables 189
Configuring Actions for loansList 191
Running selectLoan 192
Using the Shared Variable in the loanDetail Model 192
Click-to-Action (C2A) 192
When to Use Inter-Portlet Communication 192
Summary 193
Important Points 193
Chapter 8 Using Java in Portlets 195
Java Development Considerations 196
Java Methods 198
Inline Java 198
Action Lists 200
The Method Builder 200
The Linked Java Object Builder 201
Java Application Programming Interfaces 202
Java Beans 210
Creating a Java Bean and Bean Manager 210
Creating a Shopping Cart Item Bean 211
Creating a Shopping Cart Item Manager 213
Creating a Service Provider 216
Creating a Model 217
Defining the Service 217
Adding a Linked Java Object 217
Adding a Java to XML Converter 217
Clearing a Shopping Cart 218
Viewing a Shopping Cart 219
Viewing a Shopping Cart Item 221
Adding a Shopping Cart Item 222
Updating a Shopping Cart Item 223
Deleting a Shopping Cart Item 223
Testing the Service Provider 224
Testing the addShoppingCartItem Operation 225 Testing the viewShoppingCart Operation 225 Testing the viewShoppingCartItem Operation 225 Testing the updateShoppingCartItem Operation 226 Testing the deleteShoppingCartItem Operation 226 Testing the clearShoppingCart Operation 226
Creating a Shopping Cart Portlet 226
Creating a Model 226
Configuring the Portlet Adapter 228
Implementing the updateShoppingCartItem Operation 228 Implementing the addShoppingCartItem Operation 229 Implementing the clearShoppingCart Operation 229 Implementing the deleteShoppingCartItem Operation 230
Testing the Shopping Cart Portlet 232
Testing the Add Item Button 232
Testing the Edit Item Button 233
Testing the Delete Item Button 233
Testing the Clear Cart Button 233
Java Archives 234
Importing JARs 234
Excluding JARs from WAR Files 235
Summary 236
Important Points 236
Chapter 9 Using Web Services and Manipulating XML 239
Web Services in WPF 240
Creating an Order Stock Web Service 242
Creating a Model 243
Defining the Service 243
Defining the Request Object 243
Defining the Response Object 245
Adding Order Data 246
Adding a Method to Place a Stock Order 246
Adding a Service Operation 251
Testing the orderStockWebService Web Service 252
Creating a Service Provider 255
Creating a Model and Defining the Service 255
Calling the Web Service 256
Adding a Service Operation 257
Testing the Service Provider 258
Creating an Order Stock Portlet 258
Creating a Model 259
Modifying the Page 259
Adding a Portlet Adapter 260
Consuming the Service 260
Creating a Variable to Store the Request 260
Displaying the Interface 260
Adding Submit Functionality 261
Testing the Order Stock Portlet 262
XML Transform Builders 263
Chapter 10 Using Charts in Portlets 267
Charting Data in WPF 268
Creating a Service Provider 269
Creating a Model 269
Defining the Service 270
Adding Sales Data 270
Adding a Sales Schema 271
Adding an Action to Retrieve Sales Data 271
Specifying the getSales Operation 271
Testing the Service Provider 272
Creating a Sales Chart Portlet 273
Creating a Model 273
Modifying the Page 273
Modifying the Main Action List 274
Adding a Portlet Adapter 274
Consuming the Service 275
Adding a Chart 275
Configuring the Data Transformation 276
Specifying Chart Properties 277
Specifying Minimum Scale Values 277
Testing the Test Data Portlet 278
Adding Drill-Down Capabilities 279
Adding Temporary Variables 280
Defining the Transform 280
Specifying a Method to Get the Current Sales Item 282 Specifying an Action for the getSalesArea Operation 283 Specifying the getSalesArea Operation 283
Testing the getSalesArea Operation 284
Adding a Page for the Sales Area Chart 284 Adding an Action to Display the salesAreaPage 285
Configuring the Click Action 285
Populating the salesAreaPage Page 285
Testing the Drill-Down from the salesChart Model 287
Custom Chart Styles 288
Displaying TargetSales 289
Using the Custom Style 290
Upgrading to a Deployment License 291
Summary 292
Important Points 292
Chapter 11 Field Validation, Formatting, and Translation 293
Validating, Translating, and Formatting Fields 293 Schema Typed and Non-Schema Typed Fields 294
Formatter Classes 295
Client-Side and Server-Side Validation 295
Creating a Projects Portlet 296
Creating a Model 296
Modifying the Page 297
Adding a Portlet Adapter 297
Organizing Builders for page1 297
Adding a Schema 298
Adding a Variable to Hold User Input 299
Modifying the Main Action List 299
Creating a Form 299
Adding a Submit Button 299
Adding a Confirmation Page 300
Modifying the Submit Button 300
Displaying the User’s Inputs 301
Adding a Link to Return to the Project Form 301
Running a Preliminary Test 302
Adding Formatting, Validation, and Translation 303
Testing the Projects Portlet 309
Writing a Formatter Class 312
Adding a Formatter Class 312
The CustomFormatter Class 315
Adding a Linked Java Object 316
Adding a Data Field Modifier 316
Further Validation Customizations 316
Adding a Resource Bundle 316
Changing Messages for Regular Expressions 318
Creating the Post-Save Action 318
Modifying the Post-Save Action Code 319
Running the Post-Save Action 321
Summary 321
Important Points 322
Chapter 12 Profiling Portlets 323
Profiling Builder Inputs 323
Creating an Announcements Portlet 325
Creating a Model 326
Modifying the Page 326
Adding a Portlet Adapter 327
Creating a Default Resource Bundle 327
Creating a US English Resource Bundle 327 Creating an ES Spanish Resource Bundle 328
Localizing the Announcement Headings 328
Profiling the Language Input 329
Profiling the Country Input 332
Setting a Selection Handler 332
Placing Headings on the Page 334
Adding English Announcements 335
Adding Spanish Announcements 335
Importing the Announcements 336
Displaying the Announcements 336
Running a Preliminary Test 337
Testing the Selection Handler 338
Profiling the hrHeader Based on Department 339 Profiling the itHeader Based on Department 340
Profiling the hrAnnouncements Based on Department 340 Profiling the itAnnouncements Based on Department 340 Configuring the userDepartment Profile Set 340 Testing the companyAnnouncements Portlet 341
Summary 342
Important Points 342
Chapter 13 Using Ajax and Dojo 345
Using Ajax 345
Creating a Service Provider 346
Creating a Model 347
Defining the Service 347
Adding Performance Data 347
Adding Functionality for Retrieving Performance Data 348 Specifying the getPerformanceData Operation 350 Adding Functionality for Updating Performance Data 351 Specifying the updatePerformanceData Operation 352
Testing the Service Provider 353
Testing the getPerformanceData Operation 353
Creating a Performance Portlet 354
Creating a Model 354
Modifying the Page 355
Adding a Portlet Adapter 355
Consuming the Service 356
Displaying the Interface 357
Hiding and Showing a Column Using Ajax 357 Responding to a Change in the Checkbox Value 358
Adding an Area Select Field 359
Adding Submit Functionality 359
Adding Ajax Type Ahead 360
Testing the Performance Portlet 360
Using Dojo 362
Enabling Dojo Capabilities 363
Adding an Action to Save Comments 363
Adding Inline Edit Capabilities 365
Adding Tooltips 366
Adding a Feedback Bar 367
Summary 369
Important Points 369
Chapter 14 Error Handling, Logging, and Debugging Portlets 371
Error Handling 371
Creating a Model 373
Modifying the Results Page 374
Adding Division Variables 374
Defining the Division Process 374
Displaying the Result 375
Running a Preliminary Test 375
Creating a Custom Exception 376
Throwing the Custom Exception 377
Adding an Error Page 377
Adding an Error Flag 378
Adding an Error Action 379
Adding an Error Handler 379
Testing the Division Model 380
Debugging 380
Debugging Statements 381
Using Eclipse Debugging 382
Logging 385
Debug Tracing 385
Using a Custom Logging Category 388
Server Stats 389
Summary 391
Important Points 391
Chapter 15 Performance and Process Optimization 393
Performance 393
Using Ajax and Dojo 398
Custom Builders 399
Creating a Model 400
Modifying the Page 400
Adding a Portlet Adapter 401
Creating a Terms & Conditions Builder 401 Defining Builder Inputs for the Custom Builder 403 Generating the Custom Builder Artifacts 404 Modifying the Custom Builder’s Functionality 405
Modifying the Coordinator 407
Using the Terms & Conditions Builder 407
Testing the Information Model 408
Creating a New Model Wizard 409
Testing the New Model Wizard Builder 410
Summary 411
Important Points 411
Chapter 16 More Techniques for Domino 413
Adding Common Notes Functionality 413
Notes Formulas, Validation, and Translation 414
Notes Agents 419
Domino Data Access Methods 434
getDominoSession() and getDominoDatabase() 435
setComputeWithFormEnabled(boolean) 435
getUserName() 435
sendDocument(IXml, boolean, boolean) and getDocumentData(String) 435
Summary 436
Important Points 436
Appendix A Setting Up Your Environment 439
Installing WebSphere Portlet Factory 439
Configuring WebSphere Portal 441
Setting Up a New Target Page 441
Setting Up Access 443
Configuring Lotus Domino 443
Start the DIIOP and HTTP Tasks 444
Enable HTTP Clients to Browse Databases 444
Creating a Test Database in DB2 446
Creating a Test Database in SQL Server 448
Configuring a JDBC Resource 451
Setting Up a DB2 Database Driver Provider 452 Setting Up a SQL Server Driver Provider 453
Configuring the Driver 453
Configuring a DB2 Data Source 454
Configuring a SQL Server Data Source 455
Configuring an Authentication Mechanism 456
Testing the Data Source 458
Appendix B Portlet Factory Properties 461
Properties Files 461
bowstreet.properties, cluster.properties, and server.properties 462 jdbcDrivers.properties, pageprocessors.properties, persistentstore.properties 462
log4j.properties 462
logging.properties 462
migrate-profilesets.properties 462
Using Properties 464
Domino Server Settings 465
File Upload Settings 466
Specifying an Alternate Compiler 466
Dynamic Class Loading 466
SOAP and Proxy Access for Web Services 467 Avoiding Errors Caused by File Length Limitations 468
The WPF Cache 468
log4j Logging 469
Debug Tracing 470
Event Logging 471
Server Statistics Logging 471
Page Automation 472
Glossary 475
Index 493
xxvii
Foreword
Building good software applications is hard. Improvements in languages, frameworks, and tools do make things easier, and there are more of these improvements each year.
But at the same time, the technology landscape that developers live in keeps changing and getting more complex. Just when you get productive with one set of tools and technology, there’s something new that you have to adapt to or integrate with. And there’s a perpetual demand for “more software quicker”—organizations can never get all the software they want as soon as they want it.
WebSphere®Portlet Factory was created to apply concepts of software automationto help address this ongoing problem of software development complexity. This software automation moves the developer up a level, above the level of individual code artifacts. Instead of directly manipulating elements such as JSP, Java™, JavaScript, and XML files, the developer interacts with builders in a model, and the builders then generate all the necessary code artifacts in response to the developer’s high-level instructions.
You can think of builders as encapsulations of software features ordesign patterns. Each builder implements one feature of an application, controlled by instructions provided by the developer in a wizard-like user interface. An application is built by successively adding and mod-ifying features (builders) until the application works as intended. The net effect for developers is that they can rapidly develop complex applications without having to learn (and remember) all the underlying technology.
also been adopted by a number of other product groups that build products on top of Portlet Fac-tory technology and take advantage of its software automation. For example, the Lotus® ActiveInsight Dashboard Framework is built on Portlet Factory and provides a set of builders that implement high-level design patterns tailored for dashboard-style applications.
We’ve also found that automation makes it possible to quickly add support for new technol-ogy, such as integrating new back-end services or generating new user interface technologies. One example is support for Ajax (Asynchronous Java and XML) user interfaces. Implementing an Ajax user interface through hand-coding is quite complex and involves coordinated client-side code (JavaScript) and server-side code. Using builder technology, a small team with Ajax exper-tise was able to capture their experexper-tise in a set of builders that automate common Ajax patterns and generate the necessary client and server code. Once the builders were created, those Ajax pat-terns became easily accessible to any developer using Portlet Factory.
In this book, David Bowley gives a clear “soup-to-nuts” guide to building applications with Portlet Factory, from creating your first project, to back-end integration, to user interface and Ajax techniques. Each chapter tackles one aspect of application development, and for each task David shows you which builders you need and how to use them. In his examples, I think you’ll see that David has found just the right level of complexity—the examples are simple enough to easily understand, but not unrealistically simple or trivial.
Portlet Factory development—using builders and models instead of working directly with code—represents a different development paradigm than with other tools. I hope you find as much value in this automation paradigm as we have. You can use this book as your guide as you learn your way around Portlet Factory and get comfortable with this way of working.
Jonathan Booth Senior Architect
WebSphere Portlet Factory IBM
xxix
Preface
Portlet development can often be arduous and complicated; indeed, the word “rapid” is not nor-mally associated with building portlets. IBM’s award-winning1 WebSphere Portlet Factory (WPF), however, provides developers with a wizard-based development environment that greatly expedites the process of building, testing, and deploying portlets. WPF shields developers from much of the complexity of traditional portlet development, and portlets built using WPF often require little or no coding—enlarging the potential pool of people who are able to build portlet applications. Having said this, WPF developers also have the full power of Java 2 Enterprise Edi-tion (J2EE) available to them should they choose to use it, making WPF a flexible (and powerful) development tool.
This book is about how to use WPF to rapidly build portlets. No previous development experience is required to understand this book, and anyone with a remote interest in portlet devel-opment should find something of interest here. The book is structured to facilitate rapid portlet development: It is a collection of independent chapters, each walking through the process of cre-ating a portlet while focusing on a particular aspect of WPF. Due to the independent nature of the chapters (and the nature of portlet development using WPF), you can skip to the chapters that interest you without needing to read chapter after chapter of abstract theory and/or background information beforehand. For example, if you want to learn how to build a portlet that displays a graphical chart, skip to Chapter 10, “Using Charts in Portlets;” if you want to find out how to work Ajax into your portlets, skip to Chapter 13, “Using Ajax and Dojo.” If you are completely new to WPF (or portals and portlets) and are looking for some basic information to get you started in WPF, Chapter 1, “Introduction to WebSphere Portlet Factory,” provides an overview of
1 WebSphere Portlet Factory won the 2006 JavaPro readers’ choice award for “Best Java Enterprise Portal Technology”
portal terminology, WPF architecture, and the WPF Designer interface. Chapter 1 also walks you through the process of creating, testing, and deploying a simple Hello World! portlet. Other intro-ductory information is available in Appendix A, which contains some useful information for set-ting up your WPF development environment, and there is a glossary at the back of the book that defines common WPF terms.
This book also contains useful tidbits that I have picked up during my time with WPF—the sort of things developers need to know but normally wouldn’t without a great deal of experimen-tation and frustration. These snippets of information are highlighted as follows:
T
IPTips contain useful information that can be employed in WPF, usually with the purpose of expediting portlet development. Tips are useful, but they are not critically important and can be skipped if desired.
W
ARNINGWarnings are important points that usually obviate a common sticking point, and heeding them may spare you future frustration.
Due to the width of the book’s printed page, some lines of code might be too long to fit on only one line. If a line of code wraps to another line(s), and it’s not obvious it’s part of the preced-ing line, we have inserted a code continuation character ([ccc]) at the beginnpreced-ing of the runover line to indicate that the code is part of the line preceding it. (You should type lines of code that have this character as one long line without breaking it.) For example,
WebAppAccess remoteWebAppAccess =
➥webAppAccess.getModelInstance(“modelPath/ModelName”, “”, ➥false);
All the examples discussed in this book are available for download from ibmpressbooks. com/title/9780137134465. More advanced readers can import what they want from these examples directly into their projects, without necessarily consulting the book itself—although you are encouraged to follow along with the examples to increase your understanding of WPF. By walking through each example, you will learn how to build portlets in WPF by actually build-ingthem, and not just reading about it; so, by the end of each chapter, you should have a practical understanding of how to work the discussed features into your own portlets.
Although this book does discuss the theory of WPF portlet development, this information is discussed in the context of the practical examples in the book, which gives you a more concrete
understanding of how the abstract side of portlet development is applied. Readers unconcerned with what is going on under the covers can skip the theory sections without adversely affecting their portlets. Indeed, one of the advantages of using WPF is that you don’t need to learn vast amounts of theory to begin development—you can start building portlets right away. The focus of this book, then, is on the practical side of portlet development, with an emphasis on rapidly build-ing portlets with certain functionality—this is not intended as a book of theory.Similarly, given its short length, this book is not intended to cover every aspect of portlet development—only those areas that are deemed most useful to portlet developers (and WPF developers, in particular).
I hope you find this book useful and enjoyable to read; I certainly enjoyed writing it. At the least, I would like this book to go some way toward expediting your portlet development process and increasing your understanding of WPF. If you have any comments about the content or struc-ture of the book, feel free to drop me a line at dave.bowley@gmail.com
xxxiii
Acknowledgments
I’d like to extend my sincerest appreciation to everyone who supported me during the process of writing this book. In particular, I’d like to thank John Bergland and Dee Zepf for their early sup-port of the concept, and Jonathan Booth and Louise Simonds for their insightful comments and advice. I’m eternally grateful to Katherine Bull, my acquisitions editor, for her continual support and direction throughout the project; and to Kevin Howard, my development editor, who care-fully surveyed each chapter and made many helpful suggestions. Thanks also to Carlos Llopart for the Spanish translations in Chapter 12, and to my sister Kirsten for providing several of the diagrams that appear in this book.
xxxv
About the Author
1
C
H A P T E R1
Introduction to
WebSphere Portlet
Factory
This chapter explains basic portal concepts (such as what portals and portlets are), and introduces the fundamentals of portlet development using WebSphere Portlet Factory (WPF). By the end of the chapter, you will have a working Hello World! portlet and you will understand the basic con-cepts and techniques required to build, deploy, and test portlets using WPF. This chapter is intended for WPF newcomers, but those who are interested in brushing up on the basics of WPF should also find something of interest in it. If you already feel confident using WPF, feel free to skip ahead to any of the later chapters—you can always come back to this chapter if you need to. The files used in this chapter are available for download from ibmpressbooks.com/title/ 9780137134465 under the Chapter 1 folder (instructions for copying these files into your project are included in a readme.txt file in the same folder); however, to increase your understanding of the topics discussed, it is recommended that you create these files yourself by following the example in this chapter. Doing so will give you a good understanding of the basics of WPF and position you to tackle some of the other chapters in this book.
The following topics are covered in this chapter: • What is a portal and what are portlets? • Portal key benefits
• What is WebSphere Portlet Factory? • WebSphere Portlet Factory key benefits • WebSphere Portlet Factory architecture
What Is a Portal and What Are Portlets?
Aportalis a user interface (UI) for people to interact with information and processes, often via Web pages accessed using a Web browser (such as the portal shown in Figure 1.1). Portals are provided by a portal server, such as WebSphere Portal Server, in a similar way to how Web pages are provided by an ordinary Web server. Portals usually aim to streamline business operations by bringing together information and processes from disparate parts of an organization. For example, an online bookstore may provide a portal for customers to preview new releases, pur-chase new books, check the status of any current orders, and even chat with other customers to share their thoughts on a particular book. Portal functionality is normally provided through one or more portlets, which are UI components of the portal that serve a particular function (similar to how a window offers a particular function—or suite of functions—within a Microsoft® Win-dows® application). In the case of an online bookstore, then, a portal might include a New Releases portlet and a Forum portlet.
2 Chapter 1 Introduction to WebSphere Portlet Factory
Figure 1.1 An example portal at www.ibm.com/developerworks/.
browsing a catalogue and for buying new books, and a Community page might contain portlets that facilitate communication with other customers. Portals don’t necessarily have to be customer facing; for example, an intranet portal might be available only to employees, and an extranet por-tal might be available only to suppliers. A porpor-tal can be anything from a simple front-end to a backend data source, to a complex collaborative tool integrating several different departments across an enterprise.
Due to the current bandwidth limitations of the Web, portals are usually kept relatively simple in comparison with more traditional rich clients (like Microsoft Word, for example). Sim-ilarly, portlets are not normally as packed with features as their rich client cousins, and they offer a more focused service. As a result, portlets normally satisfy some key business requirement or process (either individually or in conjunction with other portlets). Having said this, portals avail-able through a Web browser can be accessed on a wide variety of platforms, using a number of different devices, and from anywhere in the world; so, potential exposure to a portal available through a Web browser is vastly superior to that gained through a rich client. Careful considera-tion, then, needs to be applied to the portal design process, and a portal should aim to supplement rich client applications rather than replace them.
Portal Key Benefits
Depending on its exact nature, a portal usually offers one or more of the following key benefits: • Integration of Business Functions—Probably the most common use for a portal is as
an integrator of business functions, usually across departmental or technological bound-aries within an enterprise. For example, a portal might provide portlets for accessing accounting applications in SAP, reports on a SQL server, and email capabilities from Lotus Domino®, and it can enable you to use these portlets (and even send information between them) as if they were all part of the same system. This sort of integration pro-motes standardization of business processes and discourages the practice of viewing an organization as a collection of isolated business units.
• Aggregation of Information—Another popular use for a portal is as an aggregator of information—that is, as a means to bring together information from disparate locations or data sources into a single interface (again, giving the impression that all of the infor-mation is stored in the same place). A portal can save users from needing to use several different programs to hunt through multiple systems in search of information.
• Collaboration between Users—Portals often provide functionality that facilitates communication and information sharing across an enterprise (such as document shar-ing, email, blogs, and project team rooms).
• Accessibility of Information and Services—One of the greatest features of the Web is how it quickly and easily facilitates communication between people from vastly differ-ent locations and backgrounds. As a result, portals often provide an experience tailored
to the context in which they are accessed. For example, a portal may be offered in sev-eral different languages, and different markups (such as HTML and WML) may be used to allow access to the portal using different devices (such as mobile phones, laptops, PCs, and PDAs).
Portal servers also provide mechanisms to restrictaccessibility through customizable authentication and authorization mechanisms that can leverage an organization’s exist-ing security methods (such as Lightweight Directory Access Protocol [LDAP] and Lotus Notes®Access Control Lists [ACL]). Putting this into practice, an employee from a sales department might be able to see only the sales portion of a portal, and an unau-thorized person might not be able to log on at all.
• User Interface Personalization—Portals often provide a certain degree of personaliza-tion, such as allowing customers to specify the information they see and how it should be displayed. For example, a portal can provide facilities for end users to choose the position of portlets on the page or to add and remove portlets as required.
What Is WPF?
WPF is a tool for Eclipse-based Integrated Development Environments (IDE) that facilitates rapid application development. This is achieved primarily through the use of wizard-based, reusable components called builders, which can be parameterized based on different contexts and automatically built into executable code.
Developers can create WPF applications by creating a WPF project in an Eclipse-based IDE (such as Rational®Software Architect [RSA], Rational Application Developer [RAD], or Eclipse itself), which has WPF installed into it. After it is installed, WPF adds new design arti-facts to the IDE that enable the development of WPF applications. WPF projects can then be automatically assembled into Web ARrchive (WAR) files (a WAR file is an archive of Java design artifacts for a Web application) from the IDE and deployed to local or remote application servers or portal servers.
Note that although you can use any version of WPF to complete the examples in this book, it is assumed that you are using WPF 6.0.2.
WPF Key Benefits
Some of the key benefits of WPF are:
• Reduced Need for Hand Coding—Developers can build standards-based applications (such as portlets, Web services, or Java 2 Enterprise Edition [J2EE] applications) with little or no coding. Given the reduced need to write code, the skill set required to build complex applications (in J2EE, for example) is drastically reduced.
process. WPF applications are also more flexible than traditional Java applications in that they are easier to maintain and extend.
• Best Practices—WPF encourages component- and service-based design, and can be used to enforce architectural patterns and best practices.
• Powerful Capabilities—WPF has a suite of around 160 wizard-like builders that can be used to automate many common development tasks. These builders have strong integra-tion capabilities with a broad range of backend data sources.
WPF Architecture
At design time, WPF applications consist of three main building blocks: builders, models, and profiles. Developers work with these elements (along with other design elements like HTML pages, XML documents, and Java classes) in a special type of project called a WebSphere Portlet Factory project (see the “Introduction to the Eclipse IDE” sidebar later in this chapter if you are unfamiliar with projects in Eclipse). Using all of these elements, a WPF mechanism known as the Factory generation enginecan automatically generate executable applications called WebApps. WPF can also automatically package these WebApps into different types of deployable WAR files, which you can configure via deployment configurations.
Each of these elements is discussed in the following sections.
Builders
Buildersare the basis of any WPF application; they are essentially wizard-based interfaces that automate common development tasks (see, for example, the SQL Call builder in Figure 1.2). A builder can do anything from add a button to a HTML page, to send data to a backend data source, to publish parts of an application as a Web service. Builders contain sets of parameters (often called builder inputs or fields) that developers use to customize what they want a builder to do. You can modify builder inputs at any time and regenerate your application as many times as you like. As of release 6.0.2, WPF contains about 160 builders, and developers are free to create their own custom builders as well. Using builders encourages component-based design, and a custom builder library can enforce architectural and coding standards across a development team.
For example, after a Domino Data Access builder call has been added to your project, you just have to enter some parameters (such as a Domino database to connect to) and save your changes, after which WPF automatically generates all the appropriate code to access and manip-ulate the appropriate backend Domino database. You then use another builder call (or several, depending on the degree of customization required) to display and format data from the database.
Developers usually interact with builders through a graphical interface (shown in Figure 1.2), but a combination of Java classes and XML files are used to create builders on the backend. Developers can manipulate these files to extend the pre-packaged builders or to create their own builders. For an example of how to create your own builder, see Chapter 15, “Performance and Process Optimization.”
6 Chapter 1 Introduction to WebSphere Portlet Factory
Figure 1.2 The SQL Call builder.
Models
Developers assemble collections of builder calls inside models, which list what builders WPF should use to generate your application and to store the specific values used for each builder input. Through builder calls, models can link to other models as well; you might, for example, use one model for UI-related builder calls, which, in turn makes calls to another model for data retrieval. Models are stored as XML files so they can be easily distributed, but are manipulated in a GUI using the WPF Designer. Structuring your projects with models enables you to build flex-ible, highly modular applications.
T
IPIf a model contains an Action List builder called ‘main’, you can run the model directly from your IDE, which executes the sequence of actions defined in the main builder from the code generated by WPF. If a model contains a Portlet Adapter builder, when your application is generated, a portlet is created based on the builder calls in the model.
contains a single model consisting of several builders. One of these builders is a Portlet Adapter builder, which means that when you deploy the project to a portal server, a Hello World! portlet will become available.
Profiles
WPF uses profiles to facilitate context sensitive functionality in your applications and can actu-ally generate different applications for different contexts, roles, or settings. A profile is essentiactu-ally a set of values for one or more builder inputs, and WPF decides which of an application’s profiles to use based on certain conditions. These conditions can be anything from a user’s J2EE role, to an LDAP group, to a custom condition specified by the developer.
For example, you might set up two profiles for an application: one for administrators and one for ordinary users. The context in this case is the type of user (which might be specified in an LDAP group). Each profile might contain different values for certain builder inputs in your appli-cation (which might lead to different pages displaying or different execution paths being fol-lowed). Depending on how you configure your profiles, two separate applications might be generated (one for each type of user); or perhaps only one application, which responds differently depending on the user who is accessing it.
Profiles are stored in files called profile sets, which have a .pset extension and can be found under the WebContent/WEB-INF/profiles directory in your project. For an example of how to use profiles in your application, skip to Chapter 12, “Profiling Portlets.”
Generating and Executing the WebApp
Whenever you open, save, or apply changes to a model or builder call, a WPF mechanism known as the Factory generation enginecreates one or more executable versions of your model called WebApps. WebApps consist of things like Java code, HTML pages, and XML files, and are built according to the inputs in your builder calls. For example, a Page builder called page1causes an HTML page called page1to be created in a WebApp by the Factory generation engine. When generating your WebApps, the actions taken by the Factory generation engine are determined by backend Java classes for each builder used (called builder regeneration classes).
You can view the artifacts generated as part of the WebApp by selecting the WebApp Tree tab, in the editor area of your IDE when you have a model currently selected (for more informa-tion on the WPF Designer interface, see “The User Interface” secinforma-tion later in this chapter). The WebApp is also accessible via API calls made from Java or from inside other builders.
The design time generation process is shown diagrammatically in Figure 1.3. In step 1, you create your models, populate them with builder calls, and then assign values to the builder inputs that these calls contain. In step 2, you generate a particular model (usually by saving one of its builder calls), which causes the Factory generation engine to build a WebApp based on your builder input values, using the corresponding builder regeneration classes.
8 Chapter 1 Introduction to WebSphere Portlet Factory
Figure 1.3 The WebApp generation process at design time.
In step 3, you have the finished product: a WebApp, which contains all of the artifacts needed by your application at runtime. If you have only one set of builder input values for a par-ticular model, you will have only one WebApp for that model. The Factory generation engine will create the WebApp using the appropriate builder regeneration classes, passing in values from the builder input values in the builder calls contained in that model.
WPF Architecture 9
Figure 1.4 The WebApp generation process with profiling.
When WPF applications are executed on a server, they pass through several stages, and generation can occur during this process. The execution process is shown diagrammatically in Figure 1.5. In step 1, a user requests access to a WPF application, and the request is received by the Factory controller servlet (WebEngineServlet) at step 2. The Factory controller servlet then routes the request to a WPF process called WebAppRunner in step 3. At step 4, the WebAppRun-ner process determines which profile (if any) to associate with the user request.
Figure 1.5 The WebApp execution process.
Although the process of generating (and executing) your WebApps occurs mostly behind the scenes in WPF, understanding it will enable you to make better sense of the WPF develop-ment process and ultimately enable you to directly manipulate the WebApp in your applications (via the WebApp API). Use of the WebApp API is discussed in Chapter 8, “Using Java in Portlets.”
10 Chapter 1 Introduction to WebSphere Portlet Factory
Factorycontrollerservlet
Generationengine
WebAppgenerated
WebAppavailable WebAppRunner
IsProfile needed?
IsWebApp incache?
WebAppretrieved Userrequest
1
2
3
4
5
6
7
8
9
10
Yes No
Yes No
Portlet Factory WAR Files
WPF applications can be automatically assembled into WAR files, which can then be deployed to an application server or portal server. Target servers for WAR deployment can be either local or remote to your development machine. There are three different types of WAR files you can create in WPF (one application can use all three WAR files simultaneously), and each one has slightly different characteristics. The three different WAR files are discussed in each of the following sections.
Development WAR
The development WAR contains functionality to assist development, which is not contained in the other types of WAR files (such as the capability to run models directly from a URL). When-ever you run models directly from your IDE, you use the version of the WebApp contained in the development WAR.
The development WAR must be deployed to an application server. You can create develop-ment WARs by right-clicking your project and selecting Application Server WAR, Build WAR for dev testing; however, you need an application server deployment configuration before this option becomes available (deployment configurations are discussed in the “Deployment Configu-rations” section).
Portlet WAR
The portlet WAR contains functionality that enables you to run models as portlets within a portal, as well as take advantage of functionality offered by the portal (such as inter-communication between portlets). This is not contained in the other WAR file types. Portlet WARs do not contain any development-specific design elements, so they are suitable for any sort of environment (test, production, and so on).
The portlet WAR must be deployed to a portal server. You can create portlet WARs by right-clicking your project and selecting Portal Server WAR, Build Portlet WAR; however, you need a portal server deployment configurationbefore this option becomes available.
T
IP
Even though you need a portlet WAR to view your models as portlets, you can still preview these models as standalone Web applications using the development WAR. This is useful for quickly testing features of your portlets that don’t require functionality that is available only in the portal (such as inter-portlet communication). After testing, you can then create a portlet WAR to test any portal-specific functionality.
Deployment WAR
The deployment WAR doesn’t contain any of the development artifacts included in the develop-ment WAR, and can’t take advantage of portal server specific functionality. You would normally use a deployment WAR when you want to deploy your application to a production environment, but don’t want to use any of the capabilities of a portal (for example, your application doesn’t contain any portlets). You might create a Web service and deploy a deployment WAR to an appli-cation server in your production environment, so that the Web service is constantly available to external consumers. You can also use deployment WARs in test environments when you don’t want to include any unnecessary design artifacts in the application.
The deployment WAR must be deployed to an application server. You can create deploy-ment WARs by right-clicking your project and selecting Application Server WAR, Build WAR for a production deployment; however, you need an application server deployment configuration before this option becomes available.
Deployment Configurations
To run your applications, you need to deploy them to an application server or portal server. In WPF, you use deployment configurations to manage settings for these deployments. You can use two deployment configurations:
• Application server deployment configuration • Deployment server deployment configuration
The application server deployment configuration is used mainly to specify settings for test-ing your application directly from the IDE. The development WAR and deployment WAR, if you are using them, are both deployed to the server specified in the application server deployment configuration. The portal server deployment configuration specifies settings for deploying the portlet WAR to a portal server.
Running WPF portlets on a portal server lets you take advantage of the functionality offered by the portal (such as inter-portlet communication and user-configurable, shared-settings menus), and running your WPF portlets on an ordinary application server lets you view them as standalone applications. There are advantages to both approaches (an application server is often quicker for testing, but doesn’t have all the functionality of a portal server), and common practice is to use an application server for testing quick changes that don’t require functionality from the portal, and then use a portal server for testing portlets as they would appear in a production envi-ronment. WPF 6.0.2 comes with a lightweight application server called WAS CE, which is per-fect for local testing.
It is possible to link to local servers (those installed on the same machine as WPF) and remote servers (those installed on a different machine to WPF) from your deployment configura-tions, and each scenario has different advantages. Local servers are the easiest to set up as they don’t require you to manually install WAR files; however, deploying to a remote server can free
up valuable resources on your development machine. If you want to have the capability to auto-matically refresh WAR files from your IDE (highly useful in test environments), you need to link to servers that are installed either on your local machine or are accessible through the file system via a mapped drive. If you’re deploying to a remote machine that you can’t access through the file system, you have to manually update the installed application from the WAR file created by WPF.
T
IPWhen mapping to a remote server, you don’t need access to the entire file system. If secu-rity is a concern on the remote server, you should map only the application server or portal server directories on the remote machine.Note that WAS 6 and WPS 6 both have multiple parent directories by default (usually c:\Program Files\IBM\WebSphere and c:\IBM).
Introduction to the WebSphere Portlet Factory Designer
The WebSphere Portlet Factory Designer (or WPF Designer) is an Eclipse-based IDE with the WPF software installed (as a result, the terms IDE and WPF Designer are often used interchange-ably throughout this book). WPF Designer enables developers to create WPF applications and to utilize WPF-specific design elements such as builders, models, and profiles in their projects.
The User Interface
After WPF Designer is installed (see Appendix A, “Setting Up Your Environment,” if you want more information on how to do this), developers should switch to the WebSphere Portlet Factory perspective if it is not already visible (if you are unfamiliar with the term perspective, please see the “Introduction to the Eclipse IDE” sidebar). You can switch to the WebSphere Portlet Factory perspective by selecting Window, Open Perspective, Other, selecting WebSphere Portlet Factory from the list, and then pressing OK. After the WebSphere Portlet Factory perspective loads, your IDE should display similar to the screenshot shown in Figure 1.6 (note that there may be slight differences depending on the version of WPF you use).
T
IPYou don’t necessarily have to use the WebSphere Portlet Factory perspective if you don’t want to, but it does provide you with an easy-to-use interface with several commonly used views.You can switch between perspectives at any time by selecting Window, Open Per-spective, Other, and then selecting the appropriate perspective from the list; you can even create your own perspective by adding and removing views and editors (which you can do from the Window menu in the IDE).You can then save your perspective by selecting Win-dow, Save Perspective As, giving your perspective a name, and pressing OK.
Figure 1.6 The WebSphere Portlet Factory perspective.
As with any other Web applications, your development artifacts display in the Project Explorer view on the left side of the screen (or in the Navigator if you’re using a version of WPF prior to 6.0.1), which is in section 1 of Figure 1.6. If you are using WPF 6.0.2 or later, underneath the models in this section, you will also see a list of artifacts referenced by the model (such as HTML files and images). The builder calls in the currently active model are displayed below this view in the Outline view, contained in section 2. You can edit a builder call by double-clicking it, and you can add new builder calls to the model by clicking the icon in the top right of the Out-line view.
The top-right quadrant of the IDE (contained in section 3 of Figure 1.6) displays editors for a number of different aspects of your application, depending on what you currently have open in the IDE. If you have a model currently selected (you can select a model by double-clicking on it in the Project Explorer view), then this section of the screen displays the Model Editor, which contains a series of tabs for the model. These tabs are WebApp Tree, Model XML, Builder Call Editor, and WebApp Diagram.
14 Chapter 1 Introduction to WebSphere Portlet Factory
Project Explorer view Model Editor
The WebApp Tree tab (shown open in Figure 1.6) gives you a hierarchical display of the items used in your WebApps and a read-only view of the code generated by the generation engine. The Model XML tab (shown in Figure 1.7) gives you a read-only view of the backend XML representation of your model.
Introduction to the WebSphere Portlet Factory Designer 15
Figure 1.7 The Model XML tab.
The WebApp Diagram tab (shown in Figure 1.8) gives you a diagrammatic representation of the execution flow in your WebApps. Switching between these tabs gives you a different view of the currently active model.
The Model Editor tab (shown in Figure 1.9) enables you to edit the currently active builder call in your model. To open a builder call in the Model Editor, simply double-click on the appro-priate builder call in Outline view.
T
IP16 Chapter 1 Introduction to WebSphere Portlet Factory
Figure 1.8 The WebApp Diagram tab.
