How-To Tutorials

What is a file type? Let's not go as far deep as "What is a file?", but before we start, let's take a look at file types. File types are determined by the contents of the files themselves, and are used to allow the opening program to be chosen wisely. In Microsoft Windows, file extension globbing is the sole method of identifying file types. Users must provide a common phrase at the end of files, and the files would be searched by their name, in turn providing the correct icon and program. Things are a little different in Ubuntu. Of course, globbing (the most basic method) is present for file types, but Ubuntu has a few other tricks up its sleeve. One of these is magic numbers. The magic number of a binary file is the first few bytes, which identify the file type. The definition of a "magic" number has somewhat loosened in recent years; it can now mean any piece of data, generally near the beginning of a file, that can be used to uniquely identify the type. Another, more powerful, but too rarely used feature, is XML namespace matching. Without this feature, all XML files wouldn't be able to be more specifically identified, with the exception of extension globbing, of course. Namespace matching allows for quick detection of a XML-based format based on not only the namespace, but also the root element. For example, XHTML files (application/xhtml+xml) can not only be matched by an xhtml file extension, but also by its namespace URI (http://www.w3.org/1999/xhtml) and its root element (html). How are file types detected? In Ubuntu, programs such as Nautilus use the shared-mime-database as the sole location for file type information. Unfortunately, other Gnome facilities such as file open and save dialogs only use extension globbing, and are independent from the MIME database. These databases are stored in a similar way to how programs can be located in four tiers, /bin, /usr/bin, /usr/local/bin and ~/bin. These databases can be found in the following directories: /usr/share/mime /usr/local/share/mime ~/.local/share/mime Like the program tiers, it is generally agreed that only MIME types installed from Ubuntu packages should be located in the first level. System-wide changes by the user or programs installed via make install are placed in the second tier, while changes local to the user are in the third. The directories inside these MIME databases represent MIME groups, for example ./video for video/* MIME types, and ./application for application/* types. Not all of these directories may exist; they'll be created on demand for file types. In these directories, there are multiple XML files, each named by their MIME suffix. They contain nodes with information about magic numbers, extension globs, parent types, child and alias types, and the file type description (often in multiple languages). The update-mime-database command, invoked manually or as a trigger opened when packages are changed, draws upon the information in these files and turns them into fast-seeking formats that aren't as friendly as XML. These real databases are in the following files: aliases: alternate names for MIME types generic-icons: system icons to be used for files globs: extension globbing without priority values (deprecated) globs2: extension globbing with priority values (current) icons: custom icons for odd file types magic: magic number database mime.cache: master cache with the entire database subclasses: child file types treemagic: detection of directory structures types: a list of MIME types XMLnamespaces: detection through XML namespaces and elements A long time ago, when I was learning about the MIME database, I used Bless to directly edit these files to create changes, but was always confused by my changes immediately disappearing. This is because the information is converted one way from the XML files to the cache files. The structure of the XML files Before we use programs to modify the MIME database for convenience, here's a quick breakdown of the format of the XML files in the database. The root element is mime-info, with the shared MIME info namespace: <mime-info /> This root element contains any number of mime-type nodes, providing detection information about a file type. You could even have an empty mime-info node, but that isn't productive at all. The following are a selection of the most important elements that can be found in mime-type nodes: glob nodes with a simple wildcard glob in a pattern attribute. A weight attribute from 0 to 100 is optional, and defaults to 50: <glob pattern="*.mkv" weight="55"/> glob-deleteall and magic-deleteall nodes, which clear any cascading of globs or magic numbers from previously parsed files and starts afresh magic nodes with an optional priority attribute from 0 to 100 (again defaulting to 50). These contain match nodes, which define rules for matching using magic numbers. These are the attributes to be used with match elements: type: one of string, host16, host32, big16, big32, little16, little32 or byte offset: where to check for the magic, using a single numeric offset or a range notated start:end value: the value to match with (numeric for any type other than string) mask: an optional attribute, this can be used for more detailed matches by running a bitwise AND on the potential match before testing. The value is either numeric (in the type specified) or strings, which are hexadecimal values all starting with 0x <magic priority="60"> <match type="string" offset="0" value="DVDVIDEO"></magic> alias nodes, with a type attribute specifying alternate or deprecated MIME types that are equivalent <alias type="video/x-matroska-mkv"/> sub-class-of nodes, with a type attribute specifying the parent MIME type comment, acronym and expanded-acronym nodes that help describe the file type to people; xml:lang attributes can be used to distinguish language root-XML elements which determine types using XML namespaces have namespaceURI and localName (root element) attributes Here's an example XML source file that uses a couple of these features (this file type is bogus, I just created it for the example): <mime-info > <mime-type> <comment xml_lang="en-AU">DML source document</comment> <acronym>DML</acronym> <expanded-acronym xml_lang="en-AU">Delan's Markup Language</expanded-acronym> <sub-class-of type="application/xml"/> <glob-deleteall/> <glob pattern="*.dml"/> <root-XML namespaceURI="http://azabani.com/dml" localName="dml"/> </mime-type></mime-info> Assogiate: a GUI editor for the Gnome MIME database Assogiate is a neat little program that allows you to create and modify file types, modifying the database in a very user-friendly and quick way. It can access the user database, ~/.local/share/mime, or the system override database, /usr/local/share/mime. Changes are not, however, placed in XML files with the file name structure of the MIME type, instead they are placed in ./packages/Override.xml allowing for a memory of the user-changed file types. Assogiate can be found in the Ubuntu universe repository: sudo apt-get install assogiate In the case that it is not, you can download and compile it: curl http://azabani.com/files/apps/assogiate-0.2.1.tar.gz | tar xvzcd assogiate-0.2.1; ./configure; make; sudo make install You aren't allowed to change the system override database without running the program as a privileged user, so always run it as root: gksu assogiate In the Assogiate window, you can use the toolbar buttons to add and modify selected file types, remove and revert changes, or search for file types. The left pane allows you to narrow your view to groups of MIME types, or user modified types. Adding and editing file types The process for these two actions is very similar. When you are in the Edit Type dialog, you can edit canonical information, alias and parent types, globbing, magic numbers and XML namespace matching each in its own tab.

Understanding DotNetNuke roles and role groups We just discussed how to add a user to your site. But are all users created equal? To understand how users are allowed to interact with the portal, we will need to take a look at what a role is and how it factors into the portal. There are plenty of real-world examples of roles we can look at. A police station, for example, can have sergeants, patrol cops, and detectives, and with each position come different responsibilities and privileges. In a police station, there are multiple people filling those positions (roles) with each of those belonging to the same position (role) sharing the same set of responsibilities and privileges. Roles in our portal work the same way. Roles are set up to divide the responsibilities needed to run your portal, as well as to provide different content to different groups of users of your portal. We want our portal to be easy for the administrators to manage. To do this, we will need to settle on the different user roles needed for our site. To determine this, we first need to decide on the different types of users who will access the portal. We will detail these user types in the following list: Administrator: The administrators will have very high security. They will be able to modify, delete, or move anything on the site. They will be able to add and delete users and control all security settings. (This role comes built-in with DotNetNuke.) The default administrator account is created during the creation of the portal. Home Page Admin: The home page admins will have the ability to modify only the information on the home page. They will be responsible for changing what users see when they first access your site. (We will be adding this role.) Forum Admin: The forum moderators will have the ability to monitor and modify posts in your forum. They will have the ability to approve or disapprove messages posted. (We will be adding this role.) Registered User: The registered users will be able to post messages in the forum and be able to access sections of the site set aside for registered users only. (This role comes built into DotNetNuke; however, we would need to provide the proper permissions to this role to perform the mentioned tasks.) Unauthenticated User: The unauthenticated user is the most basic of all the user types. Any person browsing your site will fall under this category, until they have successfully logged in to the site. This user type will be able to browse certain sections of your portal, but will be restricted from posting in the forum and will not be allowed in the Registered Users Only section. (This role comes built into DotNetNuke; however, we would need to provide the proper permissions to this role to perform the mentioned tasks.) Once you formulate the different user roles that will access the site, you will need to re strict users' access. For example, we only want the Home Page Admin to be able to edit items on the home page. To accomplish this, DotNetNuke uses role-based security. Role-based security allows you to give access to portions of your website based on what role the user belongs to. User-based security is also available per page or content section of the portal. However, the benefit of using a role-based security method is that you only have to define the access privileges for a role once. Then you just need to add users to that role and they will possess the privileges that the role defines. The following diagram gives you an idea of how this works: Looking at the diagram, we notice two things: Users can be assigned to more than one role More than one user can be assigned to a single role This gives us great flexibility when deciding on the authorization that users will possess in our portal. To create the roles we have detailed, sign in with an administrator account, and select ADMIN | Security Roles on the main menu or click the Roles link in the Common Tasks section of the control panel. This is available on the top of every DNN page for authorized users. You might need to click the double down arrows on the top-right of the page to maximize the panel. The Security Roles page appears as shown in the following screenshot: Notice that DotNetNuke comes with three roles already built into the system: the Administrators role (which we have been using), the Registered Users role, and the Subscribers role. Before we jump right into creating the role, let us first discuss the role group feature of DotNetNuke, as we will be using this feature when we create our roles. A role group is a collection of roles used, mainly, in large sites with a large number of roles, as a way of managing the roles more effectively. For the site we are building, the benefit of using role groups will be minimal. However, in order to demonstrate how to use them, we will create one for our administrative roles. While on the Security Roles page, click the Add New Role Group link located below the list of roles. This will present us with the Edit Role Group page containing two form fields. Once these fields are filled out, click the Update link at the bottom of this page. A Filer By Role Group drop-down list should now be displayed above the list of roles on the Security Roles page. If you select the Administrative Roles group that we just created, two noticeable things happen on this page. Firstly, the list of roles become empty as no roles are currently assigned to this role group. Secondly, an edit (pencil) icon and a delete (red cross X) icon now appear next to the drop-down list. These icons can be used to update or remove any custom role groups that exist on the site. These red 'X' icons are standard icons used throughout DotNetNuke to represent the ability to delete/remove items. Now that we have created our role group, we want to create the role for Home Page Admin. To do this, you again have two choices. Either select Add New Role from the dropdown in the upper left, or click on the Add New Role link. This will bring up the Edit Security Roles page, as shown in the next screenshot. We will use this page to create the Home Page Admin role that we need. The Basic Settings shown in the screenshot are as follows: Role Name: Make the name of your role short, but descriptive. The name should attempt to convey its purpose. Description: Here you may detail the responsibilities of the role. Role Group: Set this field to the Administrative Roles group that we created earlier. Public Role: Checking this will give registered users of your site the ability to sign up for this role themselves. We will be creating a Newsletter role and will demonstrate how this works when it is created. Auto Assignment: If this is checked, users will automatically be assigned to this role as soon as they register for your portal. CAUTION Do not check the Public Role and Auto Assignment checkboxes, unless you are sure. Checking these options would allow all users of the site to become members of the associated role, which would grant them the privileges assigned to the role. As we want to decide who will be able to modify our home page, we will leave both of these unchecked. To save the settings, click on the Update link. The Advanced Settings section allows you to set up a fee for certain security roles. We will not be configuring any of these settings for this particular exercise. However, we will briefly discuss how these settings can be used in Assigning security roles to users section. Now to complete the roles that we will require for Coffee Connections, we will add two more security roles The first role will be called Newsletter. We will be using this role to allow users to sign up for the newsletter we will be hosting at the Coffee Connections site. Set up the security role with the following information: Role Name: Newsletter Description: Allows users to register for the Coffee Connections Newsletter Role Group: Leave this as the default < Global Roles > as it is not going to be used to grant administrative rights to its members Public Role: Yes (checked) Auto Assignment: No (unchecked) Click on the Update link to save this role. The second role will be called Forum Admin. We will be using this role to administer the forums at the Coffee Connections site. Set up the security role with the following information: Role Name: Forum Admin Description: Allows user to administer Coffee Connections Forum Role Group: Administrative Roles Public Role: No (unchecked) Auto Assignment: No (unchecked)

