How-To Tutorials

If you’re searching for details of a particular term in Google, you’re most probably going to see a link for relevant articles from wikipedia.org in the top 10 result list. Wikipedia, is the largest encyclopedia on the Internet, and contains huge collections of articles in many languages. The most significant feature of this encyclopedia is that it is a Wiki, so anybody can contribute to the knowledge base. A Wiki, (a new concept of web2.0), is a collection of web pages whose content can be created and changed by the visitor of the page with simplified mark-up language. Wikis are usually used as knowledge management systems on the web. Brief Introduction to Wikipedia Wikipedia has defined itself as : … a free, multilingual, open content encyclopedia project operated by the United States-based non-profit Wikimedia Foundation. Wikipedia is built upon an open source wiki package called MediaWiki. MediaWiki uses PHP as a server side scripting language and MySql as the database. Wikipedia uses MediaWiki’s wikitext format for editing the text, so the user (without any necessary  knowledge of HTML and CSS) can edit them easily. The Wikitext language (also called Wiki Markup) is a markup language which gives instruction on how outputted text will be displayed. It provides a simplified approach to writing pages in a wiki website. Different types of wiki software employ different styles of Wikitext language. For example, the Wikitext markup language has ways to hyperlink pages within the website but a number of different syntaxes are available for creating such links. Wikipedia was launched by Jimmy Wales and Larry Sanger in 2001 as a means of collecting and summarizing human knowledge in every major language. As of April 2008, Wikipedia had over 10 million articles in 253 languages. With so many articles, it is the largest encyclopedia ever assembled. Wikipedia articles are written collaboratively by volunteers, and any visitor can modify the content of article. Any modification must be accepted by the editors of Wikipedia otherwise the article will be reverted to the previous content. Along with popularity, Wikipedia is also criticized for systematic bias and inconsistency since the modifications must be cleared by the editors. Critics also argue that it’s open nature and the lack of proper sources for many articles makes it unreliable. Searching in Wikipedia To search for a particular article in Wikipedia, you can use the search box in the home page of wikipedia.org.Wikipedia classifies its articles in different sub-domains according to language; “en.wikipedia.org” contains articles in English language whereas “es.wikipedia.org” contains Spanish articles. Whenever you select “english” language in the dropdown box, the related articles will be searched over “en.wikipedia.org” and so on for the another language. You can also search the articles of Wikipedia from a remote server. For this, you have to send the language and search parameters to http://www.wikipedia.org/search-redirect.php via the GET method Creating a Wiki Seek Widget Up till now, we’ve looked at the background concept of Wikipedia. Now, let’s start building the widget. This widget contains a form with three components. A textbox where the visitors enters the search keyword, a dropdown list which contains the language of the article and finally a submit button to search the articles of Wikipedia. By the time we’re done, you should have a widget that looks like this: Concept for creating form Before looking at the JavaScript code, first let’s understand the architecture of the form with the parameters to be sent for searching Wikipedia. The request should be sent to http://www.wikipedia.org/search-redirect.php via the GET method. <form action="http://www.wikipedia.org/search-redirect.php" ></form> If you don’t specify the method attribute in the form, the form uses GET, which is the default method. After creating the form element, we need to add the textbox inside the above form with the name search because we’ve to send the search keyword in the name of search parameter. <input type="text" name="search" size="20" /> After adding the textbox for the search keyword, we need to add the dropdown list which contains the language of the article to search. The name of this dropdown-list should be language as we’ve to send the language code to the above URL in the language parameter. These language codes are two or three letter codes specified by ISO. ISO has assigned three letter language codes for most of the popular languages of the world. And, there are a few languages that are represented by two letter ISO codes. For example, eng and en are the three and two letter language code for English. Some of the article languages of Wikipedia don’t have ISO codes, and you have to find the value of the language parameter from Wikipedia. For example, articles in the Alemannisch language is als. Here is the HTML code for constructing a dropdown list in major languages : <select name="language"><option value="de" >Deutsch</option><option value="en" selected="selected">English</option><option value="es" >Español</option><option value="eo" >Esperanto</option><option value="fr" >Français</option><option value="it" >Italiano</option><option value="hu" >Magyar</option><option value="nl" >Nederlands</option></select> As you can see in the above dropdown list, English is the default language selected. Now, we just need to add a submit button in the above form to complete the form for searching the article in wikipedia. <input type="submit" name="go" value="Search" title="Search in wikipedia" /> Put all the HTML code together to create the form. JavaScript Code As we’ve already got the background concept of the HTML form, we just have to use the document.write() to output the HTML to the web browser. Here is the JavaScript code to create the Wiki Seek Widget : document.write('<div>');document.write('<form action="http://www.wikipedia.org/search-redirect.php" >');document.write('<input type="text" name="search" size="20" />');document.write('&nbsp;<select name="language">');document.write('<option value="de" >Deutsch</option>');document.write('<option value="en" selected="selected">English</option>');document.write('<option value="es" >Español</option>');document.write('<option value="eo" >Esperanto</option>');document.write('<option value="fr" >Français</option>');document.write('<option value="it" >Italiano</option>');document.write('<option value="hu" >Magyar</option>');document.write('<option value="nl" >Nederlands</option>');document.write('</select>');document.write('&nbsp;<input type="submit" name="go" value="Search" title="Search in wikipedia" />');document.write('</form>');document.write('</div>'); In the above code, I’ve used division (div) as the container for the HTML form. I’ve also saved the above code in a wiki_seek.js file. The above JavaScript code displays a non-stylish widget. To make a stylish widget, you can use style property in the input elements of the form. Using Wiki Seek widget To use this wiki seek widget we’ve to follow these steps: First of all, we need to upload the above wiki_seek.js to a web server so that it can be used by the client websites. Let’s suppose that is uploaded and placed in the URL : http://www.widget-server.com/wiki_seek.js Now, we can widget in any web pages by placing the following JavaScript Code in the website. <script type="text/javascript" language="javascript"src="http://www.widget-server.com/wiki_seek.js"></script> The Wiki Seek widget is displayed in any part of web page, where you place the above code.

Depending on your data modeling need and what you already have, there are two other ways to create a data model: Derive from an existing model and Reverse Engineer an existing database. Let’s start with creating a new model by clicking the Create model button. We’d like to create both logical and physical models, so select Logical/Physical. You can see in the Model Explorer that our new model gets Model_1 name, ERWin’s default name. Let’s rename our model to Packt Model. Confirm by looking at the Model Explorer that our model is renamed correctly. Next, we need to choose the ER notation. ERWin offers two notations: IDEF1X and IE. We’ll use IE for our logical and physical models. It’s a good practice during model development to save our work from time to time. Our model is still empty, so let’s next create a logical model in it. Logical Model Logical model in ERWin is basically ER model. An ER model consists of entities and their attributes, and their relationships. Let’s start by creating our first entity: CUSTOMER and its attributes. To add an entity, load (click) the Entity button on the toolbar, and drop it on the diagramming canvas by clicking your mouse on the canvas. Rename the entity’s default E/1 name to CUSTOMER by clicking on the name (E/1) and typing its new name over it. To add an attribute to an entity, right-click the entity and select Attributes. Click the New button. Type in our first attribute name (CUSTOMER_NO) over its name, and select Number as its data type, and then click OK. We want this attribute as the entity’s primary key, so check the Primary Key box. In the same way, add an attribute: CUSTOMER_NAME with a String data type. Our CUSTOMER entity now has two attributes as seen in its ER diagram. Notice that the CUSTOMER_NO attribute is at the key area, the upper part of the entity box; while the CUSTOMER_NAME is in the common attribute area, the bottom part. Similarly, add the rest of the entities and their attributes in our model. When you’re done, we’ll have six entities in our ER diagram. Our entities are not related yet. To rearrange the entities in the diagram, you can move around the entities by clicking and dragging them.

