ptg 262 Chapter 11 Framework Components Figure 11.7 Manage Repository dialog Figure 11.6 Add Dependency dialog Download from www.wowebook.com ptg Assemble Flow 263 Figure 11.8 ACF dependency added As you can see, we no longer get the alert dialog. It is as if the parameter were never passed and, as far as our application is concerned, it wasn’t. Adding this one little dependency to our application secured it from a multitude of black hat mischief. By default, ACF also filters inbound and outbound JSON data streams. So, including this will not only prevent malicious content in URL parameters but also data sent to your resources. There is also support to protect against Cross-Site Request Forgery (CSRF) and an ACF API for those who’d like to have finer grain con- trol and insight into the active content that is passed to or from your application. Please see the WebSphere sMash documentation for more details (http://www.projectzero.org/sMash/1.1.x/ docs/zero.devguide.doc/zero.acf/Overview.html). Assemble Flow Assemble Flow provides the capability for constructing feeds or conversational applications with a minimum amount of programming. A flow is a program created by nontechnical people that acts on data. A flow can aggregate and manipulate data in various ways. Flows can be created with either a graphical tool or manually in XML. Flows are created by linking together activities. WebSphere sMash comes with several powerful built-in activities. Custom activities can also be created to extend the Assemble Flow system. Let’s start with building a simple flow. To start, you’ll need to add the Assemble Flow dependency to your project. The module name is zero.assemble.flow. Remember that if it’s not in your local repository, you’ll need to add it via the Manage Repositories button. After the Assemble Flow module is added to your project, you’ll be able to create and run flows. To create a flow in the Application Builder, select New File > “Flow in /public”. Flows are always placed in the public directory or one of its subdirectories. When created, your new file will be opened in the Flow Editor. Notice that there’s a palette of activities on the right side of the Application Builder (see Figure 11.9). The activities palette, by default, shows a list of all the built-in activities. Custom activities can be added to this palette as they are created. You’ll also notice that there’s a toolbar at the top of the page, as shown in Figure 11.9. Start by clicking the Properties item in the toolbar and setting a name for this flow. In this example, I’ve set the name to Hello, as shown in Figure 11.10. We’re going to start by building a simple flow that mimics what we did in the previous section. That is an application that takes in a parameter and responds with a simple Hello parameter. Download from www.wowebook.com ptg 264 Chapter 11 Framework Components Figure 11.10 Set the flow name property Figure 11.9 Activities palette and Flow Editor toolbar Now we can start adding activities to our flow. The first activity we should add is the receiveGet activity, which is found under the Built-in Activities section in the activities palette. We simply click and drag the activity from the palette to the editor canvas, as shown in Figure 11.11. Download from www.wowebook.com ptg Assemble Flow 265 Figure 11.11 Drag the receiveGET activity from the palette to the editor canvas Figure 11.12 Setting the activity name property The receiveGET activity is how we listen for an HTTP GET request from a client so that we may begin processing that request. Click on the small wrench icon to bring up the properties of the receiveGET activity and set the name of this activity. For our purposes, we’ll name it receiveName, as shown in Figure 11.12. Now that we’re listening for an HTTP GET request, we need to respond to the request. To do this, we need to drag the replyGET from the palette to the canvas. This enables us to respond to the HTTP GET request in any way we’d like. Again, we should click the wrench icon and set the name of the replyGET to something meaningful, like replyName. Now, click your receive- Name activity, and you’ll notice a little blue ball on the right side of the activity, as shown in Figure 11.11. If you hover over the little blue ball, it turns orange, and when it does, you can click and drag from your receiveName activity to the replyName activity. This links the two activities into a flow—that is, data from the receiveName activity flows to the replyName activity, as shown in Figure 11.13. Now that the data is flowing, we can finish the replyName activity by filling in the input property. Again, click the replyName activity and then the wrench icon. You may have noticed that there was more than just a name property when you set the name. The input property tells the activity what to do with the incoming data. In this case, the incoming data is from receiveName, and we simply want to take a parameter from that request and pass it back to the client. We’ll be Download from www.wowebook.com ptg 266 Chapter 11 Framework Components Figure 11.15 Results of the name flow Figure 11.14 Setting input properties in replyName passing it back as plain text, as shown in Figure 11.14, although we could choose to use HTML or any of the other content types depending on our situation. Now we can start up our application and give it a try by passing it the name parameter: http://localhost:8080/index.flow?name=Bob You may have n oti ce d th at flow file s en d wi th th e dot fl ow e xt en sio n. So, w e mu st ma ke su re to put that in our URL. The results are exactly what you’d expect and are shown in Figure 11.15. This has been a very simple example of how to use Assemble Flow. Assemble Flow con- tains many built-in activities. There are activities for every type of HTTP request (GET, PUT, POST, and DELETE). The HTTP request activities allow flows to consume requests and respond to the client. There are built-in activities for looping, flow control, sending email, and calling out Figure 11.13 Linking receiveName to replyName Download from www.wowebook.com ptg Conclusion 267 to Java classes and scripts. Beyond the built-in activities, there are activities for retrieving feeds, such as RSS and ATOM feeds, and aggregating, truncating, sorting, and filtering those feeds. There’s also an activity to apply XSLT to XML from a feed and activities for creating, retrieving, updating, and deleting feed entries. When put together, these activities make it possible to build robust and interesting services with a minimum of programming skill. The IBM WebSphere sMash team has provided many interesting examples on their website, as well as on YouTube. If you can’t find an activity that fits your needs, you are also able to create new activities. This is one of the more attractive use cases for Assemble Flow. A team of software engineers cre- ates a set of activities specific to the business. Perhaps there are activities around retrieving orders, creating orders, setting orders fulfilled, client management, and so on. After these activi- ties are created and tested, a less-technical person or even the development team could then use flow to string together new applications around these new activities. Perhaps one application is a web-based reporting application that is used by sales and marketing to see what items are most popular in their region. Another application could be built as a point of sale application to be used in retail stores. Yet another application could be used by the store management to see what they might need to order. After the building block activities are created, there are a number of applica- tions that could arise from them. Using this approach, it’s quite easy to quickly put together these applications from the cre- ated activities. This also gives rise for ad-hoc applications to easily be built. Consider when the VP of a particular country wanted to see the aggregate of items sold in his country. If you’ve already built a feed to show the quantity of item orders regionally, it would be fairly easy to aggregate those feeds into a national feed. Instead of days, it would take only hours to do that aggregation. Assemble Flow is an interesting and powerful part of WebSphere sMash that could vastly improve productivity in today’s fast-paced, agile world. Conclusion We’ve taken a brief look at several components of WebSphere sMash: • URIUtils are a set of cross-language utility methods for creating relative and absolute URIs for your application. You should be using these utilities for the creation of all the URIs within your application. This enables you to create robust applications that with- stand the rigors of the web. • Val id at or s, wh ic h a ss is t i n va lid at in g c ac he d co nt ent an d c an he lp im pr ove app li cat io n performance. • Active Content Filtering, which helps to secure your site against cross-site scripting in a manner that is easy for developers to use. • Assemble Flow, which allows nonprogrammers to create conversation applications in WebSphere sMash. It is our hope that if any of these components are interesting or helpful, you will dig into Web- Sphere sMash and use them to your advantage. Download from www.wowebook.com ptg This page intentionally left blank Download from www.wowebook.com ptg 269 WebSphere sMash enables you to rapidly create RESTful applications. This is all well and good, but in today’s environment, you need to create a really sexy Web 2.0 style client that is capable of consuming your application’s content. You can think of your client-side development as the face of your enterprise SOA. By enabling good client-based application logic, you can free up valu- able server resources. The more work you can offload to the browser, the more requests the server can handle. In the RIA/Web 2.0 world, the server is permitted to focus on handling data requests via RESTful resources and not having to continually serve intermittent pages as part of the old school request/response cycle. Now the server can send the initial payload, including the page markup and client-side application logic, and then it’s left to service data requests. After the user has entered all the required data for an application, a single submission is sent to the server for processing. There is no server-side state management (that is, session state), as all of this is han- dled on the client. In the Web 2.0 space, data is the new HTML. In its purest sense, a Rich Internet Application (RIA) consists of a single HTML page that dynamically changes its content based on user input. Examples of this are the advanced mail applications from Google, Yahoo!, and others. Traditional web applications maintain a single HTML page per request/response cycle. In most real-world enterprise Web 2.0 applications, you typically will have a hybrid solution that combines that interactivity of the Web 2.0 application with an occasional page reload during major context switches. You have to find the proper bal- ance point based on your environment and the skills of your developers. WebSphere sMash has a tight integration with the Dojo Toolkit (http://www.dojotoolkit. org). Dojo is a JavaScript environment that provides a wealth of programming logic that assists in the browser’s DOM manipulation, as well as powerful AJAX communications and many cus- tom widgets. Although we can’t cover the full scale of the Dojo Toolkit—there are plenty of C H A P T E R 12 Client-Side Programming with the Dojo Toolkit Download from www.wowebook.com ptg 270 Chapter 12 Client-Side Programming with the Dojo Toolkit good books that do that—we explore how to effectively use Dojo in your WebSphere sMash applications. Enter the Dojo Dojo is a leading enterprise-class, open-source JavaScript toolkit. It provides a broad set of features and functionality beyond general-purpose JavaScript, which enables you to create highly engaging and interactive Web 2.0 applications. IBM and several other companies endorse the Dojo foundation with financial and personnel support to advance its quality and feature set. Dojo is the best-in-class product for enterprise-ready features, which include Accessibility (A11Y), Internationalization (I18N), encapsulation of browser idiosyncrasies, and forward-looking API structure. Dojo is delivered as three main packages. These are called dojo, dijit, and dojox. As an appli- cation developer, you can then add your own custom module groups, using whatever package name- spacing fits your purpose. Typically, you want to follow a minimalist package-naming convention similar to Java packages. You can locate your custom Dojo classes anywhere under the /public directory and then register the custom package with Dojo, so it knows where to find them. Let’s review the standard module groups provided by Dojo to gain a better understanding of what’s avail- able within each and to grasp the scale of what Dojo can provide the application developer. The main dojo package consists of base libraries that provide smart modules loading, DOM query and manipulation functions, event handling, Asynchronous JavaScript and XML (AJAX) and RPC I/O, browser detection, CSS style manipulations, simple animation, and many other use- ful tools. That’s a lot of functionality immediately available with a single call to load the core /dojo/dojo.js file. Dojo enables you to start small and grow your applications as your skill set grows. All of the Dojo widgets (dijits) are available, somewhat obviously, under the dijits package. There are a huge number of widgets that provide data input, display, and management capabilities. All the dijits ensure a consistent visual user experience no matter what browser you are using. There are a complete set of form-based input widgets, including text, numbers, dates, filtering selects (such as Google Suggest), menus, buttons, and enhanced widgets that provide for client-side validation of user entry prior to submitting the data to the server. This greatly enhances the user experience, by catching input errors early and allowing the user to correct the mistakes before being sent to the server. This does not alleviate server-side validation but does prevent all the basic missing, or improperly entered, required fields style of error handling that has historically been relegated to the server, post submis- sion. Another feature of dijits is the ability to instantiate the widgets either through programmatic logic (for example, new dijit.Dialog()), or through declarative tagging in the HTML itself (for example, <div dojoType=”dijit.form.Tooltip”>). This allows strong JavaScript developers to do their thing, as well as classic HTML developers to easily build up custom Dojo-enabled pages. In practice, you will likely use a combination of declarative and programmatic dijit creation. The third main Dojo package is called dojox, which stands for Dojo eXperimental. This is somewhat of a misnomer but serves its purpose. The classes available under dojox are deemed not ready for prime time but include some powerful functionality. Some classes are robust and can safely be used in production code, whereas others are still a work-in-progress and may go Download from www.wowebook.com ptg Enabling Dojo in Your Application 271 Figure 12.1 Adding Dojo dependency through changes before they can eventually graduate to the stable dojo or dijit package groups. Read the documentation included with the classes, because they usually state the expected stabil- ity and known issues. By all means, do not dismiss the dojox package group, because this is where you can find some exciting and sexy classes to enhance your applications. The final package group within the Dojo structure, which was not mentioned previously, is called util. As the name suggests, in this package, you will find the tools needed to perform cus- tom Dojo builds and create API documentation and other useful, um, utilities. We discuss the value of performing custom Dojo builds later in the chapter, because they can provide a dramatic improvement in page load times. This is, without a doubt, the number-one best practice in any Dojo application. Enabling Dojo in Your Application To use the facilities provided by the Dojo Toolkit, you need to add the proper Dojo dependency. WebSphere sMash includes an up-to-date Dojo distribution within the normal repository locations. This dependency includes the basic Dojo Toolkit, minus a few modules that have questionable licenses, as well as some extra widgets and integration features specific to WebSphere sMash. We explore shortly how to install your own version of Dojo from dojotoolkit.org, as part of the custom build procedure, but for now, we use the bundled version of Dojo available with WebSphere sMash. Let’s start out by creating a new project in the AppBuilder. Call this application Book.Client.Vacation, and accept the remaining defaults. Because Dojo is specifically a client-side solution, we do most of our work within normal HTML files. Click into the applica- tion and create a new HTML file under the /public folder. Name this file index.html. Be sure to leave the template as default.html so that we get a nice boilerplate page. AppBuilder offers to automatically add the Dojo dependency, as shown in Figure 12.1. Accept this recommendation to have the latest Dojo module added to the application’s ivy.xml file. If you have an existing application that you want to Dojo-enable, simply go into the Dependencies tab of the project, search for and add the latest zero:zero.dojo.* module, and you’re ready to go! Download from www.wowebook.com . interesting and powerful part of WebSphere sMash that could vastly improve productivity in today’s fast-paced, agile world. Conclusion We’ve taken a brief look at several components of WebSphere sMash: •. number-one best practice in any Dojo application. Enabling Dojo in Your Application To use the facilities provided by the Dojo Toolkit, you need to add the proper Dojo dependency. WebSphere sMash. main packages. These are called dojo, dijit, and dojox. As an appli- cation developer, you can then add your own custom module groups, using whatever package name- spacing fits your purpose. Typically,