Time for action – downloading and Installing VirtualBox on Linux Ok, for this exercise you'll need a copy of Ubuntu Linux already installed on your PC. I chose Ubuntu because it's one of the friendliest Linux distributi ons available, as you will see in a moment. Before installing VirtualBox, you'll need to install two additional packages on your Ubuntu system. Open a terminal window (Applications | Accessories | Terminal), and type sudo apt-get update, followed by Enter. If Ubuntu asks for your administrative password, type it, and hit Enter to continue. Once the package list is updated, type sudo apt-get install dkms, and hit Enter; then type Y and hit Enter to install the DKMS package. The other package needed before you can install VirtualBox is build-essential. This package contains all the compiling tools VirtualBox needs to build the kernel module. Type sudo apt-get install build-essential, and hit Enter. Then type Y, and hit Enter again to conti nue. Wait for the $ prompt to show up again, type exit, and hit Enter to close the terminal window. Now you can proceed to install VirtualBox. Open the Synaptic Package Manager (System | Administration | Synaptic Package Manager), and select the Settings | Repositories option in the menu bar (if Ubuntu asks for your administrative password, type it, and press Enter to continue) : The Software Sources dialog will appear. Click on the Other (on earlier Ubuntu versions the name of this tab is Third-Party Software)and then on the Add+ button: Another dialog box will show up. Now type deb http://download.virtualbox.org/virtualbox/debian karmic non-free on the APT line field, and click on the Add Source button: If you're not using Ubuntu 9.10 Karmic Koala, then you'll need to change the APT line in the previous step. For example, if you're using Ubuntu 9.04 Jaunty Jackalope, replace the karmic part with jaunty. On the http://www.virtualbox.org/wiki/Linux_Downloads webpage, you'll find more information about installing VirtualBox on several Linux distributions and the APT line required for each Ubuntu distribution available. The third-party software source for VirtualBox will now show up on the list: Now open a terminal window (Applications | Accessories | Terminal), and type wget -q http://download.virtualbox.org/virtualbox/debian/sun_vbox.asc to download the Sun public key: Go back to the Synaptic Manager, select the Authentication tab, and click on the Import Key File button: The Import Key dialog will appear next. Select the sun_vbox.asc file you just downloaded, and click on the OK button to continue: The Sun public key for VirtualBox should now appear on the list: You can now delete the Sun public key file you downloaded earlier. Click on the Close button to return to the Synaptic Package Manager. If the Repositories Changed dialog shows up, select the Never show this message again checkbox, and click on Close to continue. Now click on the Synaptic Package Manager's Reload button to update your package sources with the most recent VirtualBox version: Once the Synaptic Package Manager finishes updating the package sources list, click on the Origin button located at the lower-left part of the window and select the download.virtualbox.org/non-free repository from the window above this button: Click on the most recent virtualbox-3.X package checkbox in the right window, and select the Mark for Installation option: When upgrading to a newer VirtualBox version, you must first completely remove the older version. Then you'll be able to install the newest version without any hassles. The Mark additional required changes? dialog box will appear next. Click on the Mark button to mark all the additional packages required to install VirtualBox: Now click on the Apply button in the Synaptic Package Manager: The Apply the following changes? dialog box will appear next. Make sure the Download package files only option is deselected, and click on the Apply button to start installing the required packages, along with VirtualBox: The Synaptic Package Manager will start downloading the required packages and, when finished, it will install them along with VirtualBox.

One of the most important aspects of running a DotNetNuke portal is trying to figure out how to administer the portal. From adding modules to working with users, it may take a while before you have mastered all the administration tasks associated with running a portal. DotNetNuke uses a few terms that may be unfamiliar at first. For example, the term "portal" can be used interchangeably with the more common term "site". Similarly, the terms "tab" and "page" may be used interchangeably within the context of DotNetNuke. Knowing that they are interchangeable will help to understand the topics that we will discuss. User accounts If you are used to working within a network environment, or have worked with different portals in the past, then you are probably comfortable with the term "users". For those of us who may not be very familiar with this term, can think of a website that you have registered with in the past. When the registration had been completed, a user account was provided to you. This account lets you return to the site and log in as a recognized user. Everything that takes place on your portal revolves around users and user accounts. Whether users are required to register in order to use your services (such as a member site) or only a few user accounts are required to manage the content, functionality, and layout of your site, you will need to understand how to create and manage user accounts. Let's start with a general description of a user, and then you will see how to create and manage your users. In order to work through the examples, you will need to bring up your portal and sign in as an administrator account, such as the one created during the initial portal installation. Who is a user? The simplest definition of a user is an individual who consumes the services that your portal provides. However, a user can take on many different roles, from a visitor who is just browsing (unregistered user) or a person who registers to gain access to your services (registered user), to a specialized member of the site such as a content editor, to the facilitator (administrator or host) who is responsible for the content, functionality, and design of your portal. The difference between an administrator account and a host (or super user) account will be explained later in detail. For now, we will focus on the administrator account that is associated with a single portal. Everything in DotNetNuke revolves around the user, so before we can do anything else, we need to learn a little about user accounts. Creating user accounts Creating user accounts Before you create user accounts, you should decide and configure how users will be able to register on the site. You can choose from the following four different types of registrations: None Private Public (default) Verified To set the registration type for your portal, go to the Site Settings link found in the ADMIN menu, as shown in the following screenshot: The User Registration section can be found under Advanced Settings | Security Settings, as shown in the next screenshot: Many sections within DotNetNuke may be collapsed or hidden by default. To view these sections, you will need to expand them by clicking the '+' in front of them. The type of registration you use depends on how you will be using your portal. The following table gives a brief explanation of the different User Registration types: Registration setting Description None Setting the user registration as None will remove the Register link from your portal. In this mode, users can only be added by the administrator or host users. Thanks to the new features in DotNetNuke 5, users who have been given the proper permissions can also manage user accounts. This allows the administrator or host users to delegate account management to other individuals with the proper access. If you plan to have all sections of your site available to everyone (including unregistered users), then selecting None as your registration option is a good choice. Private If you select Private, then the Register link will reappear. After users fi ll out the registration form, they will be informed that their request for registration will be reviewed by the administrator. The administrator will decide whom to give access to the site. Unless an administrator approves (authorizes in DNN terms) a user, they will not be able to log in. Public Public is the default registration for a DotNetNuke portal. When this is selected, the users will be able to register for yoursite by entering the required information. Once the registration form is fi lled out, they will be given access to the site and can log in without requiring any action on the part of an administrator. Verified If you select Verified as your registration option, then the users will be sent an e-mail with a verifi cation code, once they fi ll out the required information. This ensures that the e-mail address they enter in the registration process is valid. The fi rst time they sign in, they will be prompted for the verifi cation code. Alternatively, they can click on the Verification link in the e-mail sent to them. After they have been verifi ed, they will need to type in only their login name and password to gain access to the site. Please note that proper SMTP confi guration is required to ensure delivery of the verifi cation e-mails. Setting required registration fields The administrator has the ability to decide what information the user will be required to enter when registering. If you are logged in as an administrator, then you can accomplish this through a combination of User Settings and Profile Properties. A user who is given the appropriate permissions can also modify these settings; however, this requires a few additional configuration steps that we will not cover in this section. To manage the Profile Properties for your site, select the ADMIN | User Accounts link. The User Accounts section appears as shown in the following screenshot: In the preceding screen, select Manage Profile Properties, either by selecting the link at the bottom of the module container or by selecting the link in the Action menu—the menu that pops up when you point on the drop-down button adjacent to the module title, User Accounts (more information on Action menu is provided later). When you select this link, you will be redirected to a screen (see the next screenshot) that displays a list of the currently configured Profile Properties. You can manage some attributes of the Profile Properties from within this screen. For instance, you can delete a property by clicking on the 'X' icon in the second column. Alternatively, you can change the display order of the properties by clicking on one of the Dn or Up icons in the third and fourth columns. If you change the order this way, make sure you click the Apply Changes button at the bottom of the page to save any changes. Your changes will be lost if you leave this screen without clicking the Apply Changes button. If you want even more control, then you can edit a single property by clicking on the pencil icon in the first column. You will see this icon extensively in the DNN user interface. It allows you to Edit/Modify the item it is associated with. You can also add a new property by selecting the Add New Profile Property action from the Action menu. In either case, you will be redirected to another page, where you can enter information about the property. You will be redirected to the Add New Property Details page, as shown in the following screenshot: Note that if you are editing an existing property, the Property Name field cannot be changed, so make sure you get it right the first time. If you need to change the Property Name, then you will need to delete and recreate the property. Most of these fields are self explanatory, but we will describe a few of these fields.