Getting started We are going to look at a few different modules, some of which we will use. These need to be installed first, so let's do that now to save us time. The modules We need to download the following modules: Addresses module (http://drupal.org/project/addresses) enable the Addresses, Addresses - Phone/Fax and Addresses - Users components. Simplenews module (http://drupal.org/project/simplenews) And extract them to our sites/all/modules folder, and enable them via the administration interface. A look back We have already looked at one very important aspect to communicate with our users—user e-mail settings. Within the User settings page (Administer | User management | User settings), we have a group of settings under the heading User e-mail settings. These are various email templates that are sent to our users upon certain events, such as registration, account activation, password reset, account being blocked or account being deleted. The content of these emails can be very important depending on the nature of the web site. In our Dino Space site, we may use a very informal, welcoming and fun tone for our automated emails. But for a business-oriented social network, we would want to use a much more formal tone. Modules Don't forget, many modules also have their own email templates for sending emails to users, all of which can normally be changed easily from their respective sections in the administration area. Communicating on an individual basis As we have installed the contact form module on our site, we can also communicate with our users on an individual basis using the contact forms on their profiles. This is handy for those times when we do need to contact an individual user, maybe because of complaints against them by other members of the community, or perhaps to invite them to become a moderator or contributor to the site. Alternatively, we can contact the user directly via their email addresses listed in their accounts, as this is viewable from the administration area. Inactive users We may wish to contact users who have not been active on the site for a long time, to remind them that the site is still there, and that they would be welcome to become active in the community once again. Drupal records the time a user was last active, which allows us to easily sort the list of users by their activity. A module (Inactive user) is available for Drupal 5, which is intended to contact inactive users automatically, but (at the time of writing this) one is not available for Drupal 6. You may wish to keep watch on the modules list on the Drupal.org web site to see if anything comes up in future http://drupal.org/project/inactive_user Communicating with individuals publicly Don't forget, we also have access to all of the communication methods available for our users to communicate with one another, such as replying to posts, commenting on content, or posting on their profiles. So if we need to contact a user, and we can contact them publicly, we can use these features. Mailing lists Drupal has a number of modules available for sending emails to our users. Many of them are still currently under heavy development, or had their development stopped after the release of a previous version of Drupal. One of these modules is Simplenews, which is a native Drupal system for managing newsletters. One limitation of the Simplenews module, and most of the modules available, is that it can't send to all our users; it requires users to subscribe to the mailing list. We can manage the Simplenews module via Administer | Newsletter. The features available to us are quite comprehensive. Let's have a look at how the module works: Newsletters are created and managed from here Users subscribe to various Newsletters Users can be imported into Newsletters to become a subscriber A message is sent to a newsletter (this is referred to as an issue) by creating Newsletters content Issues which have been sent are saved within the module Issues which have not yet been sent are saved within the module as drafts By default, we have a newsletter, which is generic to our site based on our site name. From here we can also create new Newsletters should we wish so. The Subscriptions tab allows us to see and manage the subscriptions to our various newsletters, the Sent issues tab lists issues sent out to the newsletter lists, and the Drafts tab lists issues which are still being written. From within the Settings tab, we can set how new issues for newsletters are created, as well as the email address shown as the sender of issues. Don't forget to set the permissions; you want your users to be able to subscribe to newsletters. Users can subscribe to newsletters from within their account, or we can enable blocks for the relevant newsletters we have on our site. To send an "issue" to our newsletter list, we need to create the issue as a new content element via Create content | Newsletter issue. We enter the subject of our email as the Title, select the newsletter to send the message to from the Newsletter drop-down list, and the message is entered into the Bodybox. Beneath these options, we have some newsletter specific-options within the Newsletter sending options box. These options allow us to set the priority of the email message (this is often ignored by email clients), if we wish to request a receipt to see if a user has read the message (this is also often ignored by email clients) and finally, we can select a sending method. There are three sending methods, which are: Don't send now—this won't send the message, and will save it as a draft. Send one test newsletter to the test address—this will send the email message to the test email addresses, which we can set in the administration area. This allows us to review the newsletter, as if we were a subscriber, make any final alterations and then send it to our list. Send newsletter—this sends the email to our newsletter list. How to send an email to all our users? We can use the module to send an email to all of our users, by taking advantage of the subscriber import feature. Within Administer | Content management | Newsletters | Subscriptions, we have the ability to Import subscriptions, as shown in the following screenshot: Importing subscribers consists of entering the E-mail addresses (separated by a comma) and selecting the newsletter which we wish the user to subscribe to. To get all of our current members to subscribe to the mailing list, we could export all of our users' email addresses directly from the Drupal database, using a tool such as phpMyAdmin. If we use the tool correctly, we can even get the data in a comma-separated list ready to be pasted into the form.

Library services Library services are common document management functions for controlling the users through permissions, for creating multiple instances of a document(versioning), and for providing users with access into a document to make the changes (checking-in or checking-out). Versioning You might have more than one person who can edit a document. What if somebody edits a document and removes a useful piece of information? Well, you can make use of the versioning features of Alfresco to resolve such issues. Versioning allows the history of previous versions of a content to be kept. The content needs to be Versionable, in order for versions to be kept. You can enable versioning in four different ways: Individually: To enable versioning for an individual content object item, go to the View Details page and click on the Allow Versioning link. The next screenshot illustrates how to enable versioning on an individual content item. Using Smart Spaces: A business rule can be set for a space to allow versioning of all of the content or selected content within that space. By Type: By default, versioning is disabled for all of the content types in the Alfresco content model. Versioning can be enabled for a specific content type, irrespective of the location of the content. Globally: Alfresco can be configured globally to enable versioning for all content throughout the site. Enable versioning for sample file that you have already uploaded to the system. Go to the Intranet > Marketing Communications > Switch to open source ECM > 02_Drafts space and view the details of Alfresco_CIGNEX.doc file. Click on the Allow Versioning link to enable versioning, as shown in the following screenshot. You will immediately notice that a version with a version number of 1.0 is created. At the time of writing this article (Alfresco version 3.1), reverting back to an older version of the content is not supported. There is a plan to support this feature in future releases of Alfresco. The workaround is to download the older version and upload it again as the current version. For a checked out content, the version is updated when the content is checked in. The version number is incremented from the version number of the content object that was checked out. Auto Versioning Auto versioning can be enabled by editing the content properties and selecting the Auto Version checkbox. If auto versioning is enabled, then each Save of the content results in an incremented version number, when the content is edited directly from the repository. Each Update (upload) of the content also results in a new version (with an incremented version number) being created. If auto versioning is not enabled, then the version number is incremented only when the content is checked in. Check In and Check Out By using the versioning feature, you can ensure that all of the changes made to a document are saved. You might have more than one person who can edit a document. What if two people edit a document at once, and you get into a mess with two new versions? To resolve this issue, you'll need to use the library services. Library services provide the ability to check out a document, reserving it for one user to edit, while others can only access the document in read-only mode. Once the necessary changes have been made to the document, the user checks in the document, and can either replace the original, or create a new version of the original. Check Out locks the item and creates a working copy that can be edited (both the content and the details). Check In replaces the original item with the working copy, and releases the lock.

A simple Facebook application Well, with the Facebook side of things set up, it's now over to your server to build the application itself. The server could of course be: Your web host's server – This must support PHP, and it may be worthwhile for you to check if you have any bandwidth limits. Your own server – Obviously, you'll need Apache and PHP (and you'll also need a fixed IP address). Getting the server ready for action Once you have selected your server, you'll need to create a directory in which you'll build your application, for example: mkdir -p /www/htdocs/f8/penguin_picd /www/htdocs/f8/penguin_pi If you haven't already done so, then this is the time to download and uncompress the Facebook Platform libraries: wget http://developers.facebook.com/clientlibs/facebook-platform.tar.gztar -xvzf facebook-platform.tar.gz We're not actually going to use all of the files in the library, so you can copy the ones that you're going to use into your application directory: cp facebook-platform/client/facebook.phpcp facebook-platform/client/facebookapi_php5_restlib.php And once that's done, you can delete the unwanted files: rm -rf facebook-platform.tar.gz facebook-platform Now, you're ready to start building your application. Creating your first Facebook application Well, you're nearly ready to start building your application. First, you'll need to create a file (let's call it appinclude.php) that initiates the application. The application initiation code We've got some code that needs to be executed every time our application is accessed, and that code is: <?phprequire_once 'facebook.php'; #Load the Facebook API$appapikey = '322d68147c78d2621079317b778cfe10'; #Your API Key$appsecret = '0a53919566eeb272d7b96a76369ed90c'; #Your Secret$facebook = new Facebook($appapikey, $appsecret); #A Facebook object$user = $facebook->require_login(); #get the current user$appcallbackurl = 'http://213.123.183.16/f8/penguin_pi/'; #callback Url#Catch an invalid session_keytry { if (!$facebook->api_client->users_isAppAdded()) { $facebook->redirect($facebook->get_add_url()); }} catch (Exception $ex) { #If invalid then redirect to a login prompt $facebook->set_user(null, null); $facebook->redirect($appcallbackurl);}?> You'll notice that the code must include your API Key and your secret (they were created when you set up your application in Facebook). The PHP file also handles any invalid sessions. Now, you're ready to start building your application, and your code must be written into a file named index.php. The application code Our application code needs to call the initiation file, and then we can do whatever we want: <?phprequire_once 'appinclude.php'; #Your application initiation fileecho "<p>Hi $user, ";echo "welcome to Pygoscelis P. Ellsworthy's Suspect Tracker</p>";?> Of course, now that you've written the code for the application, you'll want to see what it looks like. Viewing the new application Start by typing your Canvas Page URL into a browser (you'll need to type in your own, but in the case of Pygoscelis P. Ellesworthy's Suspect Tracker, this would be http://apps.facebook.com/penguin_pi/): You can then add the application just as you would add any other application: And at last, you can view your new application: It is worth noting, however, that you won't yet be able to view your application on your profile. For the time being, you can only access the application by typing in your Canvas Page URL. That being said, your profile will register the fact that you've added your application: That's the obligatory "Hello World" done. Let's look at how to further develop the application.

FileField remixed If you haven't examined FileField, you'll have to do so by downloading the FileField module from http://drupal.org/project/filefield and enable it on the Modules administration page (by browsing to Administer | Site building | Modules, at /admin/build/modules). Now create a new content type named Album by going to Administer | Content management | Content types | Add content type (at /admin/content/types/add). We'll next add a FileField to this by editing the new Album type and selecting the Add field tab (at /admin/content/types/album/add_field). Call it Song, select the File for the Field type, press Continue, and press Continue again (leaving the Widget type as File Upload). In the Permitted upload file extensions, enter mp3 for now. If you wish, you may enter a new File path as well such as audio. Uploaded files would then be saved to that path. Note that you have access to the Token module's features here. So, for instance you may enter something like audio/[user-raw], which will replace [user-raw] with the username of the node's creator: Finally, select Unlimited for the Number of values, since we'll allow a single album to contain many songs. We'll also check the Required checkbox so that each album will hold at least one song. Finally, we will ensure that the Default listed value is Listed, and that we select the Enforce Default radio button for How should the list value be handled? This will force a node to always list files when displayed. We need to list our files, although we plan ultimately to control display of an album's songs in the player: Now we can add an album node with a few songs by going to Create content | Album (at /node/add/album). Uploading is simple. At this point, we only have a link displayed for our files. Our next task is to create an inline player for the audio. One possibility would be to override the theme function. However, we have other tools available that will make our job easier and even ensure cross-browser compatibility, better accessibility, and valid HTML: jQuery Media to the rescue The jQuery Media plug-in, written by Mike Alsup at http://www.malsup.com/jquery/media/, is a perfect solution. It will convert any link to media into the browser-specific code required for displaying the media. The jQuery Media module is a configurable wrapper for this plug-in. We'll also need a media player. For this exercise, we'll again use the JW FLV Media Player developed by Jeroen Wijering. This excellent player is free for non-commercial use, and has a very inexpensive licensing fee for other uses. First, download that player from http://jeroenwijering.com/ and install the player.swf file somewhere in your site's directory tree. If you install it in the site's www root folder, the module will work with little extra configuration. But you can install it in the files directory, your theme folder, or another convenient place if you need it for your environment. Just remember where you put it for future reference. Next, download and enable the jQuery Media module from http://drupal.org/project/jquery_media. You may wish to also install the jQ module from http://drupal.org/project/jq, which consolidates jQuery plug-ins installed on your site. The configuration is simple. You'll just need to enter the filepath of your media player, which can be different than the Flash Video player entered earlier, if desired. Go to the jQuery Media Administration page by browsing to Administer | Site configuration | jQuery Media Administration (at /admin/settings/jquery_media). Open the Default players (within Extra settings) and enter the filepath of your media player in the MP3 Player (mp3Player) text field: Now just check the Album box in Node types, and set the width and height within Default settings. In most cases, you would be done and the audio would be displayed automatically with no further configuration. However, we're assuming you plan to use this module in conjunction with videos, which may have already set a width and height. That means we'll need to do some more customization. Note: You do not need to do any of this, unless you have video and audio files on the site both using jQuery Media. We need to change the class of our field and add a new invocation script. However, we don't want to affect the class of our existing video files. So add the following somewhere in the phptemplate_preprocess_filefield_file function, creating that function if necessary. (If you haven't already done that, then create function phptemplate_preprocess_filefield_file(&$variables) in template.php. $node = node_load($file['nid']); if ($node->type == 'album') { $variables['classes'] = 'filefield-file-song'; if (module_exists('jquery_media')) { jquery_media_add(array('media class' => '.filefield-file-song a', 'media height' => 20, 'media width' => 200)); } } else { $variables['classes'] = 'filefield-file'; } Then you'll need to change a line in filefield_file.tpl.php. (If you haven't already created that file, create it in your theme directory, and copy the code from the theme_filefield_file function that is found in /sites/all/modules/filefield/filefield_formater.inc.) The original line in question reads as follows: return '<div class="filefield-file clear-block">'. $icon . l($file['filename'], $url) .'</div>'; However, we can rewrite that line to read: <div id="filefield-file-file-<?php print $id; ?>" class="filefield-file clear-block" <?php print $style; ?> > In either case, simply replace class="filefield-file clear-block" with class=" clear-block".

Welcome to the exciting world of Essbase Analytics known as the Aggregate Storage Option (ASO). Well, now you're ready to take everything one step further. You see, the BSO architecture used by Essbase is the original database architecture as the behind the scenes method of data storage in an Essbase database. The ASO method is entirely different. What is ASO ASO is Essbase's alternative to the sometimes cumbersome BSO method of storing data in an Essbase database. In fact, it is BSO that is exactly what makes Essbase a superior OLAP analytical tool but it is also the BSO that can occasionally be a detriment to the level of system performance demanded in today's business world. In a BSO database, all data is stored, except for dynamically calculated members. All data consolidations and parent-child relationships in the database outline are stored as well. While the block storage method is quite efficient from a data to size ratio perspective, a BSO database can require large amounts of overhead to deliver the retrieval performance demanded by the business customer. The ASO database efficiently stores not only zero level data, but can also store aggregated hierarchical data with the understandings that stored hierarchies can only have the no-consolidation (~) or the addition (+) operator assigned to them and the no-consolidation (~) operator can only be used underneath Label Only members. Outline member consolidations are performed on the fly using dynamic calculations and only at the time of the request for data. This is the main reason why ASO is a valuable option worth consideration when building an Essbase system for your customer. Because of the simplified levels of data stored in the ASO database, a more simplified method of storing the physical data on the disk can also be used. It is this simplified storage method which can help result in higher performance for the customer. Your choice of one database type over the other will always depend on balancing the customer's needs with the server's physical capabilities, along with the volume of data. These factors must be given equal consideration. Creating an aggregate storage Application|Database Believe it or not, creating an ASO Essbase application and database is as easy as creating a BSO application and database. All you need to do is follow these simple steps: Right-click on the server name in your EAS console for the server on which you want to create your ASO application. Select Create application | Using aggregate storage as shown in the following screenshot: Click on Using aggregate storage and that's it. The rest of the steps are easy to follow and basically the same as for a BSO application. To create an ASO application and database, you follow virtually the same steps as you do to create a BSO application and database. However, there are some important differences, and here we list a few: A BSO database outline can be converted into an Aggregate Storage database outline, but an Aggregate Storage database outline cannot be converted into a Block Storage database outline.Steps to convert a BSO application into an ASO application: Open the BSO outline that you wish to convert, select the Essbase database and click on the File | Wizards | Aggregate Storage Outline Conversion option. You will see the first screen Select Source Outline. The source of the outline can be in a file system or on the Essbase Server. In this case, we have selected the OTL from the Essbase Server and then click Next as shown in the following screenshot: In the Next screen, the conversion wizard will verify the conversion and display a message that the conversion has completed successfully. Click Next. Here, Essbase prompts you to select the destination of the ASO outline. If you have not yet created an ASO application, you can click on the Create Aggregate Storage Application on the bottom-right corner of the screen as shown in the next screenshot: Enter the Application and the Database name and click on OK. Your new ASO application is created, now click on Finish. Your BSO application is now converted into an ASO application. You may still need to tweak the ASO application settings and outline members to be the best fit for your needs. In an ASO database, all dimensions are Sparse so there is no need to try to determine the best Dense/Sparse settings as you would do with a BSO database. Although Essbase recommends that you only have one Essbase database in an Essbase application, you can create more than one database per application when you are using the BSO. When you create an ASO application, Essbase will only allow one database per application. There is quite a bit to know about ASO but have no fear, with all that you know about Essbase and how to design and build an Essbase system, it will seem easy for you. Keep reading for more valuable information on the ASO for things like, when it is a good time to use ASO, or how do you query ASO databases effectively, or even what are the differences between ASO and BSO. If you understand the differences, you can then understand the benefits.