After a quick look at the file and folder structure of a module, we then begin creating a new module for PHP-Nuke. This module will allow items of content to be submitted for modules that do not support user-submitted content. In this article, we will code functionality for users to submit encyclopedia entries for administrator approval. However, this will not involve making any modifications to the Encyclopedia module, and can be extended to cover other modules as well. What Happens When a Page is Requested? Let's see what happens when a visitor wants to view an article on the site, and the process that PHP-Nuke goes through to construct the page containing this information. Viewing an article means that the visitor will be navigating to a page similar to this: http://localhost/nuke/modules.php?name=News&file=article&sid=1 The page requested by the visitor is modules.php, so let's have a look at that. Note that although there are many PHP files in the PHP-Nuke installation, there are only four files actually requested in the normal course of interaction with the site: index.php modules.php admin.php backend.php The other files in the PHP-Nuke installation are used by these files when required. Where Does PHP-Nuke Get Information From? PHP-Nuke is able to collect information about what module the visitor wants to see, what operation they want to perform, and details of the user from request variables coming from these places: The query string in the URL: The URL of the page holds information that tells PHP-Nuke which module to select, which part of the module to use, what item of content to show, and so on. The query string information is used to select the page from the system that needs to be shown to the visitor. Posted variables: When a user enters information in a form, and submits this back to the server, this information will be available to PHP-Nuke. This posted information is how PHP-Nuke gets input from the user to create items of content, enter terms to search for, and so on. Cookie variables: There is user account information stored in a cookie (and administrator account information if the user has such an account). This is used to identify the user, so they do not have to keep logging on every time they view a page or come to the site. When the user logs out, this information is deleted from the cookie. The information that PHP-Nuke gets from these sources has to be treated very carefully within the system. These sources are the only means through which visitors communicate with the site, and are also the channels through which hacks or attacks might be conducted on the site. The patches we applied in Article 2 while installing the system address precisely this issue, and they make sure that the data PHP-Nuke collects from a visitor is in exactly the right form for working with. Requesting a Page Once the modules.php page is requested, the first step followed is to include the mainfile.php file. This file does the following things: It checks and processes the request variables (namely the input to the application), to avoid possibly harmful tags, or other indicators of some form of SQL injection attack. It creates global variables for each request variable. It sets up a connection to the database. It gets the site configuration such as the site name, site logo, and so on, from the database. The mainfile.php file also contains a number of core functions such as checking if the user is logged in or is an administrator, choosing the blocks to display, and filtering text, among others. These will be used at different points in the creation of the page. After this file has been included, the next thing to happen in modules.php is that PHP-Nuke gets the requested module from the $name global variable, which corresponds to the name query string variable (as in modules.php?name=News), and checks if this module is active. If the module isn't active, and the visitor isn't an administrator, a 'Module Not Active' message is displayed, and the page output is done. If the module is active, then PHP-Nuke checks if the visitor has rights to access this module. PHP-Nuke checks to see if the access is restricted to a particular user group, and if so, is the user a member of that group? PHP-Nuke also checks if the module is for subscribers only, and if so, is the user a subscriber to the site? If the visitor doesn't have the right permissions to view the module, then a 'No Access' message is displayed, and the page output is done. If the module selected by the visitor is active, and they do have permission to view it, then PHP-Nuke can get on with passing control to that module. Control is passed to the selected module by attempting to include the index.php file in the folder of the selected module. However, if there is a file variable in the query string, then the file with that name is included instead. If these files can't be found, a 'Module Cannot Be Found' error is displayed to the visitor. Thus if the user requests a page like modules.php?name=News&file=article&sid=1, the article.php file in the News folder will be included by PHP-Nuke. If the user requests a page like modules.php?name=News&sid=1, then the index.php file in the News folder will be included. Attempting to request a page like modules.php?name=News&file=nosuchfile returns a page with a 'No such page' message, since there is no file called nosuchfile.php in the News folder. The 'No such page' message is generated by PHP-Nuke, since it's in control of the process. If the user has selected an active module for which they have view permission, and are requesting a page that is part of the module, then control passes to the module, and it's up to that module to do its work and create the page. We'll see how this works later in the article, but for now, our overview of how PHP-Nuke gets the page creation underway is complete. Seeing how PHP-Nuke works isn't particularly exciting, what is more exciting is seeing how we can extend the power of PHP-Nuke by creating new blocks and modules. Along the way, we'll see most of the components required for 'programming' with PHP-Nuke, and you'll get a good idea of how to go about your own development projects. Creating a Block Our development efforts begin with creating a File block. A File block is a PHP script that is stored in the blocks folder. It must have a filename of the form block-NAME.php, where NAME will be used by PHP-Nuke as the title for the block. The filename should not contain any spaces. The goal of a block is simple. It just has to create one variable, $content, that holds the content of the block. After that, the PHP-Nuke core will bring the theme into play to take care of displaying the block. The block we will create is a better version of the Dinosaur of the Day static HTML block we created in Article 4. The block will display the name of the Dinosaur of the Day, and a thumbnail image of the lucky lizard. However, on the next day, a different dinosaur will be chosen, and the block display will be updated. This is how the block works: We will create a database table to hold the date, the title of the dinosaur for that day, and a link to the thumbnail image of that dinosaur. We will create a text data file that will contain the name of a dinosaur and a link to its thumbnail image on each line. The data in this file will be the dinosaur pool from which the dinosaur of the day is chosen at random. When the block code is executed, it will look in the database table to see if there is any information for the current date. If there is, it will retrieve it and build the block output. If there is no information for the current date, the data from the text file will be loaded in. One of the entries in that file will be selected at random, and that data will be inserted into the database. This will become the Dinosaur of the Day. That data will then be used to create the block output. We will use the text file to hold the 'Dinosaur of the Day' candidates rather than a database table so that we do not have to create a separate administration feature to add these details. To add more dinosaurs to the list, we simply upload a new version of the text file. Make sure that you copy the dinosaur thumbnails from the code download into the imagesdinosaurstnails folder of your PHP-Nuke installation root. Time For Action—Creating the Database Table Open up phpMyAdmin in your web browser, and select the nuke database from the drop-down list in the left-hand panel. Click on the SQL tab, and enter the following code into the textbox, then click on Go. CREATE TABLE dinop_dinoportal_dotd (id INT( 10 ) NOT NULL AUTO_INCREMENT ,day VARCHAR( 16 ) NOT NULL ,title VARCHAR( 128 ) NOT NULL ,image VARCHAR( 250 ) NOT NULL ,PRIMARY KEY ( 'id' )) TYPE = MYISAM ; What Just Happened? We just created our database table. There is only one table needed, with a simple design. There are four fields in the table. The id field will hold an auto-incrementing unique numerical value and the other fields will hold the current date, the title of the dinosaur, and the link to the image of the dinosaur. Time For Action—Creating the Text File Open up your text editor, and enter the following: Tyrannosaurus Rex,images/dinosaurs/tnails/tyro.gifStegosaurus,images/dinosaurs/tnails/stego.gifTriceratops,images/dinosaurs/tnails/triceratops.gif Save this file as dotd_list.txt in the blocks folder. What Just Happened? The dotd_list.txt file will be the data source for choosing a new Dinosaur of the Day image. You will notice that we are storing the data here in the form 'name of the dinosaur', 'path to the image', so it will be easy to extract the information when we need it. Time For Action—Creating the Block Code Open up your text editor, and enter the following code into a blank file: <?phpif ( !defined('BLOCK_FILE') ){ Header("Location: ../index.php"); die();}global $prefix, $db;$today = date('d-m-Y');$sql = "SELECT * from ".$prefix."_dinoportal_dotd WHERE day='$today'";$result = $db->sql_query($sql);$content = "";$dino_title = "";$image = ""; $numrows = $db->sql_numrows($result); if ($numrows) { $row = $db->sql_fetchrow($result); $dino_title = $row['title']; $image = $row['image']; } else { $filename = "blocks/dotd_list.txt"; $possibles =@ file($filename); if ($possibles) { $choice = rand(1, count($possibles)); $imp = explode("," , $possibles[$choice-1]); $dino_title = $imp[0]; $image = $imp[1]; $sql = "INSERT INTO ".$prefix."_dinoportal_dotd(day,title,image) VALUES ('$today', '$dino_title', '$image')"; $result = $db->sql_query($sql); } $choice = rand(1, count($possibles)); $imp = explode("," , $possibles[$choice-1]); $dino_title = $imp[0]; $image = $imp[1]; }if ($dino_title){ $content = "Today's dinosaur is:<br><center><b>$dino_title</b><center><br>"; $content .= "<center><img src="$image" alt="$dino_title"></center><br>";}?> Save this file as block-DinosaurOfTheDay.php in the blocks folder of your PHP-Nuke installation. What Just Happened? We just entered the code for the Dinosaur of the Day block, and we'll step through it now. This first part of the code stops this file being requested directly by a visitor— the BLOCK_FILE constant is defined in mainfile.php, and without that constant being defined, the visitor would be redirected back to the homepage of the site. Block files are never requested directly by the visitor, they are included by PHP-Nuke. These first few lines of code are found in every block file: if ( !defined('BLOCK_FILE') ){ Header("Location: ../index.php"); die();} Now we can get started. First, we set ourselves to access some of the global variables of the application, and we will have our first look at the objects to access data from the database. The only global variables we need here are the ones for data access—$prefix, which holds the value of the database tables prefix, and $db, which is used to actually perform database operations. global $prefix, $db; Next, we grab today's date, formatted as digits like this 24-05-2005. $today = date('d-m-Y'); Now we set up the SQL statement to retrieve the information corresponding to this date from the database: $sql = "SELECT * from ".$prefix."_dinoportal_dotd WHERE day='$today'"; Now we execute the SQL statement: $result = $db->sql_query($sql); It is possible that there is no data corresponding to today's date, so we check the number of rows returned from this last query. If there are zero rows, there will be no information. $numrows = $db->sql_numrows($result); If there are some rows returned, we can start creating the block output. We use the sql_fetchrow() method to retrieve a row of data from the result of the query. This row is returned as an array, and we set some variables from the array. We'll only grab one row. If for some reason, there is more than one entry for today's date, we simply ignore the others. if ($numrows){ $row = $db->sql_fetchrow($result); $dino_title = $row['title']; $image = $row['image'];} Now we move on to the situation where there is no information for today's date, and we have to create it. The first thing we do is to read the contents of the dotd_list.txt file into an array—there will be one entry in the array for each line in the text file. However, we have to consider what will happen if there is some kind of problem reading the file. else{ $filename = "blocks/dotd_list.txt"; Note that the path to the file for the dodt_list.txt file is blocksdotd_list.txt. This may seem strange, since both this file and the block file are in the same blocks folder. However, PHP will be looking for this file from the executing script, which will be one of index.php, modules.php, or admin.php, all of which are outside the blocks folder. Thus we need to add the blocks folder in the path to the dotd_list.txt file. Now we try to grab the file itself: $possibles =@ file($filename); The file function opens the named file, and reads the input into an array called $possibles. The use of the @ character here will suppress any error messages—if there is a problem opening or reading the file, no untidy error messages will be displayed to the user, and execution can continue. Of course, if there is a problem reading the file then there will be a problem with $possibles. So we check this next—if there has been some problem reading the file then $possibles will be false: if ($possibles){ If there is something stored in $possibles, then this check will be passed, and we can proceed to choose one element from it at random. We choose a random number, between 1 and the number of lines in the text file. $choice = rand(1, count($possibles)); All we have to do now is choose that element from the array (we have to subtract one from the random number because the first element of the array is 0, rather than 1), and then split up that line to get at the title and the path to the image. $imp = explode("," , $possibles[$choice-1]);$dino_title = $imp[0];$image = $imp[1]; We split the line using the explode() function. The explode() function converts a string to an array by splitting it at certain characters. We will split the string at the ',' character, and we get an array with two entries. The first entry is the name of the dinosaur; the second is the path of the image. Now we have the details of our Dinosaur of the Day, we can add it to the database using an INSERT SQL statement. $sql = "INSERT INTO ".$prefix."_dinoportal_dotd(day,title,image) VALUES ('$today', '$dino_title', '$image')"; $result = $db->sql_query($sql); }} At this point, we should have a Dinosaur of the Day, one way or another, and so we can finalize the block output. However, we check the value of the $dino_title variable just in case there has been some problem either retrieving data or creating the new Dinosaur of the Day. If there has been a problem with either of these, there will be no value for the $dino_title variable, and if so, this code will ensure that the block content will remain empty, rather than producing some useless output. if ($dino_title){ $content = "Today's dinosaur is:<br><center><b>$dino_title</b><center><br>"; $content .= "<center><img src="$image" alt="$dino_title"></center><br>";} That's it, our block is complete! The key points of this block were the initial few lines that stopped the file from being requested directly, and this was also our first encounter with the data access code. Another thing to note from this example is the effort we made to ensure that the block output was only created if everything went smoothly. We suppressed errors when trying to read in a file, we checked that the reading of a file had actually given us some data, and then we didn't create any output if there was a problem with dino_title variable, which would be an indicator of some problem. All this means that if there is a problem, the visitor will not be confronted with lots of error messages, which could disturb the visitor and lead to a poor impression of your site, or even break the layout of the page, or reveal some information about your code that could be used against you. All that remains now is to set up this File block using the steps we saw in Article 4, and we are away! Data Access in PHP-Nuke In the code for creating the block we had a couple of lines with data access functions: $result = $db->sql_query($sql);$numrows = $db->sql_numrows($result);$row = $db->sql_fetchrow($result); PHP-Nuke uses a 'data abstraction layer', which means that you call functions against an object, which translates them into specific calls against the database of your choice. Generally, MySQL is the database used with PHP-Nuke, but you could choose another database server to power your site. A more pertinent advantage is that you don't need to use database-specific functions to access data in PHP-Nuke; you only need to learn about the functions of the data access object (You will still need to know some SQL to create queries that will be executed on the database). The code for the data access object is found in the file dbmysql.php. In fact, the db folder contains code for different types of database server, but this file is the one selected by default by PHP-Nuke for working with the MySQL database server. The data access object is a genuine object, that is, it's an instance of a class, sql_db in this case. Classes are one of the basics of object-oriented programming, but other than this instance PHP-Nuke does not make much use of object-oriented programming. A discussion of object-oriented programming in PHP is beyond the scope of this article series, and it won't particularly help here since PHP-Nuke makes so little use of it. All that we need to know is how to access the methods (functions) of the data access object. Object-oriented programming is covered in more detail in any book on PHP programming, and you can read an article about it at http://www.devarticles.com/c/a/PHP/Object-Oriented-Programming-in-PHP/. The data-access object provides a number of methods that you can use to execute a query, retrieve a row of data, check the number of rows returned by the query, or get the last inserted auto-increment field. Working with the object follows a similar process to the standard way of working with data in PHP using functions like mysql_query() or mysql_fetch_field(). To access data in PHP-Nuke, you will need two global variables, $prefix and $db. The $prefix variable holds the table prefix of the database tables, and this needs to be used in your SQL queries. The $db variable is the data access object itself. In our block example, we had these lines to create a SQL query and then execute it: $sql = "SELECT * from ".$prefix."_dinoportal_dotd WHERE day='$today'";$result = $db->sql_query($sql); Note the $db->sql_query() syntax. This syntax is used in PHP to call a method on an object, in this case the sql_query() method of the $db object. The sql_query() method executes an SQL query as its name suggests. You provide a string with the query that's to be executed as a parameter. Following the execution of a query, you can retrieve a row using the sql_fetchrow() method: $row = $db->sql_fetchrow($result); This method returns an array, and you can refer to the fields in the data using $row['fieldname'], as we do in the block example to get the title and image fields: $dino_title = $row['title'];$image = $row['image']; If you want to insert or update data, you need to create the relevant SQL query and then use the sql_query() function to do it: $sql = "INSERT INTO ".$prefix."_dinoportal_dotd(day,title,image) VALUES ('$today', '$dino_title', '$image')";$result = $db->sql_query($sql); This is only a small selection of the methods of the data access object. Another interesting one is the sql_nextid() method, which you can use after an INSERT statement to get the value of the last auto-increment field created. However, these are the methods that you will see the most of as you look around the code in PHP-Nuke. Module File and Folder Structure Before we get started creating a new module, let's have a look at the file structure of a typical module. A module is simply a collection of files (usually only PHP files) contained in a folder that goes in the modules folder in the root of the PHP-Nuke installation. The name of the folder is the name that PHP-Nuke will recognize the module by. However, we can't just place the files into the module folder in any order. There is an organization of files, subfolder names, and filenames that modules need to follow in order to function properly with PHP-Nuke. The image below shows the contents of the News module folder: We have already seen how PHP-Nuke switches between files in the module folder based on the value of the file query string variable. If there is no value for this variable, the index.php file of the module is used. Files that sit inside the module folder are the 'front-end' files, which will be used during a standard user's visit to the module. The code for the administration part of a module resides in the admin folder within the module folder. In earlier versions of PHP-Nuke (before 7.5), the administration code for any module would have to go into the admin folder (the one in the root of the PHP-Nuke installation), and would be mixed with the 'core' administration code. The decision to have a module's administration code contained within the module folder itself means that the module is much more self-contained, keeps people away from the core code itself, and generally makes the module easier to set up, install, and maintain. We'll see more about what is found in the admin folder when we create the administration area of our new module later in this article. We saw in Article 4 that the Language block allows you to change PHP-Nuke's user interface language. This ability to switch languages is something that has made PHP-Nuke so popular all around the world. This multi-language support is achieved by module developers avoiding coding any 'localizable' text into the module output. Localizable text is text that needs to be translated if a different interface language is selected. Instead of coding the text, PHP constants are used, with the values of the constants defined in a language file. The language files are found in the language folder of the module, and there is a separate language file for each language, each with a filename of the form lang-LANGUAGE.php. All PHP-Nuke needs to do is select the correct file based on the desired language. Creating a User Submissions Module Writing a new module allows you to extend PHP-Nuke to get it to do exactly what you want it to do. What we will do here is to create a general-purpose module that will allow users to submit content for modules that do not support user-submitted material. We'll call it UserSubmissions. It will work in the way the Submit News module works for stories: The user will submit the material through a form. The administrator will be notified of the new submission by email. The administrator will be able to see a list of the submitted material in the administration area, and can edit, delete, or approve the material to go into the database. The point of this module is that it does not touch the modules for which it allows the submission of content; everything will happen in the UserSubmissions module. In this article, we will only code in functionality for users to submit encyclopedia entries. It is straightforward to extend this to allow submissions for the Content module, or questions for the FAQ module. Conceptually what the module does is to: Present a form to the user similar to the one the administrator would use for entering an encyclopedia entry. Take the user's input and store it in a 'general' way in a single database table. After the administrator checks the input, the data is then stored in the encyclopedia's database tables using the same kind of code that the Encyclopedia module uses. We will see exactly what the 'general' way we store the data in is later. Basically, the module will take all the parts of the encyclopedia entry—the title, the text, the encyclopedia ID—and put them all together into one bundle, which can then be easily retrieved and broken out to form the individual pieces of data for the administrator to view, approve, or delete. Rather than presenting the development as a series of steps for you to follow, we will break the code up into various tasks, and then examine each piece of code or activity. You can type in the code as it is presented, although it is probably easiest to grab the example code for this module from the code download, and refer to it as we go. Module Development Steps The steps that we will follow to create the module are these: Create the module folder Create the database tables Code the front end (visitor view) of the module Adapt the code for multi-language support Set up module administration Code the administration area Rather unusually, we're going to start by coding the front end of the site. The reason this is unusual is that modules typically display some kind of data (that is what all the modules we have encountered in the article series do), and you would first need to enter this data into the database. This data is usually entered by the administrator, through the administration interface. With some example data in place, the front end of the site will be able to display it. It will be difficult to test the front end if it is supposed to display data and there is no data to display! This module does not require any existing data in the database to work. In fact, the data is entered by a standard visitor, and the administrator only has to look at this data, and edit or delete it. There is no facility in the administrator part of the module for the administrator to add new data into the module, which would rather defeat the point of this module! Thus we can start on the front end of the module quite happily. Let's start off with creating the module folder. Creating the Module Folder Create a new folder in the modules folder called UserSubmissions. This will be our module folder. Within this folder, create two new folders called admin and language. The admin folder will contain our administration code, and the language folder will contain the user interface language files. We create another folder, inside the admin folder, also called language. This folder will hold the language files for the module's administration interface. That's the first step out of the way, so let's move on to the database tables. Creating the Database Tables The module has only one database table. The table will be called <prefix>_usersubmissions. You can follow the same steps in phpMyAdmin as we did earlier for creating the block database table to create this table: CREATE TABLE dinop_usersubmissions ( id int(11) NOT NULL auto_increment, data text NOT NULL, parent_id int(11) NOT NULL default '0', type varchar(36) NOT NULL default '1', user_id int(11) NOT NULL default '0', date timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, title varchar(255) NOT NULL default '', user_name varchar(250) NOT NULL default '', PRIMARY KEY (id)) COMMENT='Table for holding user submitted content' ; Each row in this table will represent a single item of submitted content. The row will be identified by its id field. With only one table, you may be wondering how this module is going to be able to hold data from different modules. The answer is that the submitted data will be bundled up into a single object, then 'serialized' and stored in the data field. When the data is needed for viewing, it will be unbundled, and 'unserialized' back into a form that can be worked with. The 'title' of the submission will be stored in the title field. The type of module that we are storing data for will be held in the type field of the row. The details of the submitter will be stored in the user_id and user_name fields. We actually only use the user_name field in this version of the module, but we store both for future use. The date the item is submitted is held in the field called date. This field is a MySQL TIMESTAMP, and whenever a row is inserted, the current date and time will be inserted into the field automatically by the database, so we will not need to record the date and time ourselves. The final field is parent_id. Recall how an encyclopedia entry belongs to an Encyclopedia; a content page belongs to a Content category; a FAQ question belongs to a particular category, and so on. For each of these types of content, you needed to provide a 'parent' object that the content would belong to. That is where our parent_id field comes in. The ID of the parent object will be stored in this field. For an encyclopedia entry, this will be the ID of the chosen Encyclopedia.