In essence, ADO.NET Data Services serves up data as a web service over HTTP using the objects in the Entity Model of the data and conforms to the principles of REST (Representational State Transfer) wherein everything is a kind of resource with a name and they can be manipulated using the well known HTTP Verbs; Get, Put, Post and Delete. The data can be returned in a number of formats including RSS and ATOM. According to W3C, "Atom" is an XML-based document format that describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached "metadata". Create an ASP.NET Web Application Create an ASP.NET Web application as shown below and make sure the target platform is 3.5. Create the Entity Model Right click the Application in Solution Explorer and click on Add New Item. In the Add New Item window click on ADO.NET Entity Data Model and change the default name Model1.edmx to one of your choice. Here it is MyFirst.edmx. Then click on the Add button. This brings up the Entity Data Model Wizard as shown. Read the notes on this page. Now click on the Generate from Database and click Next. This opens the 'Choose Your Data Connection' page of the wizard as shown with some default connection as shown. Change it over to the TestNorthwind database on SQL Server 2008 Enterprise Edition (RTM). TestNorthwind is a copy of the Northwind database and click Next. Of course you can create a new connection as well. The connection is saved to the Web.Config file. Click on the Next button. The wizard changes page so that you can 'Choose your Database Objects' This may take some time as the program accesses the database and the following page is displayed. The model uses the relational data in the database. Place a check mark for the Tables to include all the tables in the database. The TestNorthwindModel namespace gets created. Click on the Finish button. This brings up the ModelBrowser browsing the MyFirst.edmx file as shown. The MyFirst.edmx file contents are shown in the next figure. By right clicking inside the MyFirst.edmx you can choose the Zoom level for the display. The connected items shown are the tables with relationships in the database. Those standing alone are just tables that are not a part of the original database and can be removed by right clicking and deleting them. The tables retained finally for the model are as shown. Make use of the Zoom controls to adjust to your comfort level. As seen in the above each table has both Scalar Properties as well as Navigation Properties. The Navigation properties shows the relationship with other tables. In the OrderDetails table shown, the connections extend to the Orders table and the Products table. On the other hand the Orders table is connected to, Customers, Employees, Order_Details and Shippers. In the Solution Explorer the MyFirst.edmx file consists of the TestNorthwindModel and the TestNorthwindModel.store folders. The model folder consist of the Entities and the Assoications(relationships between entities) and the EntityContainer as shown.

Viewing Our First Entry Now one question remains: where do we have to go to see our entry? The answer is that our entry is not yet on our website. That is because the entry does not appear in a template and everything on an ExpressionEngine website must go into a template before it can be viewed. Follow these instructions to point a template to our new weblog. Click on Templates in the menu bar. Select Create a New Template Group, and call the New Template Group to be news. Leave all the other options at their default and click Submit. Select the news template group, and then click on the index template to edit it. To include a weblog in a template, we use a tag. A tag is a unique ExpressionEngine piece of code that is used in templates to include extra functionality. In this case, we want to include a weblog, so we need a weblog tag. A tag has two parts: variables and parameters. Parameters are always part of the opening tag whereas variables are used between the opening tag and the closing tag. In the news/index template we will add in the weblog tag as well as some standard HTML code. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html > <head> <title>News from the President</title> <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> </head> <body> <h1>Toast for Sale!</h1> <h2>News from the President</h2> {exp:weblog:entries weblog="toastnews"} <h3>{title}</h3> {summary} {body} {extended} {/exp:weblog:entries} </body> </html> The indentation helps to demarcate related sections and therefore make the code more readable, but is certainly not required. Click Update and Finished to save our updates. The difference between Update and Update and Finished is that Update will keep you in the template editing screen so that you can continue to make further edits, whereas Update and Finished returns you to the main templates screen. Now view the news template at http://localhost/news or www.example.com/news to see how it looks. It should look like the following screenshot. Notice how the {title} has been changed to reflect the actual title of our entry (and so has {summary} and {body}). What happens if we post two entries? Let us try it and see! Back in the control panel, select Publish | Toast News and write a second entry with a different title, URL title, and so forth. Hit Submit, and then visit http://localhost/news or http://www.example.com/news to see what happens. It should look like as follows: For our final enhancement, let us edit the template to include variables for the author name and the date of the entry. To do this, add the highlighted code as shown next: <body> <h1>Toast for Sale!</h1> <h2>News from the President</h2> {exp:weblog:entries weblog="toastnews"} <h3>{title}</h3> {summary} {body} {extended} <p class="footnote">Written by {author} on {entry_date format="%F %j%S"}</p> {/exp:weblog:entries} </body> {author} is a variable that returns the name of the person who was logged in when the entry was created. {entry_date} is a variable that displays the date that the entry was written on. format is a parameter of the entry_date variable that is used to specify how the date should be formatted. %F is the month of the year spelled out; %j is the day of the month; and %S is the suffix (for example, nd or th). So %F %j%S is rendered as 'February 7th'. For a complete list of date formats, visit http://expressionengine.com/docs/templates/ date_variable_formatting.html.   Revisit http://localhost/news or http://www.example.com/news, and you can now see the author name underneath both entries. Make Our Weblog Pretty Using CSS Our weblog, whilst functional, is not exactly the prettiest on the web. We will spruce it up with some more HTML and CSS. This section will not introduce any new ExpressionEngine features but will demonstrate how to incorporate standard CSS into our templates. An understanding of HTML and CSS will be invaluable as we develop our ExpressionEngine site. Please note that this article can only demonstrate the basics of using HTML with CSS in an ExpressionEngine website. If you are already familiar with using HTML and CSS, then you will only need to go through the section in the first part (Creating and Linking to a Styling Template) to create the CSS template and link to it from the HTML template. Creating and Linking to a Styling Template As with a more conventional HTML/CSS website, our CSS code will be separated out from our HTML code, and placed in its own template (or file). This requires creating a new CSS template and modifying our existing template to identify the main styling elements, as well as to link to the CSS template. First, let us go back into our news template and add the following code (highlighted). The trick with writing HTML with CSS is to identify the main sections of the HTML code using the <div> tag. <body> <div id="header"> <h1>Toast for Sale!</h1> <h2>News from the President</h2> </div> <div id="content"> {exp:weblog:entries weblog="toastnews"} <h3>{title}</h3> <div class="contentinner"> {summary} {body} {extended} </div> <p class="footnote">Written by {author} on {entry_date format="%F %j%S"}</p> {/exp:weblog:entries} </div> </body> Here we have identified three sections using the <div> tag. We have encapsulated our website title in a header section. We have wrapped up all of our ExpressionEngine entries into a content section. Finally, we have created a contentinner section that contains just the text for each ExpressionEngine entry, but does not include the title. Also note that footnote is a section. What is the difference between an id and a class in our <div> tags? A section defined with an id only appears once on a page. In our case, the header only appears once, so we can use the id. A section defined with a class may appear multiple times. As the contentinner section will appear on the page for each entry present there, we have used a class for this section. Next, we want to create a CSS template that tells us what to do with these sections. To do this, go back to the main Templates page, select the toast template group, and then select New Template. Call the new template toast_css. Under Template Type select CSS Stylesheet instead of Web Page. Leave the Default Template Data as None – create an empty template and hit Submit. Before we start editing our new CSS template, we must be sure to tell the HTML template about it. Select to edit the index template in the news template group. Insert the following highlighted commands between the <head> and </head> tags to tell the HTML template where the CSS template is. <head> <title>News from the President</title> <link rel='stylesheet' type='text/css' media='all' href='{path=toast/toast_css}' /> <style type='text/css' media='screen'>@import "{path=toast/toast_css}";</style> <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> </head>

Doug is an avid dinosaur and model enthusiast, and runs his own shop and museum selling model dinosaurs and offering information and facts on various dinosaurs. For the purpose of this article, we will create an e-commerce website named 'Doug's Dinos!' for Doug and his business. Making Things Easier Although Doug's store is relatively simple for his customers to use, it is missing three key features that would make their time on the website easier, these are: An overview of the shopping cart Search features Ability to auto-create user accounts At the moment, without a search feature the only way for users to find products is by manually browsing through the website and stumbling across a product they like. Adding a Shopping Cart We can add a shopping cart to our theme so that customers can continue browsing the website but still know how much is in their shopping cart, and easily get to it later. To add this block, we need to go to the Blocks section, which is under Site Building within the Administer area. Within the Blocks section, we need to ensure we have all our themes selected (or do this for each theme we are using) and then change the Region of the Shopping cart to the left sidebar. Once we click on the Save blocks button, the shopping cart block is displayed in our theme: Adding Search Capabilities Doug tested the website with a few friends and family members, and their main issue with it was the difficulty in finding products they wanted. The first thing we need to do is install the Search module, which is grouped under the Core - optional section of Modules in the Administer area. With the module installed, we now need to enable the Search feature from the Blocks section; otherwise the search box won't be displayed on the website. We can select this feature by going to Administer | Site Building | Blocks, then set it up in the same way as for the shopping cart and save the settings. We now have a search box on our website under the header but above the main menu! Let's try searching for one of our products, for instance T-Rex. Notice something? No results found! This seems quite strange as we have a product with T-Rex in the name, so why didn't we get any results? The reason for this is that Drupal has not yet been indexed. Drupal uses a cron job to create the index of the site. Without the indexing done Search options cannot work. The Search settings under Administer | Site configuration allow us to specify how many pages are indexed per "cron run" and allow us to set the site to be re-indexed. Cron JobsA cron job is a setting on your web host's server (if you have cPanel hosting, it is available under "crontab") that performs tasks at specific times. Drupal has a special page that performs various tasks; this can be called by a cron job so that it regularly opens the page and runs the tasks. This setting depends on having set up a cron job to periodically call the cron.php file. For more information on setting up cron jobs, you should contact your web host. Typically it involves a crontab setting in your hosting control panel such as cPanel. We can manually run the cron task, by opening the cron.php file in our web browser. In this case we just open: http://www.dougsdinos.com/cron.php. Once we have opened this page, let's try searching for T-Rex again. This time we will get some results! Customers will now be able to find products and other content on Doug's website much more easily! Auto-Creating User Accounts If a customer is not a user on our site, we can automatically create a user account for them once they have placed their order; this saves the inconvenience of using an anonymous purchase policy where the user has to log in or register, but it gives the user the added convenience of having their details saved for future orders. This is something Doug wants to enable to make things easier for regular customers on this site. The first thing we need to do is install the module. The module is called EC Useracc and is listed in the E-Commerce Uncategorized group of modules. Now under E-Commerce configuration we have a new option called User Account; let's take a look at it. This has the following settings: Confirmation e-mail Welcome mail Days to confirm expiry The Confirmation e-mail is to see if the customer wants to create a user account; this email expires after the number of days set in the Days to confirmation expiry setting has passed, and the Welcome mail is the email sent when the account is created. These emails can be configured on the Mail page. These settings don't actually enable the feature though; we have installed the module and looked at the global settings, but to actually get it to work we need to set how we would like each product to work in relation to this module. If we go to edit any product, there is a new section, which was not there previously, called User account provision; this is what we need to change. As Doug wants this feature enabled, we need to check the option Create an account for the user when this product is purchased. The other option, Block the user's account when this product expires, relates to using recurring billing in products (mainly non-tangible products i.e. services) such as a customer support contract or a magazine subscription.

Building the Documentation An easier way to guide your readers and your writers is to provide each one of them with helpers and guidelines, as we have learned in the previous section of this article. From a writer's point of view, this is done by having a set of reusable templates together with a guide that describes how and when to use them in a project. It is called a documentation portfolio. From a reader point of view, being able to browse the documentation with no pain, and getting used to finding the info efficiently, is done by building a document landscape. Building the Portfolio There are many kinds of documents a software project can have, from low-level documents that refer directly to the code, to design papers that provide a high-level overview of the application. For instance, Scott Ambler defines an extensive list of document types in his book Agile Modeling (http://www.agilemodeling.com/essays/agileArchitecture.htm). He builds a portfolio from early specifications to operations documents. Even the project management documents are covered, so the whole documenting needs are built with a standardized set of templates. Since a complete portfolio is tightly related to the methodologies used to build the software, this article will only focus on a common subset that you can complete with your specific needs. Building an efficient portfolio takes a long time, as it captures your working habits. A common set of documents in software projects can be classified in three categories: Design: All documents that provide architectural information, and low-level design information, such as class diagrams, or database diagrams Usage: Documents on how to use the software; this can be in the shape of a cookbook and tutorials, or a module-level help Operations: Provide guidelines on how to deploy, upgrade, or operate the software Design The purpose of design documentation is to describe how the software works and how the code is organized. It is used by developers to understand the system but is also a good entry point for people who are trying to understand how the application works. The different kinds of design documents a software can have are: Architecture overview Database models Class diagrams with dependencies and hierarchy relations User interface wireframes Infrastructure description Mostly, these documents are composed of some diagrams and a minimum amount of text. The conventions used for the diagrams are very specific to the team and the project, and this is perfectly fine as long as it is consistent. UML provides thirteen diagrams that cover most aspects in a software design. The class diagram is probably the most used one, but it is possible to describe every aspect of software with it. See http://en.wikipedia.org/wiki/Unified_Modeling_Language#Diagrams. Following a specific modeling language such as UML is not often fully done, and teams just make up their own way throughout their common experience. They pick up good practice from UML or other modeling languages, and create their own recipes. For instance, for architecture overview diagrams, some designers just draw boxes and arrows on a whiteboard without following any particular design rules and take a picture of it. Others work with simple drawing programs such as Dia (http://www.gnome.org/projects/dia) or Microsoft Visio (not open source, so not free), since it is enough to understand the design. Database model diagrams depend on the kind of database you are using. There are complete data modeling software applications that provide drawing tools to automatically generate tables and their relations. But this is overkill in Python most of the time. If you are using an ORM such as SQLAlchemy (for instance), simple boxes with lists of fields, together with table relations are enough to describe your mappings before you start to write them. Class diagrams are often simplified UML class diagrams: There is no need in Python to specify the protected members of a class, for instance. So the tools used for an architectural overview diagram fit this need too. User interface diagrams depend on whether you are writing a web or a desktop application. Web applications often describe the center of the screen, since the header, footer, left, and right panels are common. Many web developers just handwrite those screens and capture them with a camera or a scanner. Others create prototypes in HTML and make screen snapshots. For desktop applications, snapshots on prototype screens, or annotated mock-ups made with tools such as Gimp or Photoshop are the most common way. Infrastructure overview diagrams are like architecture diagrams, but they focus on how the software interacts with third-party elements, such as mail servers, databases, or any kind of data streams. Common Template The important point when creating such documents is to make sure the target readership is perfectly known, and the content scope is limited. So a generic template for design documents can provide a light structure with a little advice for the writer. Such a structure can include: Title Author Tags (keywords) Description (abstract) Target (Who should read this?) Content (with diagrams) References to other documents The content should be three or four screens (a 1024x768 average screen) at the most, to be sure to limit the scope. If it gets bigger, it should be split into several documents or summarized. The template also provides the author's name and a list of tags to manage its evolutions and ease its classification. This will be covered later in the article. Paster is the right tool to use to provide templates for documentation. pbp.skels implements the design template described, and can be used exactly like code generation. A target folder is provided and a few questions are answered: $ paster create -t pbp_design_doc designSelected and implied templates:pbp.skels#pbp_design_doc A Design documentVariables:egg: designpackage: designproject: designEnter title ['Title']: Database specifications for atomisator.dbEnter short_name ['recipe']: mappersEnter author (Author name) ['John Doe']: TarekEnter keywords ['tag1 tag2']: database mapping sqlCreating template pbp_design_docCreating directory ./designCopying +short_name+.txt_tmpl to ./design/mappers.txt The result can then be completed: =========================================Database specifications for atomisator.db=========================================:Author: Tarek:Tags: database mapping sql:abstract:Write here a small abstract about your design document... contents ::Who should read this ?::::::::::::::::::::::Explain here who is the target readership.Content:::::::Write your document here. Do not hesitate to split it in severalsections.References::::::::::Put here references, and links to other documents. Usage Usage documentation describes how a particular part of the software works. This documentation can describe low-level parts such as how a function works, but also high-level parts such command-line arguments for calling the program. This is the most important part of documentation in framework applications, since the target readership is mainly the developers that are going to reuse the code. The three main kinds of documents are: Recipe: A short document that explains how to do something. This kind of document targets one readership and focuses on one specific topic. Tutorial: A step-by-step document that explains how to use a feature of the software. This document can refer to recipes, and each instance is intended to one readership. Module helper: A low-level document that explains what a module contains. This document could be shown (for instance) when you call the help built-in over a module. Recipe A recipe answers a very specific problem and provides a solution to resolve it. For example, ActiveState provides a Python Cookbook online (a cookbook is a collection of recipes), where developers can describe how to do something in Python (http://aspn.activestate.com/ASPN/Python/Cookbook). These recipes must be short and are structured like this: Title Submitter Last updated Version Category Description Source (the source code) Discussion (the text explaining the code) Comments (from the web) Often, they are one-screen long and do not go into great details. This structure perfectly fits a software's needs and can be adapted in a generic structure, where the target readership is added and the category replaced by tags: Title (short sentence) Author Tags (keywords) Who should read this? Prerequisites (other documents to read, for example) Problem (a short description) Solution (the main text, one or two screens) References (links to other documents) The date and version are not useful here, since we will see later that the documentation is managed like source code in the project. Like the design template, pbp.skels provide a pbp_recipe_doc template that can be used to generate this structure: $ paster create -t pbp_recipe_doc recipesSelected and implied templates:pbp.skels#pbp_recipe_doc A recipeVariables:egg: recipespackage: recipesproject: recipesEnter title (use a short question): How to use atomisator.dbEnter short_name ['recipe'] : atomisator-dbEnter author (Author name) ['John Doe']: TarekEnter keywords ['tag1 tag2']: atomisator dbCreating template pbp_recipe_docCreating directory ./recipesCopying +short_name+.txt_tmpl to ./recipes/atomisator-db.txt The result can then be completed by the writer: ========================How to use atomisator.db========================:Author: Tarek:Tags: atomisator db.. contents ::Who should read this ?::::::::::::::::::::::Explain here who is the target readership.Prerequisites:::::::::::::Put here the prerequisites for people to follow this recipe.Problem:::::::Explain here the problem resolved in a few sentences.Solution::::::::Put here the solution.References::::::::::Put here references, and links to other recipes. Tutorial A tutorial differs from a recipe in its purpose. It is not intended to resolve an isolated problem, but rather describes how to use a feature of the application step by step. This can be longer than a recipe and can concern many parts of the application. For example, Django provides a list of tutorials on its website. Writing your first Django App, part 1 (http://www.djangoproject.com/documentation/tutorial01) explains in ten screens how to build an application with Django. A structure for such a document can be: Title (short sentence) Author Tags (words) Description (abstract) Who should read this? Prerequisites (other documents to read, for example) Tutorial (the main text) References (links to other documents) The pbp_tutorial_doc template is provided in pbp.skels as well with this structure, which is similar to the design template. Module Helper The last template that can be added in our collection is the module helper template. A module helper refers to a single module and provides a description of its contents, together with usage examples. Some tools can automatically build such documents by extracting the docstrings and computing module help using pydoc, like Epydoc ( http://epydoc.sourceforge.net). So it is possible to generate an extensive documentation based on API introspection. This kind of documentation is often provided in Python frameworks. For instance Plone provides an http://api.plone.org server that keeps an up-to-date collection of module helpers. The main problems with this approach are: There is no smart selection performed over the modules that are really interesting to document. The code can be obfuscated by the documentation. Furthermore, module documentation provides examples that sometimes refer to several parts of the module, and are hard to split between the functions' and classes' docstrings. The module docstring could be used for that purpose by writing a text at the top of the module. But this ends in having a hybrid file composed of a block of text, then a block of code. This is rather obfuscating when the code represents less than 50% of the total length. If you are the author, this is perfectly fine. But when people try to read the code (not the documentation), they will have to jump the docstrings part. Another approach is to separate the text in its own file. A manual selection can then be operated to decide which Python module will have its module helper file. The documents can then be separated from the code base and allowed to live their own life, as we will see in the next part. This is how Python is documented. Many developers will disagree on the fact that doc and code separation is better than docstrings. This approach means that the documentation process is fully integrated in the development cycle; otherwise it will quickly become obsolete. The docstrings approach solves this problem by providing proximity between the code and its usage example, but doesn't bring it to a higher level: a document that can be used as part of a plain documentation. The template for Module Helper is really simple, as it contains just a little metadata before the content is written. The target is not defined since it is the developers who wish to use the module: Title (module name) Author Tags (words) Content