INTRODUCTION Underwater scenes are one of the most exciting, inspiring, and gorgeous environments in real life and computer graphics world alike. And with this awe-striking appearance comes a very complex array of possibilities. From a photographer’s point of view alone, underwater scenes seem to be one of the most challenging places and situations to be at, let alone the difficulty of acquiring a proper lighting and the satisfactory combination of shutter speeds and apertures. Same thing applies also to recreating such a scene in computer graphics, specifically in 3D. Throughout my career in 3D design and animation, I have never thought exactly how to approach an underwater scene not until I actually delved, sat down, and started thinking what approach to do. Fortunately, after hours of conceptualizing and imagining, I came with an approach, which might seem odd to others, but it works which. And that has been my primary motivation in writing this article and sharing my discoveries. Hopefully, this wouldn’t be too software-centric as compared to my previous articles, which I was trying very hard not to do. The concepts I will present throughout this entire writing will be based off from my own experiences and repeated mistakes. Since there are so many possibilities in approaching problems, hopefully you’ll find mine to be one of the simplest one. Let’s head on. REQUIREMENTS Blender 2.49b Skill Level: Intermediate to Advanced REFERENCES Below are some reference images I looked up at Google. These will be our starting point and our scene bases.       You’ll notice from the images above that underwater scenes could greatly vary depending on your location and on how deep you are. The shallower your location is, the darker it might get, and the more life there would be. But for now, we’ll focus on just the ambience of the scene and we’ll try as much as we could to imitate this. CREATING THE TERRAIN Now that we’re comfortable with our references and how our scene will faintly look like, let’s go ahead and start the actual creation of our environment. First, we have to create our terrain where our props and other models will be situated on. I had this on the first order so that we can pretty much see where and how our props which we are going to model later will look like or if we ever need them to be in the scene at all. Approaching it this way will give us more leeway on the proceeding steps we’ll do later on. For this environment, our terrain will simply be a subdivided smooth plane with varying elevations (as would have implied by water movement). To achieve this, first let’s delete whatever default scene elements we have (objects, lamps, etc.) by hovering our mouse pointer over to the 3D Viewport Window, pressing A once or twice (depending whether you have a selected object or not) to select all visible elements in your scene, and press X > Erase selected Object(s) or by pressing the Delete button on your keyboard. After this, we simply add a plane primitive mesh to the scene via spacebar > Add > Mesh > Plane or by clicking on Add > Mesh > Plane on the menu header. It’s a good idea to start adding objects in a hierarchical or orderly manner right from the start so we could easily keep track of our progress and solve problems that may arise later on. Erasing the Default Scene Objects Adding a Plane Primitive to the Scene   After adding the plane to our current scene, let’s go ahead and scale it a little bit larger just to give us an initial sense of scale and enough room to add our proceeding objects later. Do this by selecting the Plane Object (if it hasn’t been selected by default), then press S to scale and then type 5 consequently to scale it up by 5 Blender Units (BU) uniformly on the X, Y, and Z axis respectively. Or alternatively, you can use the Transform Toolbox (N) and type in 5 in the Scale X, Scale Y, and Scale Z input fields, better yet, to save time, enable the Link Scale button, and type 5 in either of the scale axes and the others will follow along. The Default Plane Added to the Scene     Scaling the Plane Object   To review, what we basically did was to add a mesh primitive to our scene, in this case a Plane, then to have enough room to work on, we scaled it five times its original size. Looking at the plane in the 3D space though, you might notice that it lacked thickness which is one of the key roles of the z-axis, so with this in mind, we could just scale it along the x and y axes, disregarding the z axis, which we can do by pressing Shift Z after executing the Scale operation. What this will do is scale it only in the other axes excluding z, which will result in the same appearance as scaling it in all axes. But for future reference and to eliminate ambiguities later on, it’s better to just scale it in all axes which is the default option after doing the scale command. Continuing from where we left off, we are now going to create more vertices from our existing plane, these vertices will be our manipulation points that will eventually define our object’s shape later on.