(For more resources on .NET, see here.) Creating a control When building applications, you probably also build controls. Controls are re-usable components that contain functionality that can be re-used in different locations. In ASP.NET Webforms, a control is much like an ASP.NET web page. You can add existing web server controls and markup to a custom control and define properties and methods for it. When, for example, a button on the control is clicked, the page is posted back to the server that performs the actions required by the control. The ASP.NET MVC framework does not support ViewState and postbacks, and therefore, cannot handle events that occur in the control. In ASP.NET MVC, controls are mainly re-usable portions of a view, called partial views, which can be used to display static HTML and generated content, based on ViewData received from a controller. In this topic, we will create a control to display employee details. We will start by creating a new ASP.NET MVC application using File | New | Project... in Visual Studio, and selecting ASP.NET MVC Application under Visual C# - Web. First of all, we will create a new Employee class inside the Models folder. The code for this Employee class is: public class Employee{ public string FirstName { get; set; } public string LastName { get; set; } public string Email { get; set; } public string Department { get; set; }} On the home page of our web application, we will list all of our employees. In order to do this, modify the Index action method of the HomeController to pass a list of employees to the view in the ViewData dictionary. Here's an example that creates a list of two employees and passes it to the view: public ActionResult Index(){ ViewData["Title"] = "Home Page"; ViewData["Message"] = "Our employees welcome you to our site!"; List<Employee> employees = new List<Employee> { new Employee{ FirstName = "Maarten", LastName = "Balliauw", Email = "maarten@maartenballiauw.be", Department = "Development" }, new Employee{ FirstName = "John", LastName = "Kimble", Email = "john@example.com", Department = "Development" } }; return View(employees);} The corresponding view, Index.aspx in the Views | Home folder of our ASP.NET MVC application, should be modified to accept a List<Employee> as a model. To do this, edit the code behind the Index.aspx.cs file and modify its contents as follows: using System.Collections.Generic;using System.Web.Mvc;using ControlExample.Models;namespace ControlExample.Views.Home{ public partial class Index : ViewPage<List<Employee>> { }} In the Index.aspx view, we can now use this list of employees. Because we will display details of more than one employee somewhere else in our ASP.NET MVC web application, let's make this a partial view. Right-click the Views | Shared folder, click on Add | New Item... and select the MVC View User Control item template under Visual C# | Web | MVC. Name the partial view, DisplayEmployee.ascx. The ASP.NET MVC framework provides the flexibility to use a strong-typed version of the ViewUserControl class, just as the ViewPage class does. The key difference between ViewUserControl and ViewUserControl<T>is that with the latter, the type of view data is explicitly passed in, whereas the non-generic version will contain only a dictionary of objects. Because the DisplayEmployee.aspx partial view will be used to render items of the type Employee, we can modify the DisplayEmployee. ascx code behind the file DisplayEmployee.ascx.cs and make it strong-typed: using ControlExample.Models;namespace ControlExample.Views.Shared{ public partial class DisplayEmployee : System.Web.Mvc.ViewUserControl<Employee> { }} In the view markup of our partial view, the model can now be easily referenced. Just as with a regular ViewPage, the ViewUserControl will have a ViewData property containing a Model property of the type Employee. Add the following code to DisplayEmployee.ascx: <%@ Control Language="C#" AutoEventWireup="true" CodeBehind="DisplayEmployee.ascx.cs" Inheits="ControlExample.Views.Shared.DisplayEmployee" %><%=Html.Encode(Model.LastName)%>, <%=Html.Encode(Model.FirstName)%><br/><em><%=Html.Encode(Model.Department)%></em> The control can now be used on any view or control in the application. In the Views | Home | Index.aspx view, use the Model property (which is a List<Employee>) and render the control that we have just created for each employee: <%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" AutoEventWireup="true" CodeBehind="Index.aspx.cs"Inherits="ControlExample.Views.Home.Index" %><asp:Content ID="indexContent" ContentPlaceHolderID="MainContent"runat="server"> <h2><%= Html.Encode(ViewData["Message"]) %></h2> <p>Here are our employees:</p> <ul> <% foreach (var employee inModel) { %> <li> <% Html.RenderPartial("DisplayEmployee", employee); %> </li> <% } %> </ul></asp:Content> In case the control's ViewData type is equal to the view page's ViewData type, another method of rendering can also be used. This method is similar to ASP.NET Webforms controls, and allows you to specify a control as a tag. Optionally, a ViewDataKey can be specified. The control will then fetch its data from the ViewData dictionary entry having this key. <uc1:EmployeeDetails ID="EmployeeDetails1" runat="server" ViewDataKey="...." /> For example, if the ViewData contains a key emp that is filled with an Employee instance, the user control could be rendered using the following markup: <uc1:EmployeeDetails ID="EmployeeDetails1" runat="server" ViewDataKey="emp" /> After running the ASP.NET MVC web application, the result will appear as shown in the following screenshot:

Let's take a look at the XML Schema Definition (XSD) file of the Spring Web Flow configuration file. To make the file more compact and easier to read, we have removed documentation and similar additions from the file. The complete file is downloadable from http://www.springframework.org/schema/webflow/spring-webflow-2.0.xsd. An XSD file is a file that is used to describe an XML Schema, which in itself is a W3C recommendation to describe the structure of XML files. In this kind of definition files, you can describe which elements can or must be present in an XML file. XSD files are primarily used to check the validity of XML files that are supposed to follow a certain structure. The schema can also be used to automatically create code, using code generation tools. The elements of the Spring configuration file are: flow The root element of the Spring Web Flow definition file is the flow element. It has to be present in all configurations because all other elements are sub-elements of the flow tag, which defines exactly one flow. If you want to define more than one flow, you will have to use the same number of flow tags. As every configuration file allows only one root element, you will have to define a new configuration file for every flow you want to define. attribute Using  the attribute tag, you can define metadata for a flow. You can use this metadata to change the behavior of the flow. secured The secured tag is used to secure your flow using Spring Security. The element is defined like this: <xsd:complexType name="secured"> <xsd:attribute name="attributes" type="xsd:string" use="required" /> <xsd:attribute name="match" use="optional"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="any" /> <xsd:enumeration value="all" /> </xsd:restriction> </xsd:simpleType> </xsd:attribute> </xsd:complexType> If you want to use the secured element, you will have to at least define the attributes attribute. You can use the attributes element to define roles that are allowed to access the flow, for example. The match attribute defines whether all the elements specified in the attributes attribute have to match successfully (all), or if one of them is sufficient (any). persistence-context The persistence-context element enables you to use a persistence provider in your flow definition. This lets you persist database objects in action-states. To use persistence-context tag, you also have to define a data source and configure the persistence provider of your choice (for example, Hibernate or the Java Persistence API) in your Spring application context configuration file. The persistence-context element is empty, which means that you just have to add <persistence-context /> to your flow definition, to enable its features. var The var element can be used to define instance variables, which are accessible in your entire flow. These variables are quite important, so make sure that you are familiar with them. Using var elements, you can define model objects. Later, you can bind these model objects to the forms in your JSP web sites and can store them in a database using the persistence features enabled with the persistence-context element.  Nevertheless, using instance variables is not mandatory, so you do not have to define any, unless required in your flow. The element is defined as shown in the following snippet from the XSD file: <xsd:element name="var" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:attribute name="name" type="xsd:string" use="required" /> <xsd:attribute name="class" type="type" use="required" /> </xsd:complexType> </xsd:element> The element has two attributes that are both required. The instance variable you want to define needs a name, so that you can reference it later in your JSP files. Spring Web Flow also needs to know the type of the variable, so you have to define the class attribute with the class of your variable. input You can use the input element to pass information into a flow. When you call a flow, you can (or will have to, depending on whether the input element is required or not) pass objects into the flow. You can then use these objects to process your flow. The XML Schema definition of this element looks like this: <xsd:complexType name="input"> <xsd:attribute name="name" type="expression" use="required" /> <xsd:attribute name="value" type="expression" /> <xsd:attribute name="type" type="type" /> <xsd:attribute name="required" type="xsd:boolean" /> </xsd:complexType> The input element possesses certain attributes, of which only the name attribute is required. You have to specify a name for the input argument, which you can use to reference the variable in your flow. The value attribute is used to specify the value of the attribute, for example, if you want to define a default value for the variable. You can also define a type (for example int or long) for the variable if you want a specific type of information. A type conversion will be tried if the argument passed to the flow does not match the type you expect. With the required attribute, you can control if the user of your flow has to pass in a variable, or if the input attribute is optional. output While you can define input parameters with the input element, you can specify return values with the output element. These are variables that will be passed to your end-state as the result value of your flow. Here's the XML Schema definition of the output element: <xsd:complexType name="output"> <xsd:attribute name="name" type="expression" use="required" /> <xsd:attribute name="value" type="expression" /> <xsd:attribute name="type" type="type" /> <xsd:attribute name="required" type="xsd:boolean" /> </xsd:attribute> </xsd:complexType> The definition is quite similar to the input element. You can also see that the name of the output element is required. Otherwise, you have no means of referencing the variable from your end-state. The value attribute is the value of your variable, for example, the result of a computation or a user returned from a database. Of course, you can also specify the type you expect your output variable to be. As with the input element, a type conversion will be attempted if the type of the variable does not match the type specified here. The required attribute will check if nothing was specified, or the result of a computation is null. If it is null, an error will be thrown.   actionTypes Per se, this is not an element which you can use in your flow definition, but it is a very important part of the XML Schema definition, referenced by many other elements. The definition is quite complex and looks like this: <xsd:group name="actionTypes"> <xsd:choice> <xsd:element name="evaluate"> <xsd:complexType> <xsd:sequence> <xsd:element name="attribute" type="attribute" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="expression" type="expression" use="required" /> <xsd:attribute name="result" type="expression" use="optional" /> <xsd:attribute name="result-type" type="type" use="optional" /> </xsd:complexType> </xsd:element> <xsd:element name="render"> <xsd:complexType> <xsd:sequence> <xsd:element name="attribute" type="attribute" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="fragments" type="xsd:string" use="required" /> </xsd:complexType> </xsd:element> <xsd:element name="set"> <xsd:complexType> <xsd:sequence> <xsd:element name="attribute" type="attribute" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="name" type="expression" use="required" /> <xsd:attribute name="value" type="expression" use="required" /> <xsd:attribute name="type" type="type" /> </xsd:complexType> </xsd:element> </xsd:choice> </xsd:group> actionTypes is a group of sub-elements, namely evaluate, render, and set. Let's go through the single elements to understand how the whole definition works. evaluate With the evaluate element, you can execute code based on the expression languages. As described by the above source code, the element has three attributes; one of them is required. The expression attribute is required and executes the code that you want to run. The result value of the expression, if present, can be stored in the result attribute. Using the result-type attribute, you can convert the result value in the specified type, if needed. Additionally, you can define attributes using a sub-element of the attribute element. render Use the render element to partially render content of a web site. Using the required fragments attribute, you can define which fragments should be rendered. When the link on a web site is clicked the entire web site is not a re-load. Spring JavaScript allows you to update chosen parts of your web page. The remaining web site will not be reloaded, which can greatly enhance the performance of your web application. As is the case with the evaluate element, you can also specify additional attributes using the attribute sub-element. set The set element can be used to set attributes in one of the Spring Web Flows scopes. With the name attribute you can define where (in which scope) you want to define the attribute, and how it should be called. The following short source code illustrates how the set element works: <set name="flowScope.myVariable" value="myValue" type="long" /> As you can see, the name consists of the name of the scope and the name of your variable, delimited by a dot (.). Both the name attribute and the value attribute are required. The value is the actual value of your variable. The type attribute is optional and describes the type of your variable. As before, you can also define additional attributes using the attribute sub-element.

Documenting Your Project Documentation is work that is often neglected by developers and sometimes by managers. This is often due to a lack of time towards the end of development cycles, and the fact that people think they are bad at writing. Some of them are bad, but the majority of them are able to produce fine documentation. In any case, the result is a disorganized documentation made of documents that are written in a rush. Developers hate doing this kind of work most of the time. Things get even worse when existing documents need to be updated. Many projects out there are just providing poor, out-of-date documentation because the manager does not know how to deal with it. But setting up a documentation process at the beginning of the project and treating documents as if they were modules of code makes documenting easier. Writing can even be fun when a few rules are followed. This article provides a few tips to start documenting your project through: The seven rules of technical writing that summarize the best practices A reStructuredText primer, which is a plain text markup syntax used in most Python projects A guide for building good project documentation The Seven Rules of Technical Writing Writing good documentation is easier in many aspects than writing a code. Most developers think it is very hard, but by following a simple set of rules it becomes really easy. We are not talking here about writing a book of poems but a comprehensive piece of text that can be used to understand a design, an API, or anything that makes up the code base. Every developer is able to produce such material, and this section provides seven rules that can be applied in all cases. Write in two steps: Focus on ideas, and then on reviewing and shaping your text. Target the readership: Who is going to read it? Use a simple style: Keep it straight and simple. Use good grammar. Limit the scope of the information: Introduce one concept at a time. Use realistic code examples: Foos and bars should be dropped. Use a light but sufficient approach: You are not writing a book! Use templates: Help the readers to get habits. These rules are mostly inspired and adapted from Agile Documenting, a book by Andreas Rüping that focuses on producing the best documentation in software projects. Write in Two Steps Peter Elbow, in Writing with Power, explains that it is almost impossible for any human being to produce a perfect text in one shot. The problem is that many developers write documentation and try to directly come up with a perfect text. The only way they succeed in this exercise is by stopping the writing after every two sentences to read them back, and do some corrections. This means that they are focusing both on the content and the style of the text. This is too hard for the brain and the result is often not as good as it could be. A lot of time and energy is spent in polishing the style and shape of the text, before its meaning is completely thought through. Another approach is to drop the style and organization of the text and focus on its content. All ideas are laid down on paper, no matter how they are written. The developer starts to write a continuous stream and does not pause when he or she makes grammatical mistakes, or for anything that is not about the content. For instance, it does not matter if the sentences are barely understandable as long as the ideas are written down. He or she just writes down what he wants to say, with a rough organization. By doing this, the developer focuses on what he or she wants to say and will probably get more content out of his or her brain than he or she initially thought he or she would. Another side-effect when doing free writing is that other ideas that are not directly related to the topic will easily go through the mind. A good practice is to write them down on a second paper or screen when they appear, so they are not lost, and then get back to the main writing. The second step consists of reading back the whole text and polishing it so that it is comprehensible to everyone. Polishing a text means enhancing its style, correcting its faults, reorganizing it a bit, and removing any redundant information it has. When the time dedicated to write documentation is limited, a good practice is to cut this time in two equal durations—one for writing the content, and one to clean and organize the text. Focus on the content, and then on style and cleanliness. Target the Readership When starting a text, there is a simple question the writer should consider: Who is going to read it? This is not always obvious, as a technical text explains how a piece of software works, and is often written for every person who might get and use the code. The reader can be a manager who is looking for an appropriate technical solution to a problem, or a developer who needs to implement a feature with it. A designer might also read it to know if the package fits his or her needs from an architectural point of view. Let's apply a simple rule: Each text should have only one kind of readers. This philosophy makes the writing easier. The writer precisely knows what kind of reader he or she is dealing with. He or she can provide a concise and precise documentation that is not vaguely intended for all kinds of readers. A good practice is to provide a small introductory text that explains in one sentence what the documentation is about, and guides the reader to the appropriate part: Atomisator is a product that fetches RSS feeds and saves them in adatabase, with a filtering process.If you are a developer, you might want to look at the API description(api.txt)If you are a manager, you can read the features list and the FAQ(features.txt)If you are a designer, you can read the architecture andinfrastructure notes (arch.txt) By taking care of directing your readers in this way, you will probably produce better documentation. Know your readership before you start to write. Use a Simple Style Seth Godin is one of the best-selling writers on marketing topics. You might want to read Unleashing the Ideavirus, which is available for free on the Internet http://en.wikipedia.org/wiki/Unleashing_the_Ideavirus. Lately, he made an analysis on his blog to try to understand why his books sold so well. He made a list of all best sellers in the marketing area and compared the average number of words per sentences in each one of them. He realized that his books had the lowest number of words per sentence (thirteen words). This simple fact, Seth explained, proved that readers prefer short and simple sentences, rather than long and stylish ones. By keeping sentences short and simple, your writings will consume less brain power for their content to be extracted, processed, and then understood. Writing technical documentation aims to provide a software guide to readers. It is not a fiction story, and should be closer to your microwave notice than to the latest Stephen King novel. A few tips to keep in mind are: Use simple sentences; they should not be longer than two lines. Each paragraph should be composed of three or four sentences, at the most, that express one main idea. Let your text breathe. Don't repeat yourself too much: Avoid journalistic styles where ideas are repeated again and again to make sure they are understood. Don't use several tenses. Present tense is enough most of the time. Do not make jokes in the text if you are not a really fine writer. Being funny in a technical book is really hard, and few writers master it. If you really want to distill some humor, keep it in code examples and you will be fine. You are not writing fiction, so keep the style as simple as possible.