LIGHTING UP THE SCENE From the point we started our scene, we haven’t tried any test renders yet to see how our underwater environment looks and I know you’re all so eager to try and press that RENDER button (so am I), but let’s make sure that we don’t waste a second of our time by rendering something that’s not worth the button press at all. Let’s prepare our background or world (as Blender world) so our recently created objects could have something to lie on, not just blank void of utter nothingness. In our 3D Viewport, select your camera (which is in layer 5), and proceed to the Editing (F9) panel and under the Camera tab, click the Mist button. What we did was to enable our camera to view our mist distance, for use later in the next procedure. Next step, proceed to the Shading (F5) panel then to the World Buttons and under Mist/Stars/Physics tab, click the Mist button to enable it. As of this time, the Mist toggling we did doesn’t do anything great yet for our scene. Under the same tab, adjust the Start and Dist values accordingly, and then you’ll notice the changes take effect in your 3D Viewport via your camera. What mist does is it fades whatever objects are within its range into our world background. Enabling Mist Display   Mist Settings   After you’ve set your Mist settings, proceed to the tab right next to the current one we are in now, the Amb Occ tab. Click the Ambient Occlusion button and leave the other default settings as they were except for the diffuse energy settings which we’ll change to Sky Color and the type of Ambient Occlusion to use which we’ll change in the dropdown menu from Raytrace to Approximate. We told Blender to render out our scene with ambient occlusion which is basically a global illumination method (or something similar to it), creating a global environmental lighting and producing soft shadows due to object occlusion. I often do this to my scenes where I start out my lighting process by turning on AO (Ambient Occlusion) as my first pass and take it from there. Ambient Occlusion Settings   Now, the moment you have been waiting for, RENDER TIME! Probably, before you have even read this sentence here, you already pressed the F12 button or the RENDER button. If you didn’t, I guess you already know what to do which leads us to this image: First Render!   Pretty dark isn’t it? By default, if we had the Ambient Occlusion’s diffusion settings to Plain, which just uses a plain white occlusion color, this render would be brighter, but we would not achieve that dark blue distant color that we see right now. To fix this problem, or better said to tweak this better, we’ll add in lights, which is the primary reason of this part of this article. So why don’t we throw in some? The first light we’ll create is a spot lamp from directly above. We would have opted to have this step of the lighting in the last parts of our pass but we’re trying as much as possible to avoid resetting some settings later on. Add a spot lamp to our scene by moving your mouse pointer over to the 3D Window and pressing spacebar, choose Add > Lamp > Spot. Set the settings of lamp (as seen in the screenshot) such that it only affects our nearest terrain. Adding the Spot Lamp   Top Spot Lamp Settings   Again, let’s do a test render and see how everything looks like so far. Render with Top Spot Lamp   And finally, some light and recognition, but still a little bit dark, so however you want it, throw in some lights at the sides to kill the dark shadows. Experiment with the way you light the scene. Just for reference purposes, you can take a look at the screenshot below. Light Setup   Leading us to: With More Lights   Just for fun and more aesthetic appeal, we’ll create another light which will cast rays (popularly known as volumetric lighting) and produce caustics which we’ll see in the sand. Duplicate the top lamp and move it higher than the original spot lamp we duplicated it from and adjust the settings accordingly. Ray Spot Lamp   The key settings for this lamp are the halo and halo steps. Enabling Halo makes our spot lamp draw volumes of light and halo step enables us to block this volume to create nice looking shadows out of the volume. A halo step of 0 will not produce the shadows and non-zero values will enable us to achieve such, often, you can stay at levels of 5 which is a good compromise between the quality of shadows and speed but for this part, we’ll just choose 1 to achieve the smoothest shadows. Without anything to block out the volumetric light, it would look as though a beam from an alien spacecraft just swept through our scene. But we want smaller light streaks, so what we need to do is to create a mesh to block out the light and let the beam pass through the holes of the mesh (as seen in the screenshot). Commonly, this mesh is called the “gobo” or the pattern with which light passes through. Render with Light Beams   Now, on to the caustics. To those of you who haven’t heard about caustics before, they are the patterns you see on the floor of a pool or a shallow body of water. It is caused by the way light had been bent by the waves and distortions happening on the surface of the water. You can skip and just move on to the other one if you don’t wish to add caustics to your scene, but I highly suggest you not to since this is one of the most fun parts in creating the scene. It had been a tedious and long journey for me to discover about this technique in creating caustics and thought I might share it to those who haven’t found out a way yet. All credit goes to the Blender Artists forum and the creators of this great application that we’ll use shortly to create the caustic effect. If you’ll do a quick Google search and type in “caustics generator”, among the first few results you will see is the CausticsGenerator application (pretty repetitive, eh?). Or you could go directly to this site http://www.lysator.liu.se/~kand/caustics/ and find out about this wonderful application. Head over to their downloads section and grab a copy of the free version which is licensed under the GNU GPL or you could buy the commercial version. Under their readme file or about section, here’s a description of caustics: “Caustics can be described as the light pattern you see at the bottom of a pool on a sunny day. This tool will let you render such caustics patterns. The rendered images can be animated and used for realtime graphics and are tileable in both space and time.” After downloading the application, extract the zip file to your preferred directory, and inside that open the file CausticsGenerator.exe. You’ll be presented with lots of settings and sliders to play around it. I won’t hold you back to go ahead, play around with it, and have fun. The procedure I did to achieve the caustics effect for our scene is to just adjust the depth, resolution (width & height), supersampling, and the output file and render out an animation out of the settings I had. Caustics Generator Settings   That’s about it for our caustics and after successfully rendering out the animation, you can check the directory where you have the renders outputted and you can see a bunch of BMP images. These are what we’ll be using as image sequence textures for one of our lights back in Blender. Caustic Image Sequences Generated   Back to Blender, select the upper spot lamp casting the beams of light and go to Shading (F5) panel, then to the Lamp Buttons and scroll over until you see Texture and Input tab. Click Add New and name your texture “caustics” and use the View Coordinates. Under the Map To tab, select Shadows to have the caustics affect the shadows from the light as well (though in real life, this rarely happens). Adding a Texture to the Spot Lamp   Proceed to the textures button and change the texture type to Images. Browse through the folder where you saved the caustics images and just select the first image in the series and click load or middle mouse click the first file. Under the Image tab, click Sequence (to tell Blender that we’re not just using the single file we loaded but the whole sequence which comes with it), enable Auto Refresh, set the total number of frames, and click Cyclic to make the animation loop. Loading the Caustics Texture   If we render the scene now, here’s how it will look like with the caustics: Render with Caustics

ADDING VEGETATION Let’s leave the terrain as it is right now and make sure it is in layer one (just to keep things more organized). Then let’s select the camera and move it to layer five by pressing M then clicking the fifth layer or by pressing 5 on your keyboard. Activate layer two by pressing 2 on your numeric keys (not the Numpad). We will use this as our layer for our first group of seaweeds. Go to front view, add a new Bezier Curve, proceed to Edit Mode and follow the initial settings I have on the Editing Panel. Moving the Camera to Layer Five     Adding a Bezier Curve and its Settings   Let’s leave the curve settings for now and we’ll get back to them when necessary. What we have to do now is to rotate the curve such that we see the thicker part of the face in front view and the start point of the curve on the bottom portion. There are two easy ways to do this; either we rotate the curve on view at a time or we can type in values in the transform window, you can settle for either of the two. To make things quicker, I opt for the latter. With the curve currently active/selected, proceed to Object Mode (Tab), then bring up the Transform Window if it is not yet on your screen by pressing the N key while having your mouse pointer on the 3D Window. Afterwhich, using the Transform Window, let’s change the default name of the bezier curve from “Curve” to “Curve.Weed”, then change the rotation values for RotX and RotY accordingly, as seen in the following screenshot. Renaming and Rotating the Curve   Next comes the fun part: editing the curves and giving them the wavy forms they deserve. With the curve selected, go to Edit Mode (Tab), then for convenience purposes, we are going to disable the drawing of the curve handles. We do this by going to the Editing (F9) panel and under the Curve Tools1 tab, disable the Draw Handles button. Now if we select all the points in the curve, the handles that are usually there and are sometimes in the way are now hidden, and if you wanted to have more control over your curves, you can always turn them back on by simply enabling the same button we disabled awhile back. Right now though, we only have two points to work on our curve which is a bit limited. But don’t fret, because Blender’s curve tools are of its greatest assets and they won’t let us have it unless it’s good to use. With that said, we can solve the problem by selecting all curve points (pressing A twice), then press W to bring up the Specials Menu and choose Subdivide. You can also access the same function by going to the Editing (F9) panel and click the Subdivide button. You can repeat the same process to achieve more subdivisions on your curve, but I highly suggest you keep it as simple as you could, and only add points when needed. Another way you can add points to your curve is to select existing points then pressing the E key (as in extrude) which will automatically put you in grab mode and confirm location with your left mouse button. You can also select a point from the curve then press CTRL left mouse button which will add a new curve point to where your mouse pointer is. Subdividing the Curve   Now that you already have enough subdivisions to work on, you can manipulate the individual points the way you want to as shown in the screenshot below. Another cool thing with manipulating curves is the ability to tilt curve points along their own axes with ease. You can tilt points by selecting one or many points then pressing T or accessing it through the menu via Curve > Transform > Tilt.   Curve Shaped     Tilting Curve Points   After creating the shape of our sea weed, it’s time we convert it to a polygon for us to further edit and finalize the shape. Select the Curve in Object Mode, then press Alt C then choose Mesh (which should be the only option available from the pop-up menu). What this does is it converts our existing curve into a polygon mesh with editable points (similar to what the mesh primitives have). This way we can add more details to the weed. But first, we mush fix first one problem that our weed mesh has: a hole at the top. You can choose not to address this issue, but in order to avoid getting back and fixing some stuff later on, it’s better to do it now. When we rotate our view such that we see the top part of our weed, we can clearly see a cut through the mesh, let’s fix this by going to Edit Mode, selecting four neighboring vertices and create a face by pressing F or going to the menu then choosing Mesh > Faces > Make Edge/Face. While in edit mode, you can also occlude background vertices by clicking the button with the cube icon on your menu 3D Viewport menu. This might also be a good time to rename our object from Curve.Weed to Weed. Creating Faces     Faces Complete   Let’s exit Edit Mode and get back to Object Mode (Tab) and just give our weed a basic subsurface smoothing. With the object selected, you can press Ctrl 1 to add level 1 Subsurf to the weed or your can go to the Editing (F9) panel, and go to the Modifiers tab, click Add Modifier and choose Subsurf, then change the default Render Levels from 2 to 1 since we don’t need the extra count since they hardly differ in this case like ours. Adding Subsurf   However, you’ll notice that hardly any smoothing took place and it even revealed problems with our mesh. Don’t panic because this would just be an easy fix. Select the Weed Object and proceed to edit mode, select all vertices, then press W to access the Specials Menu and choose Remove Doubles. Removing Mesh Doubles   Next, after successfully applying subsurf to our weed object, we know scale down the top-most part to further make it more convincing and natural. While still in Edit Mode, select the top-most vertices then use the Proportional Editing tool with a Smooth Falloff and perform a scale (S) operation while controlling the radius of influence with your middle mouse wheel. Using the Proportional Editing Tool for Scaling   After performing the proportional scaling, it should look something like this Weed Shape   Next, we add in just an initial material to distinguish it from other objects we’ll create later on. Weed Initial Material Settings   Hardly do we see weeds by their own, as singular leaves with no nearby leaves, unless it’s artificially setup. To add more weeds as group, we simply duplicate the weed we have now and edit the duplicates accordingly. Group of Weeds   Next up, we “group” the weeds using Blender’s grouping function. We do this by first selecting the objects we want to be included in the group, in this case, the weeds. After we’ve selected the weeds, let’s split our 3D view and make our left view an Outliner (by clicking the lower left-most icon of the screen), then change the drop-down menu entry from “All Scenes” to “Groups”. Let’s move our mouse pointer over to our 3D View and press CTRL G then click Add to New Group or via the Menu, Object > Group > Add to New Group.   Preparing the Weeds for Grouping     Grouping the Weeds   Right after you perform the grouping function, you’ll notice your object outline change from the default white to green which indicates that it belongs to a group. Additionally, we also see a new entry at the Outliner Window labeled “Group”. The outliner is a very powerful aspect of Blender in a way that you can keep your assets, shots, groups, etc. as organized as you want them to. Think of it as your file manager inside of Blender, aside from the fact of course that Blender has its own dedicated file manager too. To rename the group we just created (for easier searching later on), move your mouse pointer over to the group name, then press CTRL left mouse button and the name will change into an input area where you can type the name you want to, in our case we will name it “Weed.Group”. It took me a long time before to figure out how to rename items in the Outliner, I checked every possible menu entry showing some rename-this-group function but unluckily I didn’t find any, not until I accidentally pressed this shortcut (after being so frustrated and bugged). Sometimes, accidents just bring out great surprises we never thought be useful. But of course, I could have settled into asking or searching the Blender forums for the solution, but the stubborn user that I am, I still decided to solve it on my own until I lose my mind, and I did after all (without losing my mind though).   Weeds as Group     Renaming the Group   Now here’s one fun part of creating groups for our objects: using them as particle instances. You’ll see what I mean in a moment. Let’s get back to our terrain layer by pressing 1 on your keyboard or by clicking the first layer button on our layer lineup. Select the terrain object and go to Object (F7) panel then to the Particle buttons sub-panel. Here you’ll see one tab labeled “Particle System”, pretty puny and out-of-place you might say? Just look after we’ve created some system to play around with and you’ll notice just how powerful the particle system of Blender is (far beyond what this article can stress). Click the Add New button to add a new and fresh particle system. Adding a Particle System to the Terrain Object   Rename the particle system from the default “PSys” to something more meaningful like “Weed”. Next, change the Particle Type from Emitter to Hair. Under the Particle System tab, click Random button and beside it select Faces from the dropdown menu, next click Even button and beside it select Random from the dropdown menu. What we just did is to tell the particle system to emit particles in a random order, in an evenly distributed manner on a per-face basis. Still on the Particle System tab, change the amount to 50 and the Segments to 2. We won’t need much for this system, just an adequate amount since we don’t want our system to slow down due to the calculation that Blender does when visualizing particle instances. Right now we don’t see yet what’s actually happening and it’s more like a guessing game at this stage but you’ll see shortly how all this comes together.