Build systems Build systems are not necessary for building web applications with Spring Web Flow, but they greatly assist a developer by resolving dependencies between packages and automating the build process. In this article, we will show you how to build your projects with Apache Ant and Apache Maven. Ant Ant is a powerful and very flexible build tool. You can write Extensible Markup Language (XML) files, which tell Ant how to build your application, where to find your dependencies, and where to copy the compiled files. Often, you won't find the need to download Ant, as it is already built-in into popular IDEs such as Eclipse and NetBeans. Ant does not provide you with an automatic dependency resolving mechanism. So you will have to manually download all the libraries your application needs. Alternatively, you can use a third-party dependency resolving system such as Apache Ivy, which we will describe later in this article. When you have obtained a copy of Ant, you can write a build.xml file as shown in the following code. <?xml version="1.0" encoding="UTF-8"?> <project name="login.flow" default="compile"> <description> login.flow </description> <property file="loginflow.properties"/> <path id="classpath"> <fileset dir="lib/"> <include name="*.jar" /> </fileset> </path> <target name="init"> <mkdir dir="${build}" /> <mkdir dir="${build}/WEB-INF/classes" /> </target> <target name="assemble-webapp" depends="init"> <copy todir="${build}" overwrite="y"> <fileset dir="${webapp-src}"> <include name="**/*/" /> </fileset> </copy> </target> <target name="compile" depends="assemble-webapp"> <javac srcdir="${src}" destdir="${build}/WEB-INF/classes"> <classpath refid="classpath" /> </javac> <echo>Copying resources</echo> <copy todir="${build}/WEB-INF/classes" overwrite="y"> <fileset dir="${resources}"> <include name="**/*/" /> </fileset> </copy> <echo>Copying libs</echo> <copy todir="${build}/WEB-INF/lib" overwrite="y"> <fileset dir="lib/"> <include name="*.jar" /> </fileset> </copy> </target> </project> First of all, we will specify that we have defined a few required folders in an external PROPERTIES file. The loginflow.properties, stored in your project's root folder, looks like this: src = src/main/java webapp-src = src/main/webapp resources = src/main/resources build = target/chapter02 These define the folders where your source code lies, where your libraries are located, and where to copy the compiled files and your resources. You do not have to declare them in a PROPERTIES file, but it makes re-using easier. Otherwise, you will have to write the folder names everywhere. This would make the build script hard to maintain if the folder layout changes. In the init target, we create the folders for the finished web application. The next is the assemble-webapp target, which depends on the init target. This means that if you execute the assemble-webapp target, the init target gets executed as well. This target will copy all the files belonging to your web application (such as the flow definition file and your JSP files) to the output folder. If you want to build your application, you will have to execute the compile target. It will initialize the output folder, copy everything your application needs to it, compile your Java source code, and copy the compiled files, along with the dependent libraries. If you want to use Apache Ivy for automatic dependency resolution, first, you have to download the distribution from http://ant.apache.org/ivy. This article refers to Version 2.0.0 Release Candidate 1 of Ivy. Unpack the ZIP file and put the ivy-2.0.0-rc1.jar file in your %ANT_HOME%lib folder. If you are using the Eclipse IDE, Ant is already built into the IDE. You can add the JAR file to its classpath by right-clicking on the task you want to execute and choosing Run As | Ant Build… In the appearing dialog, you can add the JAR file on the Classpath tab, either by clicking on Add JARs… and selecting a file from your workspace, or by selecting Add External JARs…, and looking for the file in your file system. Afterwards, you just have to tell Ant to load the required libraries automatically by modifying your build script. We have highlighted the important changes (to be made in the XML file) in the following source code: <project name="login.flow" default="compile"> ... <target name="resolve" description="--> retrieve dependencies with ivy"> <ivy:retrieve /> </target> ... </project> The last step, before we can actually build the project, involves specifying which libraries you want Ivy to download automatically. Therefore, we will now have to compose an ivy.xml file, stored in your project's root folder, which looks like this: <ivy-module version="2.0"> <info organisation="com.webflow2book" module="login.flow"/> <dependencies> <dependency org="org.springframework.webflow" name="org.springframework.binding" rev="2.0.5.RELEASE" /> <dependency org="org.springframework.webflow" name="org.springframework.js" rev="2.0.5.RELEASE" /> <dependency org="org.springframework.webflow" name="org.springframework.webflow" rev="2.0.5.RELEASE" /> </dependencies> ... </ivy-module> To keep the example simple, we only showed the Spring Web Flow entries of the file we just mentioned. In order to be able to build your whole project with Apache Ivy, you will have to add all other required libraries to the file. The org attribute corresponds to the groupId tag from Maven, as does the name attribute with the artifactId tag. The rev attribute matches the version tag in your pom.xml. Maven Maven is a popular application build system published by the Apache Software Foundation. You can get a binary distribution and plenty of information from the project's web site at http://maven.apache.org. After you have downloaded and unpacked the binary distribution, you have to set the M2_HOME environment variable to point to the folder where you unpacked the files. Additionally, we recommend adding the folder %M2_HOME%bin (on Microsoft® Windows system) or $M2_HOME/bin (on Unix or Linux systems) to your PATH variable. Maven has a configuration file called settings.xml, which lies in the M2_HOMEconf folder. Usually, you do not edit this file, unless you want to define proxy settings (for example, when you are in a corporate network where you have to specify a proxy server to access the Internet), or want to add additional package repositories. There are several plug-ins for the most popular IDEs around, which make working with Maven a lot easier than just using the command line. If you do not want to use a plug-in, you have to at least know that Maven requires your projects to have a specific folder layout. The default folder layout looks like this: The root folder, directly below your projects folder, is the src folder. In the main folder, you have all your source files (src/main/java), additional configuration files, and other resources you need (src/main/resources), and all JSP and other files you need for your web application (src/main/webapp). The test folder can have the same layout, but is used for all your test cases. Please see the project's website for more information on the folder layout. To actually build a project with Maven, you need a configuration file for your project. This file is always saved as pom.xml, and lies in the root folder of your project. The pom.xml for our example is too long to be included in this article. Nevertheless, we want to show you the basic layout. You can get the complete file from the code bundle uploaded on http://www.packtpub.com/files/code/5425_Code.zip. <project xsi_schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.webflow2book</groupId> <artifactId>chapter02</artifactId> <packaging>war</packaging> <version>0.0.1-SNAPSHOT</version> <name>chapter02 Maven Webapp</name> <url>http://maven.apache.org</url> This is a standard file header where you can define the name and version of your project. Further, you can also specify how your project is supposed to be packaged. As we wanted to build a web application, we used the war option. Next, we can de?ne all the dependencies our project has to the external libraries: <dependencies> <dependency> <groupId>org.springframework.webflow</groupId> <artifactId>org.springframework.binding</artifactId> <version>2.0.5.RELEASE</version> </dependency> <dependency> <groupId>org.springframework.webflow</groupId> <artifactId>org.springframework.js</artifactId> <version>2.0.5.RELEASE</version> </dependency> <dependency> <groupId>org.springframework.webflow</groupId> <artifactId>org.springframework.webflow</artifactId> <version>2.0.5.RELEASE</version> </dependency> ... </dependencies> As you can see, defining a dependency is pretty straightforward. If you are using an IDE plug-in, the IDE can do most of this for you. To build the application, you can either use an IDE or open a command-line window and type commands that trigger the build. To build our example, we can enter the projects folder and type: mvn clean compile war:exploded This cleans up the target folder, compiles the source files, and compiles all necessary files for our web application in the target folder. If you use Tomcat, you can point your context docBase to the target folder. The application will be automatically deployed on the startup of Tomcat, and you can test your application.