In order to work with Pentaho 3.2 Data Integration(PDI) you need to install the software. It's a simple task; let's do it. Time for action – installing PDI These are the instructions to install Kettle, whatever your operating system. The only prerequisite to install PDI is to have JRE 5.0 or higher installed. If you don't have it, please download it from http://www.javasoft.com/ and install it before proceeding. Once you have checked the prerequisite, follow these steps: From http://community.pentaho.com/sourceforge/ follow the link to Pentaho Data Integration (Kettle). Alternatively, go directly to the download page http://sourceforge.net/projects/pentaho/files/Data Integration. Choose the newest stable release. At this time, it is 3.2.0. Download the file that matches your platform. The preceding screenshot should help you. Unzip the downloaded file in a folder of your choice —C:/Kettle or /home/your_dir/kettle. If your system is Windows, you're done. Under UNIX-like environments, it's recommended that you make the scripts executable. Assuming that you chose Kettle as the installation folder, execute the following command: cd Kettlechmod +x *.sh What just happened? You have installed the tool in just a few minutes. Now you have all you need to start working Launching the PDI graphical designer: Spoon Now that you've installed PDI, you must be eager to do some stuff with data. That will be possible only inside a graphical environment. PDI has a desktop designer tool named Spoon. Let's see how it feels to work with it. Time for action – starting and customizing Spoon In this tutorial you're going to launch the PDI graphical designer and get familiarized with its main features. Start Spoon. If your system is Windows, type the following command: Spoon.bat In other platforms such as Unix, Linux, and so on, type: Spoon.sh If you didn't make spoon.sh executable, you may type: sh Spoon.sh As soon as Spoon starts, a dialog window appears asking for the repository connection data. Click the No Repository button. The main window appears. You will see a small window with the tip of the day. After reading it, close that window. A welcome! window appears with some useful links for you to see. Close the welcome window. You can open that window later from the main menu. Click Options... from the Edit menu. A window appears where you can change various general and visual characteristics. Uncheck the circled checkboxes: Select the tab window Look Feel. Change the Grid size and Preferred Language settings as follows: Click the OK button. Restart Spoon in order to apply the changes. You should neither see the repository dialog, nor the welcome window. You should see the following screen instead: What just happened? You ran for the first time the graphical designer of PDI Spoon, and applied some custom configuration. From the Look Feel configuration window, you changed the size of the dotted grid that appears in the canvas area while you are working. You also changed the preferred language. In the Option tab window, you chose not to show either the repository dialog or the welcome window at startup. These changes were applied as you restarted the tool, not before. The second time you launched the tool, the repository dialog didn't show up. When the main window appeared, all the visible texts were shown in French, which was the selected language, and instead of the welcome window, there was a blank screen. Spoon This tool that you're exploring in this section is the PDI's desktop design tool. With Spoon you design, preview, and test all your work, that is, transformations and jobs. When you see PDI screenshots, what you are really seeing are Spoon screenshots. The other PDI components that you will meet in the following chapters are executed from terminal windows. Setting preferences in the Options window In the tutorial you changed some preferences in the Options window. There are several look and feel characteristics you can change beyond those you changed. Feel free to experiment with this setting. Remember to restart Spoon in order to see the changes applied. If you choose any language as preferred language other than English, you should select a diff erent language as alternati ve. If you do so, every name or descripti on not translated to your preferred language will be shown in the alternative language. Just for the curious people: Italian and French are the overall winners of the list of languages to which the tool has been translated from English. Below them follow Korean, Argenti neanSpanish, Japanese, and Chinese. One of the setti ngs you changed was the appearance of the welcome window at start up. The welcome window has many useful links, all related with the tool: wiki pages, news, forum access, and more. It's worth exploring them. You don't have to change the settings again to see the welcome window. You can open it from the menu Help | Show the Welcome Screen. Storing transformations and jobs in a repository The first time you launched Spoon, you chose No Repository. After that, you confi gured Spoon to stop asking you for the Repository option. You must be curious about what the repository is and why not to use it. Let's explain it. As said, the results of working with PDI are Transformati ons and Jobs. In order to save the Transformations and Jobs, PDI offers two methods: Repository: When you use the repository method you save jobs and transformations in a repository. A repository is a relational database specially designed for this purpose. Files: The files method consists of saving jobs and transformations as regular XML files in the filesystem, with extension kjb and ktr respectively. The following diagram summarizes this: You cannot mix the two methods (files and repository) in the same project. Therefore, you must choose the method when you start the tool. Why did we choose not to work with repository, or in other words, to work with fi les? This is mainly for the following two reasons: Working with files is more natural and practical for most users. Working with repository requires minimum database knowledge and that you also have access to a database engine from your computer. Having both preconditions would allow you to learn working with both methods. However, it's probable that you haven't. Creating your first transformation Until now, you've seen the very basic elements of Spoon. For sure, you must be waiti ng to do some interesting task beyond looking around. It's time to create your first transformation. Time for action – creating a hello world transformation How about starting by saying Hello to the World? Not original but enough for a very first practical exercise. Here is how you do it: Create a folder named pdi_labs under the folder of your choice. Open Spoon. From the main menu select File | New Transformation. At the left-hand side of the screen, you'll see a tree of Steps. Expand the Input branch by double-clicking it. Left -click the Generate Rows icon. Without releasing the button, drag-and-drop the selected icon to the main canvas. The screen will look like this: Double-click the Generate Rows step that you just put in the canvas and fill the text boxes and grid as follows: From the Steps tree, double-click the Flow step. Click the Dummy icon and drag-and-drop it to the main canvas. Click the Generate Rows step and holding the Shift key down, drag the cursor towards the Dummy step. Release the button. The screen should look like this: Right-click somewhere on the canvas to bring up a contextual menu. Select New note. A note editor appears. Type some description such as Hello World! and click OK. From the main menu, select Transformation | Configuration. A window appears to specify transformation properties. Fill the Transformation name with a simple name as hello_world. Fill the Description field with a short description such as My first transformation. Finally provide a more clear explanation in the Extended description text box and click OK. From the main menu, select File | Save. Save the transformation in the folder pdi_labs with the name hello_world. Select the Dummy step by left -clicking it. Click on the Preview button in the menu above the main canvas. A debug window appears. Click the Quick Launch button. The following window appears to preview the data generated by the transformation: Close the preview window and click the Run button. A window appears. Click Launch. The execution results are shown in the bottom of the screen. The Logging tab should look as follows:

While the things we learned about using Zabbix agents, creating items and yes, even user parameters are useful, there are some things that are specific to Windows system monitoring which we will look at now. For this section you will need a Windows machine that is accessible from the Zabbix server. Installing Zabbix agent for Windows To install the agent, it first has to be obtained. On Windows, compiling software is less common and most users get binary distributions, which is exactly what we will do now. The Windows build of the Zabbix agent can be obtained from two official locations—either from the download page at http://www.zabbix.com/download.php, or from the source archive. This time it is suggested to use the one included inside the archive to make sure the versions match.The agent executable is located in the subdirectory bin/win32 or bin/win64—choose the one that is appropriate for your architecture and place it on some directory in the Windows machine.For simplicity, we'll use C:zabbix this time, but you are free to use any other directory. We will also need the configuration file, so grab the example provided at misc/conf/zabbix_agentd.win.conf and place it in the same directory. Before we continue with the agent itself let's figure out whether we need to alter the configuration in any way.Open C:zabbix_agentd.win.conf in your favorite text editor and look for any parameters we might want to change. Firstly, the log file location isn't quite optimal—it's set to c:zabbix_agentd.log, so let's change it to read: LogFile=c:zabbixzabbix_agentd.log We have already learned that the server line, which currently reads Server=127.0.0.1, will have to be changed. Replace the 127.0.0.1 part with the IP address of your Zabbix server. As this is not a Zabbix server, replace the Hostname directive to read: Hostname=Windows box Now let's try to start the agent up. Execute: C:zabbix>zabbix_agentd.exe -c c:/zabbix/zabbix_agentd.win.conf While the agent daemon does start up, it doesn't like being started like that and prints a warning: zabbix_agentd.exe [1464]: !!!ATTENTION!!! ZABBIX Agent started as a console application. !!!ATTENTION!!! So what can we do to make it happier? First stop it by pressing Ctrl+C.The agent daemon executable on windows has additional options that can be passed to it, so execute in the command prompt (when located in the directory where zabbix_agentd.exe resides): C:zabbix>zabbix_agentd.exe --help While the start of the output does not differ notably, we can see several additional parameters at the end of the help. ZABBIX Agent Win32 (service) v1.8.1 (revision 9692) (27 January 2010)usage: zabbix_agentd.exe [-Vhp] [-idsx] [-m] [-c <file>] [-t <metric>]Options:-c --config <file> Specify configuration file. Use absolute path-h --help give this help-V --version display version number-p --print print supported metrics and exit-t --test <metric> test specified metric and exitNote that -t and -p switches do not work with user parameters. Usezabbix_get instead.Functions:-i --install install Zabbix agent as service-d --uninstall uninstall Zabbix agent from service-s --start start Zabbix agent service-x --stop stop Zabbix agent service-m --multiple-agents service name will include hostname The Zabbix agent daemon for Windows includes functionality to install it as a standard Windows service, which is controlled by the last set of options. Unless you are simply doing some testing, you'll want to properly install it, so let's do that now. C:zabbix>zabbix_agentd.exe -c c:/zabbix/zabbix_agentd.win.conf -i The Zabbix agent daemon is installed as a Windows service using the configuration file, specified by the -c flag. zabbix_agentd.exe [4376]: Service "ZABBIX Agent" installedsuccessfully.zabbix_agentd.exe [4376]: Event source "ZABBIX Agent" installedsuccessfully. You can verify in the Windows Control Panel, Services section, that the Zabbix service has indeed been installed: While it has been set to start up automatically, it is stopped now. We can start it by either right clicking the Zabbix Agent service entry and choosing Start, or by using command line switch to zabbix_agentd.exe. Let's try the latter method now: C:zabbix>zabbix_agentd.exe -c c:/zabbix/zabbix_agentd.win.conf -s Supposedly service was started successfully. zabbix_agentd.exe [5608]: Service "ZABBIX Agent" started successfully. Again, let's verify in the services list that the Zabbix service has started up: It looks like everything is fine on the monitored host, which we will now have to configure in the frontend. Open Configuration | Hosts, and click Create Host, then fill in the following values: Name: Enter Windows box. Groups: Select Windows servers in the Other Groups box, then click on the < < button. If there's any other group in the In Groups box, remove it. IP address: Enter the IP address of that host. When you are done, click Save. Now select Windows servers in the Group dropdown and click on Items next to the Windows box, then click Create Item. Enter these values: Description: Enter CPU Load Key: Enter system.cpu.load Type of information: Select Numeric(float) Update interval: Enter 60 Keep history: Enter 7 When you are done, click Save. We can now check out incoming data at Monitoring|Latest data—select Windows servers in the Group dropdown. We have now successfully retrieved data on the CPU load for this Windows machine. Notice how the key syntax is the same as for Linux. This is true for several other keys, and you can check out the Zabbix documentation to determine which keys are supported on which platform.

Why are we launching new brands? Packt is somewhat unique in terms of IT publishers. We print books on demand and sell, almost exclusively, directly to our customers from our website. This allows us to print books which sell in relatively small quantities. Accordingly, we can publish on very specific subjects and nascent areas. As a publisher, we live or die by our books. It’s therefore important for us to have good, focused knowledge of technologies and their advancements. With the rapid growth in Open Source software (Gartner reported that 85% of companies use Open Source software in November 2008), and in major Enterprise software (made by companies such as IBM, Microsoft and Oracle), we are releasing more and more books – 190 are due in 2010. Yet as we grow, we risk losing our ability to focus so greatly on specific areas of software whilst remaining credible as a publisher. This is where the new brands come in. Each brand will have personnel focused exclusively on either Enterprise or Open Source software, and this will allow the books to excel in their specific topic areas. What will change? I imagine that you already expect us to change the branding of our future books, and this will be happening. Keep up to date with the blog for branding information, including new book cover styles, and new logos. We are also looking for a wider range of cover images than ever, so if you have even a passing interest in photography, take a look at what we need, and you could have one of your pictures on the cover of a book – imagine how good you’ll feel when you can show that off to your friends. We will be increasing our commitment to the communities around which our books are based. You are probably aware of our work with the Open Source Royalty Scheme, by which Open Source projects receive a percentage of the revenue from each book sold about their software, and our Open Source CMS Award. We are looking to expand both of these projects, and have plans afoot to become more involved with Enterprise communities, because our work with them is growing. Ultimately, wouldn’t you agree that continuing to focus our activities on you, the reader, is important? This unusual branding move is, we believe, the best way of going about doing this.

Retrofitting a website The first thing the client would like to do to their website is spice it up with a new navigation control and a playful, interactive logo for the top of the page. First, we'll work on a navigation control to replace the text links on the left hand side of the page of the current website. As you will notice in the following image, the current website navigation mechanism isn't fancy, but it's simple. However, the client would like the website to be more modern, while preserving ease of use. Adding pizzazz with Silverlight Cake-O-Rama would like to add a fancy navigation widget to their site. They've commissioned a graphic artist to create the following look for the widget.   A few words on search engine optimization We could easily create a Silverlight application that would encompass all the content and functionality of a whole website. However, doing so would severely limit the website's visibility to search engines. Search engines have programs called spiders, or robots, that 'crawl' the internet scanning for content. Generally, these programs can only see text exposed in the HTML. Search results are ranked based on this text-only content. Placing all our content inside a rich internet application platform like Silverlight would effectively hide all of our content. The net result would be reduced visibility on search engines. All Rich Internet Application (RIA) platforms have this issue with search engine visibility. Until this problem is resolved, the best approach is to augment the page's HTML content on sites that you want to be found more easily by search engines. Building a navigation control from the ground up Silverlight 4 has the Grid, Canvas, StackPanel, Border, WrapPanel, ViewBox, and ScrollViewer layout panels. Why are there so many? Well, each one serves a unique purpose. Picking the right kind of container You wouldn't fill a cardboard box with water or drink milk out of a gasoline can, would you? The same could be said of the various layout containers in Silverlight, each one serves a unique purpose and some are better at certain tasks than others. For instance, when you want to create a toolbar, you would probably use a StackPanel or WrapPanel , and not a Canvas. Why? While you could manually code the layout logic to place all the child controls, there's no good reason to. After all, there are already controls to do the heavy lifting for you. Below are the most common layout containers in Silverlight 4: Container Layout Behavior Canvas Manual positioning of items using X and Y coordinates Grid Lays out items using a defined grid of rows and columns InkPresenter Canvas that can handle digital ink StackPanel Stacks items on top of or next to one another WrapPanel Lines up items and wraps them around Border Draws a border around an item Viewbox Scales an item up to take up all the available space ScrollViewer Places a scroll bar around the control Silverlight also provides the means to write your own layout code. While there may be situations where this is warranted, first think about how you can achieve the desired result with a combination of the existing containers. Stack it up: Using the StackPanel Based on the website's current navigation links, StackPanel seems like the best choice. As the name implies, it lays out child controls in a stack, which seems like a good fit for our list of links. Time for action – building navigation buttons in Silverlight Now, let's make a StackPanel of button controls to navigate around the site. In order to do this, we will need to do the following: Launch Visual Studio 2010 and click on File|New Project. Choose to create a new Silverlight Application as shown in the next screen: Name the project CakeNavigationButtons and click OK to accept the default settings. In the MainPage.xaml file, write the following lines of XAML inside the Grid tag: <StackPanel> <Button Content="Home" /> <Button Content="Gallery"/> <Button Content="Order"/> <Button Content="Locations"/> <Button Content="Contact Us"/> <Button Content="Franchise Opportunities"/></StackPanel> Return to Visual Studio 2010 and click on Debug|Start Debugging or press F5 to launch the application. On the following screen, click OK to enable debugging. Your application should look something like this: We have now created a StackPanel of button controls to navigate around the website using Silverlight, but the application is not exactly visually appealing, not to mention, the buttons don't do anything. What we need them to do is reflect the design we've been provided with and navigate to a given page when the user clicks on them. What just happened? What we created here is the foundation for what will eventually become a dynamic navigation control. You have created a new Silverlight application, added a StackPanel, and then added button controls to it. Now, let's move on to make this little navigation bar sparkle. Adding a little style with Styles Many people refer to Silverlight controls as being "lookless", which may sound strange at first as they clearly have a "look." The term refers to the fact that the logic in a control defines its behavior rather than its appearance. That means that all the controls you've seen in Silverlight so far have no presentation logic in them. Their look comes from a default resource file. The good news is that we can create our own resources to customize the look of any control. You can re-style a control in Silverlight in much the same way as you can in Cascading Style Sheets (CSS).

Click here to download the interview, or hit play in the media player below.    

In this article, we play the number game once more. Let's build a formula to calculate the complexity of processes. The purpose is not to teach how to design good processes (the earlier chapters tackled that), but to 'score' them on their control-flow complexity and flag those that exceed a particular threshold. Processes with lower scores are more readable, maintainable, and testable than those with higher scores. Processes with high scores need rework! Most SOA developers, today, struggle with process complexity. They write impeccable, highly-structured Java or C# code, but their processes tend to branch out and meander in every possible direction. They would never dream of embedding an if-then inside a for loop inside a while loop inside of a catch inside a do-while in Java, but they are quick to bury, deep in an SOA process, a pick inside a sequence inside a flow inside of switch inside a scope. Their processes are often far too complex. On the other hand, when they review each others' processes, they know intuitively what 'too complex' means. Process (b) in the following figure, for example, appears much more complex than Process (c), because it has far too many arrows and is difficult to navigate. Process (c) looks tidier and more structured by comparison. Process (a) is harder to judge. Although it is well-structured and easy to navigate, it is also absurdly long; having so many steps in a sequence is poor design. In this article, we quantify 'complex'. We build a formula that rules in favor of Process (c), and penalizes (a) for its excessive sequence and (b) for its nesting and excessive branching. In addition, we demonstrate that processes designed in 'flat form' (introduced in Chapter 6) score lower than 'naïve' processes. Applying McCabe's Formula for BPEL and TIBCO BusinessWorks In this section, we study McCabe's formula for complexity, and describe how it can be used to measure the complexity of processes in BPEL and BusinessWorks. Calculating McCabe Complexity The best-known measure of programmatic complexity is Thomas McCabe's cyclomatic complexity. In his landmark paper, published in 1976 (A Complexity Measure, IEEE Transactions on Software Engineering, v. SE-2, no. 4, pp. 308—320, http://www.literateprogramming.com/mccabe.pdf), McCabe shows how to score the complexity of computer programs (FORTRAN is McCabe's preferred language) using concepts from graph theory. McCabe's approach is twofold: He shows how to represent a computer program as a directed graph, with nodes representing steps and arrows representing the flow of control between these steps. The program must have exactly one entry point, from which all nodes are reachable, and exactly one exit point, which is reachable from all nodes. If the program has several modules or procedures, each is represented as a separate directed graph. The complexity of this graph, and thus the complexity of the computer program, is E – N + 2P, where E is the number of edges, N the number of nodes, and P the number of modules. Assuming the program is a single unit with no separate modules, its complexity is E ‑ N + 2. Alternatively, the complexity of the program is A + 1, where A is the number of decisions or alternate paths in the graph; if a node branches in D directions, it has 1 normal path and D-1 alternate paths. This second method is easier to calculate: start with 1, then for each decision node add the number of outgoing branches less one. For example, add 1 for each binary decision, 2 for each ternary decision, and so on. Process (a) in the figure above has 16 edges and 17 nodes, so its complexity is 16 – 17 + 2, or 1. Alternatively, it has no decisions, so its complexity is 0 + 1, or 1. Process (b) has 23 edges and 10 nodes, and thus, has a complexity of 23 – 10 + 2, or 15. Alternatively, in process (b), node D3 has one alternate path (that is, it is a binary decision), D1, D4, and D5 each have two alternative paths, D6 has three alternate paths, and D2 has four alternate paths; the total number of alternate paths is thus 1 + 2 + 2 + 2 + 3 + 4, or 14. So the complexity of Process (b) is 14 + 1, or 15. Process (c) has 19 edges and 14 nodes, and thus a complexity of 19 – 14 + 2, or 7; alternatively, it has six alternate paths—five for D1, one for D2—so its complexity is 6 + 1, or 7. McCabe advocates the use of his cyclomatic measure on actual software projects. The team should agree on an acceptable upper bound for complexity (say 20), score each program, and decide how to rework those that score too high. McCabe's measure is not perfect. For one thing, it does not penalize processes for having too many nodes. The rather preposterous sequence of 17 activities in Process (a) in the preceding figure has a perfect McCabe score of 1. A process consisting of a million consecutive activities, or even one with as many activities as there are particles in the universe, would also score 1, and would pass review! Secondly, McCabe does not penalize for nested branching. The two processes shown in the following figure have the same complexity, although the process on the bottom is intuitively more complex than that on the top. Each process scores 7, because each contains three ternary (or 3-way) decisions: D1, D2, and D3. In the top process, those decisions come consecutively, whereas in the bottom, they are nested three levels deep. McCabe Complexity for BPEL Despite its flaws, McCabe's formula forms a part of our scoring mechanism for SOA processes; it is a component of a larger measure we develop in the last section of this article. As a pre-requisite for that discussion, we now consider how to apply the McCabe score to processes developed in BPEL and in TIBCO's BusinessWorks. BPEL processes are mapped to McCabe's directed graph form as follows: A BPEL sequence maps easily to a line of nodes, such as fragment shown in the next figure, where the BPEL sequence of activities A, B, and C is drawn as three nodes—A, B, and C—with arrows from A to B and from B to C. A sequence does not add to the complexity of the process. A BPEL pick, flow, or switch is represented as an N-ary decision in the following figure. The beginning and end points of the structure are designated by the nodes labeled Split and Join. For a pick, the branches are onMessage or onAlarm handlers. For a switch, the branches are case or otherwise structures. For a flow, the branches are the activities to be run in parallel (A, B, and C in the figure). (If the flow has inter-activity links, the links are represented as edges.) A pick, switch, or flow adds N-1 to the overall complexity. A BPEL while activity is represented as a GOTO-style loop. The loop begins with a conditional check called Test (as shown in the following figure) and then branches either to A (to perform the while activity if the condition is true), or out of the loop to End. When A completes, it loops back to Test for another iteration. As it contains one binary decision, the while structure adds 1 to the complexity. Error handling is dicier. A single unnested scope with a single error handler and N basic activities (at any level within the scope) adds as much as N to the complexity, assuming each of those basic activities might encounter the error that the handler is meant to catch. The reason for this is that each basic activity must have a binary choice whether to continue down the happy path or route directly to the handler. The scope shown in process (a) in the following figure, contains activities A, B, and C in a sequence (Sc denotes the start of the scope, End its end), but each of these activities has an error path to the handler Error, thus adding 3 to the complexity. In cases with nested scopes and multiple handlers, things get more complicated. An example of this is shown in Process (b). The outer scope, bounded by Sc1 and End1, has two handlers: E11, which is accessible from activity A; and E12, accessible from E. The inner scope, bounded by Sc2 and End2, has its own two handlers, E21 and E22, both of which are accessible from the activities B and C. The E21 handler, in turn, can throw an exception to the outer handler E11. The complexity introduced by all of this is 7: one for the decision at A, one for the decision at E, one for the decision at E21, and two each for the decisions at B and C.

Do not do this in a production database. Before continuing with this article, you should read the Oracle Database Concepts 11g Release 2 (11.2) of the documentation, the book every DBA should start with. Our examination of data blocks starts in Section 12-6 of the Concepts Manual. Data block format: "Every Oracle data block has a format or internal structure that enables the database to track the data and free space in the block. This format is similar whether the data block contains table, index, or table cluster data." A block is the smallest unit of logical storage that the Relational Database Management System (RDBMS) can manipulate. Block size is determined by the database parameter DB_BLOCK_SIZE. The logical storage of data blocks, extents, segments, and table spaces (from smallest to largest) map to the data files, which are stored in operating system blocks. An undo block will store the undo transaction that is the actual SQL command needed to reverse the original SQL transaction statement. This undo is needed for read consistency for all read-only queries until you commit or rollback that transaction. Read consistency within a changed block (transaction) is maintained for any of the following commands: insert, update, delete, merge, select for update, or lock table. Any of the previous changes are tracked until the command is issued to either commit or rollback a particular transaction. This consistency keeps the data view to each user the same, whether they are just doing queries or actually changing any other data. A point in time or what is called the System Change Number (SCN) identifies each transaction, and transaction flags show the state of the transaction. The only end user that can see any changed data will be the one making the changes, no matter the application used until they commit that change. The SCN advances for every change to the database as a sequential counter, which identifies a certain point in time. The SCN tracks more than just single transactions by end users. These transactions will be in Data Definition Language (DDL) or Data Manipulation Language (DML). DDL statements are associated with creating objects (create table) or what is also called metadata. DML are the other commands mentioned earlier (insert, update, delete, among others) that manipulate the data in some way. The RDBMS advances the SCN if another person logs in, reconnects, or alters their session as well as when Oracle background processes (which constantly check the state of activity inside of the database) take place. It is undo that gives everyone a point-in-time consistent view of the data, which is called Read Consistency. There are controls created from business rules within the application called triggers and integrity constraints that validate the data entered by the user. Database locks control access to data during changes for exclusive access by the end user changing it. During a delete or update statement: The data block is read, loading it into a memory structure called a buffer cache The redo log buffer will contain the corresponding delete or update statement An entry in the undo segment header block is created for this transaction It also copies the delete or update row into an undo block For a delete, the row is removed from the data block and that block is marked as dirty Locks keep exclusive use of that block until a commit or rollback occurs Dirty is an internal designation where the block is identified as having changed data that has not been written to disk. The RDBMS needs to track this information for transactional integrity and consistency. The underlying dynamic performance view v$bh indicates when a particular block is dirty, as seen by the following query: SYS@ORCL11>select file#, block# from v$bh where dirty='Y'; When a transaction is committed by the end user: The transaction SCN is updated in the data block and the undo segment header marks that statement as committed in the header section of the undo block. The logwriter process (LGWR) will flush the log buffer to the appropriate online redo log file. SCN is changed on the data block if it is still in the buffer cache (fast commit). Delayed block cleanout can happen when all of the changed blocks don't have the updated SCN indicating the commit has occurred. This can cause problems with a transaction that is updating large numbers of rows if a rollback needs to occur. Symptoms include hanging onto an exclusive lock until that rollback is finished, and causing end users to wait. The delayed block cleanout process does occasionally cause problems that would require opening an Oracle Support Request. Delayed block cleanout was implemented to save time by reducing the number of disk reads to update the SCN until the RDBMS needs to access data from that same block again. If the changed block has already been written to the physical disk and the Oracle background process encounters this same block (for any other query, DML, or DDL), it will also record the committed change at the same time. It does this by checking the transaction entry by SCN in the undo header, which indicates the changes that have been committed. That transaction entry is located in the transaction table, which keeps track of all active transactions for that undo segment. Each transaction is uniquely identified by the assignment of a transaction ID (XID), which is found in the v$transaction view. This XID is written in the undo header block along with the Undo Byte Address (Uba), which consists of the file and block numbers UBAFIL data file and UBABLK data block, and columns found in the v$transaction view, respectively. Please take the time to go through the following demonstration; it will solidify the complex concepts in this article. Demonstration of data travel path Dumping a block is one of the methods to show how data is stored. It will show the actual contents of the block, whether it is a Table or Index Block, and an actual address that includes the data file number and block number. Remember from the concepts manual that several blocks together make up an extent, and extents then make up segments. A single segment maps to a particular table or index. It is easy to see from the following simplified diagram how different extents can be stored in different physical locations in different data files but the same logical tablespace: The data in the test case comes from creating a small table (segment) with minimum data in a tablespace with a single data file created just for this demonstration. Automatic Segment Space Management (ASSM) is the default in 11g. If you create a tablespace in 11g with none of the optional storage parameters, the RDBMS by default creates an ASSM segment with locally managed autoallocated extents. It is possible to define the size of the extents at tablespace creation time that depends on the type of data to be stored. If all of the data is uniform and you need to maintain strict control over the amount of space used, then uniform extents are desirable. Allowing the RDBMS to autoallocate extents is typical in situations where the data is not the same size for each extent, reducing the amount of time spent in allocating and maintaining space for database segments. Discussing the details, options, and differences for all of the ways to manage segment space in Oracle Database 11g is beyond the scope of this article. For this example, we will be using race car track information as the sample data. For this demonstration, you will create a specific user with the minimum amount of privileges needed to complete this exercise; SQL is provided for that step in the script. There are several key files in the zipped code for this article that you will need for this exercise, listed as follows: dumpblock_sys.sql dumpblock_ttracker.sql dumpblocksys.lst dumpblockttracker.lst NEWDB_ora_8582_SYSDUMP1.rtf NEWDB_ora_8582_SYSDUMP1.txt NEWDB_ora_8621_SYSDUMP2.rtf NEWDB_ora_8621_SYSDUMP2.txt NEWDB_ora_8628_SYSDUMP3.rtf NEWDB_ora_8628_SYSDUMP3.txt NEWDB_ora_8635_SYSDUMP4.rtf NEWDB_ora_8635_SYSDUMP4.txt You will also need access to a conversion calculator to translate the hexadecimal to a number that is the first listing below—use hexadecimal input and decimal output. The second will allow you to look up Hex (Hexadecimal) equivalents for characters.http://calculators.mathwarehouse.com/binary-hexadecimal-calculator.php#hexadecimalBinaryCalculatorhttp://www.asciitable.com/ Location of trace files The dump block statement will create a trace file in the user dump (udump) directory on any version prior to 11gR1, which can be viewed by a text editor. Using 11gR1 and above, you will find it in the diag directory location. This example will demonstrate how to use the adrci command-line utility to view trace files. First we set the home path where the utility will find the files, then search with the most recent listed first—in this case, it is the NEWDB_ora_9980.trc file. Now that you know the location for the trace files, how do you determine which trace file was produced? The naming convention for trace files includes the actual process number associated with that session. Use the following command to produce trace files with a specific name, making it easier to identify a separate task: SYS@NEWDB>ALTER SESSION SET TRACEFILE_IDENTIFIER = SYSDUMP_SESSION;