How-To Tutorials - Web Development

Drupal 6 Theming Cookbook Over 100 clear step-by-step recipes to create powerful, great-looking Drupal themes Take control of the look and feel of your Drupal website Tips and tricks to get the most out of Drupal's theming system Learn how to customize existing themes and create unique themes from scratch Part of Packt's Cookbook series: Each recipe is a carefully organized sequence of instructions to complete the task as efficiently as possible Including a CSS file in a theme This recipe details the steps involved in adding a CSS file to the theme via its .info file. In this case, we will be adding a CSS file to the mytheme sub-theme which we created in the previous article. Getting ready Create a CSS file inside the theme's folder named mytheme.css and add the following example rule to it: * { color: #996633 !important; } This rule should override and change the color of all text on the page to a brownish hue. How to do it... Adding a CSS file to a theme is best accomplished via its .info file. Navigate to the theme's folder at sites/all/themes/mytheme and open the mytheme.info file in an editor. Add the following line to this file to include our CSS: stylesheets[all][] = mytheme.css If the CSS file is stored along with other stylesheets in a sub-folder named css, the syntax would include the relative path to the file as follows: stylesheets[all][] = css/mytheme.css. Once done, save the file and exit the editor. Since we have modified the .info file and introduced a new file, our changes will not take effect until the theme registry is rebuilt. Therefore, clear the Drupal cache and view the site to confirm that our new stylesheet has been included correctly. The theme should now display all text in brown. How it works... Drupal checks the .info file and notes that we have declared stylesheets using the stylesheets variable. The syntax of this variable is similar to that of an array in PHP. The all index in the syntax represents the media type as used in CSS declarations. The next screenshot displays a section of the source code of a page which confirms the inclusion of the new stylesheet, mytheme.css. We can also see that our sub-theme is including the stylesheets declared by its base theme—Garland—as well as its own stylesheets. In the preceding screenshot, we can see that Drupal references each stylesheet along with a query string. For example, mytheme.css is included as mytheme.css?e. This rather quirky suffix is a trick used by Drupal to ensure that browsers do not use stale copies of a cached CSS file while rendering our site. We can test this by clearing the Drupal cache and viewing the source code once again. Now, our stylesheets should have a different suffix— perhaps, something like mytheme.css?A—thereby tricking browsers into believing that these are different files and using them instead of their cached copies. There's more... One of the advantages of using a sub-theme is that we can easily override elements of the base theme. This includes stylesheets as well. Overriding the base theme's stylesheet If the base theme includes a stylesheet named layout.css, adding a stylesheet of the same name in the sub-theme will override the base theme's stylesheet. In other words, Drupal will include the sub-theme's stylesheet instead of that of the base theme. Enabling CSS optimization CSS optimization in Drupal is accomplished through two steps—aggregation and compression. This optimization provides a significant boost to performance both on the server as well as for the user. This recipe details the steps to be performed to enable this feature in Drupal. Getting ready CSS optimization is a requirement only when a site is ready to go live. Until such time, it is recommended that it be left switched off as CSS changes during development will not take effect unless the Drupal cache is cleared. How to do it... Optimization and other performance-related features are sequestered within admin/ settings/performance (Home | Administer | Site configuration | Performance). This performance configuration page should have a section titled Bandwidth optimizations which should contain options for CSS and Javascript optimization. Look for the setting named Optimize CSS files and set it to Enabled as in the following screenshot: Public File system As the screenshot states, the optimized CSS file is cached using Drupal's file system which needs to be set to public to ensure that the user's browser can access and download it. Therefore, it is necessary to set Download method of the Drupal file system to Public. This can be done via admin/settings/file-system (Home | Administer | Site configuration | File system). Once done, click on the Save configuration button at the bottom of the page to save our changes. How it works... Aggregation involves the collating and joining of multiple CSS files into a single stylesheet, while compression reduces the resulting file to a smaller size by trimming out unnecessary elements such as whitespace. The former helps in reducing the number of files that the server has to load and serve. The latter saves on bandwidth and time. The previous and following screenshots demonstrate CSS optimization at work. The previous screenshot is a snippet of the HTML source of a Drupal page running on a stock Garland theme. As displayed, this involves the server performing look-ups and serving eight separate CSS files—seven for all media types and a print stylesheet—for each and every page served. If this is extrapolated to sites of greater complexity, the number of files and, consequently, the server and bandwidth load, begin to take on significant proportions and can seriously impact performance. The preceding screenshot is of the same page as before with one difference—CSS optimization is now turned on. The number of CSS files has now been reduced to only two—one for all media types and the other being the print media type. These stylesheets are stored in the files folder and are cached copies. As a result, each page load now only involves the webserver serving two files instead of the previous eight. There's more... CSS optimization and other performance improvements should be used with care. When to use it CSS optimization is only necessary to improve performance on production sites. Enabling it beforehand will only hinder theme development. Enabling optimization can sometimes be handy when working on sites which are using more than 31 stylesheets—a not too infrequent occurrence on sites using a plethora of modules and an elaborate theme—as this is an upper-bound for Internet Explorer. IE will only load the first 31 stylesheets and ignore the rest. Drupal's CSS optimization feature reduces this number to one, thereby conveniently working around the issue. An alternative is to use modules such as IE CSS Optimizer (http://drupal.org/project/ie_css_optimizer). Other optimizations Other optimization settings can also be configured on the performance page. These include page caching, block caching, and JavaScript optimization. It is also worthwhile browsing the caching and performance modules that are available as contributed modules via http:// drupal.org/project/modules under the category Performance and scalability. Creating the mysite module to hold our tweaks In the course of developing our site, we will frequently come across situations where various elements of the site need to be tweaked in PHP using Drupal's APIs. While a lot of theme-specific cases can be stored in template files, certain tweaks which are theme-agnostic require that we store them in a module to ensure that they are available to all themes. This recipe covers the creation of a module to hold all these bits and pieces. Getting ready Create a folder inside sites/all named modules. This is where custom and contributed modules are usually housed. How to do it... The following list details the procedure involved in creating a module named mysite to hold our theme-agnostic customizations and other odds and ends: Create a folder inside sites/all/modules named mysite where mysite refers to the name of our site. Create a file named mysite.info within the mysite folder. Edit this file and add the following code inside: name = Mysite description = A module to hold odds and ends for mysite. core = 6.x Save the file. Create another file named mysite.module which will hold our odds and ends. Save and exit the editor. Finally, enable the module via the module administration page at admin/build/ modules (Home | Administer | Site building | Modules). How it works... Just as with themes, modules require a .info file which provides information to Drupal on compatibility, dependencies, and so on. Once Drupal ascertains that the module is compatible with the version installed, it loads the .module file of the same name and processes it accordingly. We can test if the module is working by adding a snippet such as the following: <?php /** * Implementation of hook_init(). */ function mysite_init(){ // Display a message on every page load. drupal_set_message("Welcome to MySite!"); } As the comment suggests, the preceding snippet will display a welcome message on every page load. There's more... The Drupal community routinely comes up with modules to ease the pain of development. Module builder There's a module available named Module builder which can be used to generate a skeleton of a general module. This can subsequently be populated as per our requirements. It is available at http://drupal.org/project/module_builder.

TYPO3 Templates Create and modify templates with TypoScript and TemplaVoila Build dynamic and powerful TYPO3 templates using TypoScript, TemplaVoila, and other core technologies. Customize dynamic menus, logos, and headers using tricks you won’t find in the official documentation. Build content elements and template extensions to overhaul and improve TYPO3’s default back-end editing experience. Follow along with the step-by-step instructions to build a site from scratch using all the lessons in the book in a practical example. Page tree concepts We are about to dive into all of the little details, but there are a few basic concepts that we need to review first. So, we're going to make sure we have a more complete definition that avoids any confusion: Page tree: Our TYPO3 page tree is all of the pages and folders that we work with. This includes the home page, about us, subpages, and even non-public items such as the storage folder in our example site. If we have a very simple website it could look like this: Home About Us Staff Level: Our page tree will almost always have pages, subpages, and pages under those. In TYPO3, these are considered levels, and they increase as you go deeper into the page tree. For example, in our extremely simple website from the example above both Home and About Us are at the base (or root) of our page tree, so they are on level 0. The staff page is underneath the About Us page in the hierarchy, so it is on level 1. If we added a page for a photo gallery of our last staff lunch as a subpage to the staff page, then it would be at level 2: Home (Level 0) About Us (Level 0) Staff (Level 1) Staff Lunch Gallery (Level 2) Rootline: TYPO3 documentation actually has a few different uses for the term "rootline", but for the menu objects it is the list of pages from your current page or level moving up to the root page. In our example above, the current rootline from the Staff Lunch Gallery is Staff Lunch Gallery | Staff| About Us Before we look at all the different kinds of menus in TYPO3 and all their little differences, we need to explore the base TypoScript object for all of them: HMENU. HMENU generates hierarchical menus, and everything related to menus in TYPO3 is controlled by it. As the base object, HMENU is the one thing that every type of menu is guaranteed to have in common. If we understand how HMENU is creating its hierarchical menu, then everything else is just styling. We can already see an example of HMENU being used in our own TypoScript template setup by looking at the menus that the TemplaVoila Wizard generated for us: ## Main Menu [Begin] lib.mainMenu = HMENU lib.mainMenu.entryLevel = 0 lib.mainMenu.wrap = <ul id="menu-area">|</ul> lib.mainMenu.1 = TMENU lib.mainMenu.1.NO { allWrap = <li class="menu-item">|</li> } ## Main Menu [End] ## Submenu [Begin] lib.subMenu = HMENU lib.subMenu.entryLevel = 1 lib.subMenu.wrap = <ul id="submenu-area">|</ul> lib.subMenu.1 = TMENU lib.subMenu.1.NO { allWrap = <li class="submenu-item">|</li> } ## Submenu [End] We can see that the wizard created two new HMENU objects, lib.mainMenu and lib.subMenu, and assigned properties for the entry level and HTML tags associated with each menu. We're about to learn what those specific properties mean, but we can already use the code from the wizard as an example of how HMENU is created and how properties are defined for it. Types of menu objects The HMENU class does not output anything directly. To generate our menus, we must define a menu object and assign properties to it. In our current menus, the TemplaVoila Wizard generated a menu object for each HMENU in the following highlighted lines: ## Main Menu [Begin] lib.mainMenu = HMENU lib.mainMenu.entryLevel = 0 lib.mainMenu.wrap = <ul id="menu-area">|</ul> lib.mainMenu.1 = TMENU lib.mainMenu.1.NO { allWrap = <li class="menu-item">|</li> } ## Main Menu [End] ## Submenu [Begin] lib.subMenu = HMENU lib.subMenu.entryLevel = 1 lib.subMenu.wrap = <ul id="submenu-area">|</ul> lib.subMenu.1 = TMENU lib.subMenu.1.NO { allWrap = <li class="submenu-item">|</li> } ## Submenu [End] There are a handful of classes for menu objects that can be used by HMENU to generate menus in TYPO3, but we are going to be concentrating on the two most powerful and flexible options: TMENU and GMENU. The TemplaVoila Wizard used TMENU in our current menu, and it is used to generate text-based menus. Menus built with TMENU output the title of each page in the menu as a text link, and then we can use HTML and CSS to add styling and layout options. Menus created with the GMENU class are considered graphic menus. We can use GMENU to dynamically generate images from our page titles so that we can use fancy fonts and effects like drop-shadow and emboss that are not supported in CSS by all browsers equally. Menu item states The menu system in TYPO3 allows us to define states for different menu options. For example, using the state definitions, we can customize the behavior of menu items when they are active or rolled over. The normal state (NO) is available and set by default, but all of the menu item states must be enabled in TYPO3 by adding code to our template like this: lib.mainMenu.1.ACT = 1. All menu objects share a common set of menu item states from the table below: HMENU properties Because HMENU is the root of all of our other menu objects, any of the properties that we learn for HMENU will be applicable to all of our menu options that we might use on future websites. I've included a list of the TypoScript properties that we are most likely to use in the TypoScript template setup, but you can see the complete list in the TSref (http://typo3.org/documentation/document-library/references/doc_core_tsref/current). If you haven't used TypoScript much, and this is too much information all at once, don't worry. It will make more sense in a few pages when we start experimenting on our own site. Then, this will serve as a great reference. As we've already witnessed in the main menu, TYPO3 sorts our menu by the order in the page tree by default. We can use this property to list fields for TYPO3 to use in the database query. For example, if we wanted to list the main menu items in reverse alphabetical order, we could call the alternativeSortingField in our template: lib.mainMenu.1 = TMENU lib.mainMenu.1.alternativeSortingField = title desc

  Koha 3 Library Management System Install, configure, and maintain your Koha installation with this easy-to-follow guide A self-sufficient guide to installing and configuring Koha Take control of your libraries with Koha library management system Get a clear understanding of software maintenance, customization, and other advanced topics such as LDAP and Internationalization Written in a style that applies to all Linux flavors and Koha versions Orientation to updating software Before we can update the Koha software, let us learn about Koha's software versions and how to choose the version to upgrade to. In this section we also learn about the components of a software update, and how to install each component of the update properly. Understanding Koha's software versions To choose which new version to upgrade to, let us first understand how the Koha software is organized. Branches At any given point Koha has at least two main software branches: Stable: This branch is older and is considered stable or bug free for the most part. Only bug fixes are allowed on this branch. Development: This branch is where new features are developed. This branch is ahead of the stable branch, meaning it has all the features of the stable branch and the new features in development. Heads Both branches—stable and development have heads. A heads is the tip of the branch, pointing to the latest change made in that branch. At the time of writing of this article, there are two heads available in Koha's Git repository. 3.0.x: This is the tip of the stable branch master: This is the tip of the development branch Tags Both branches have multiple tags. Tags point to specific points in a branch's change history. For instance we see these tags related to the stable branch: v3.00.06: This is the latest stable branch v3.00.05: An earlier version of the 3.0.x branch v3.00.04: An earlier version of the 3.0.x branch v3.00.03: An earlier version of the 3.0.x branch And these tags are available for the development branch: v3.02.00-beta: This is the 3.02 branch in the beta testing stage v3.03.00-alpha: This is the 3.02 branch when released for alpha testing Choosing a version to update to We can choose to move to the head of the stable branch or the head of the development branch or to any tag in one of these branches. Here are some pointers to help you decide: On production servers, we upgrade to the latest stable tag in the stable branch To take an early look at new features being developed, switch to the alpha or beta tag in the development branch, if available If you want to take a look at the very latest version of the software, switch to head of the development branch Understanding components of software updates When bugs are fixed or new features are added in Koha, different types of files and programs can change such as these: Perl, Java script, HTML, CSS, and other types of files in kohaclone folder Tables, columns, constraints, indexes, system preferences, and other types of changes in Koha's database Indexes and properties in Zebra configuration files Directives in Koha's Apache2 configuration files An overview of the installation process To ensure that software updates are installed properly, we need to follow these steps: Download software updates: We can download updates using Git. Git automatically detects our current version and downloads updates from Koha's online repository. Switch to a specific software version: Depending on our purposes, we will choose a version that we want to upgrade to. Install Perl module prerequisites: The new version of the software may depend on new Perl modules; we will need to install these. Install the new version of Koha: We will install the new Koha version using the make utility; this process is similar to that of a fresh Koha install. Configure Apache2: The new version of the software may have an updated Apache2 configuration file. We will need to configure this new file. Upgrade the database: We will use Koha's web installer to upgrade the database to the new version. Rebuild Zebra indexes: The new software version may contain updates to Zebra configuration files. To have these changes reflected in search results, we will need to do a full rebuild of Zebra's indexes. Restart Zebra server: To load new Zebra configurations we will have to restart zebrasrv.

There are four basic types of Q replication: Unidirectional Bidirectional Peer-to-peer Event Publishing Replicating to a stored procedure or a Consistent Change Data (CCD) table are a subset of unidirectional replication. Let's look at each of these in more detail. Unidirectional replication In unidirectional replication, we can replicate all of the rows and columns of a source table or we can just replicate a subset of the rows and columns. We cannot really perform any transformation on this data. If we want to perform some sort of transformation, then we would need to replicate to a stored procedure. Replicating to a stored procedure Stored procedure replication is a subset of unidirectional replication in which the target is not a table as such, but a stored procedure, as shown in the following diagram: A stored procedure can transform the data and output the results to a target table. This target table is not known to Q Apply. These stored procedures can be written in SQL, C, or Java. Prior to DB2 9.7 the source table and the stored procedure must have the same name, and the target table name can be any name we like. Bidirectional replication In bidirectional replication, we replicate copies of tables between two servers, each of which has a copy of the table. Note that we can only set up bidirectional replication between two servers. Unlike unidirectional replication, where we can replicate a subset of rows and columns, this is not possible in bidirectional replication. The tables on both servers can have different names, but must have the same number of rows and columns. The columns must have identical column names of compatible data types. It is not possible to do any data transformation using this type of replication. Because we are updating records on both servers, it is possible that the same record will be updated at the same time on both servers. Although Q replication provides a conflict detection mechanism, we strongly advise that the driving application should be written or modified in such a way that such conflicts be avoided. The conflict detection provided by Q replication should be treated as a safety net and not the primary conflict resolution mechanism. This mechanism allows us to choose which data values are used to detect conflicts (key column values only, changed column values, or all column values) and which server should win if such a conflict is detected. The row in the losing system is rolled back and the record is written to the IBMQSNAP_EXCEPTIONS table for review. One of the related subjects to conflict detection is the concept of which server takes precedence in a conflict, or to put it more bluntly, which server is the master and which is the slave! If there is a conflict, then whichever server takes precedence will not apply changes from the other server. This ensures that the servers remain in sync. There is a more egalitarian option, which is that no server takes precedence. In this situation, rows are applied irrespective of whether or not there is a conflict, which ultimately leads to a divergence of the contents of the databases, which is not good! There are two types of bidirectional replication—the first type is where we have an active/passive setup and the second type is where we have an active/active setup. The type of replication you choose will have implications on which server is defined as the master and which as the slave and what to do if a Q subscription is inadvertently inactivated. In an active/passive setup, the passive server should be made the master. In an active/active setup, the choice of which system is the master is a decision you have to make. Peer-to-peer replication Peer-to-peer replication allows us to replicate data between two or more servers. This is different from bidirectional replication, which is only between two servers. Each server has a copy of the table (which can have a different schema and name), but must have the same number of rows and columns and these columns must have identical column names and compatible data types. It is not possible to do any data transformation using this type of replication. In peer-to-peer replication, there is no such thing as a master or slave server—each server will have the most recent copy of the table—eventually! What this means is that there will be a slight delay between the first server having a copy of the table and the last server having that copy. This is an asynchronous process, so at any one time the tables might be different, but once applications stop updating them, then the tables will converge to the most recently updated value. This type of processing means that there isn't any "manual" conflict detection as such (it is handled automatically by Q Apply), because the latest update will always win. If two applications update the same record at exactly the same time, then Q replication uses the server number allocated when the peer-to-peer environment was set up to determine the winner. This type of processing means that two columns are added to each of the tables in the Q replication environment, where the first column is a timestamp of when the row was last updated (GMT) and the second column is the machine number. These updates are performed through triggers on the tables.

Getting Started with Oracle BPM Suite 11gR1 – A Hands-On Tutorial Learn from the experts – teach yourself Oracle BPM Suite 11g with an accelerated and hands-on learning path brought to you by Oracle BPM Suite Product Management team members Offers an accelerated learning path for the much-anticipated Oracle BPM Suite 11g release Set the stage for your BPM learning experience with a discussion into the evolution of BPM, and a comprehensive overview of the Oracle BPM Suite 11g Product Architecture Discover BPMN 2.0 modeling, simulation, and implementation Understand how Oracle uses standards like Services Component Architecture (SCA) to simplify the process of application development Describes how Oracle has unified services and events into one platform Built around an iterative tutorial, using a real-life scenario to illustrate all the key features Full of illustrations, diagrams, and tips for developing SOA applications faster, with clear step-by-step instructions and practical examples Written by Oracle BPM Suite Product Management team members           Read more about this book      (For more resources on Oracle, see here.) BPM yields high business benefits in many dimensions when adopted successfully. Thus it is prudent to be familiar, right from the start, with the essential considerations that lead to a successful BPM adoption, and conversely, the absence of which is likely to lead to failure and frustration. However, before we dive into a discussion on how we should prepare for BPM projects, a couple of clarifications are in order. First, we should point out that not all processes are business processes. A process, particularly a digital description of a process, is essentially a depiction of a sequence of activities along with applicable flow control and business logic. In digital applications such processes appear in a variety of places. Take for example a "customer information update" activity with cross-departmental scope. This may involve updating multiple back-end IT applications, and the exact update operation may differ from application to application in how much to update and in what format to communicate with the application; there may be conditions under which certain updates may or may not take place, and so on. Often, processes are used to explicitly state all the individual tasks and associated logic behind a complex activity such as this system-wide customer information update. While such a customer information update activity will be recognized as an important and essential process at a business level, its lower level details may be expressed by an information mediation process that may be of little interest to a line of business owner. Thus, the associated process is not a business process. In general, business processes will involve activities with direct relevance to the business and the process itself will typically embody all, or a significant part, of some business value-chain. Compared to the processes that guide data exchange between applications, business processes also typically engage more roles, often played by human participants, and involve complicated decision making, some of which requires sophisticated articulation of business rules; some others require live actions by the human participants. Depending on the situation, certain tasks in a business process may have to be transferred from one participant to the other. In some cases, a business task may require joint activity of several participants, as in collaboration. These behind-the-scenes, technical workflow processes that exchange data between applications and perform other integration flows in support of the business tasks are generally referred to as service orchestrations to distinguish them from core business processes. The second clarification concerns the abbreviation BPM, which is commonly used to imply Business Process Modeling, or Business Process Monitoring, or even Business Performance Management. Here we are referring to the full lifecycle of business processes of which modeling and monitoring are specific parts. Business performance management has a finance focus, and of course, business processes can feed useful information to such financial calculations. Areas of focus for successful BPM adoption Successful BPM adoption often involves changes in organizational behavior and focus, acquisition of skills in the necessary technology and tools, and implementation of suitable working practices. These practices range from planning to implementation of business processes, working with process instances, and monitoring and management of such processes, including post-implementation process improvement activities. These are areas of focus that are critical for BPM adoption success. Process-centric or process-driven organizations behave differently than others, in that their leaders are strongly committed to business process excellence, and their employees at all levels are better aware how the business conducts itself. Their processing of business transactions has clearer definition, better visibility, and end-to-end traceability. Such organizations make necessary investments in improving their existing processes and creating newer ones faster than their competition. Suitable change in organizational behavior, when warranted, is critical for successful BPM adoption. The implementation of such organizational changes concerns various aspects of organizational development, such as organizational culture, managerial actions and incentive compatibility, and is not strongly tied to a specific BPMS. Mastering adequate skills in a BPMS suitable for the scope of BPM adoption is critical for efficient and successful delivery of individual projects. BPM practice, that is, the discipline and organized activities that lead to successful BPM projects, combines BPM methodology with proper use of tools and can be seen as one of the ways an organization committed to process excellence conducts itself. This article will focus on some of the practice aspects of a BPM project. The scope of a BPM project can also vary from company to company. A BPM project may be limited to simply working on a specific process, either creating a new one or improving an existing one. We would call this a tactical project. On the other hand, a BPM project may be the starting point of a broader scoped BPM adoption that is intended to span multiple sub-organizations and is meant to include families of BPM applications. We would call this a strategic initiative. Of course, you may also be dealing with a BPM project that is one of many being executed under a bigger BPM program. Clearly, your preparation will be somewhat different depending on what type of project you are involved in. Regardless of the scope of your BPM project, an essential step in assuring project success is to identify the Critical Success Factors (CSFs) of your project. You need to also ensure that these CSFs are relevant to the key stakeholders of the project, including those who fund the project or own or use the outcome of the project. Once you know the scope of your BPM adoption, an immediate question is, do you have the right capabilities, both in type and level, to execute the chosen initiative successfully? Oracle's BPM methodology provides a BPM Capability Maturity Model framework to articulate your BPM capabilities. It groups nearly a hundred individual capabilities into eight capability domains: business and strategy, organization, governance, project process and service portfolios, architecture, information, infrastructure, and operations, administration, and management—the first half of this list focuses more on organizational aspects while latter half is more technology focused. Oracle's BPM maturity model also classifies an organization on its level of expertise within each of the capabilities (and thus within each of the capability domains) in one of five maturity levels: Ad-hoc, Opportunistic, Systematic, Managed, and Optimized. The higher the level of maturity, the higher is the ability to execute; conversely, lower levels of maturity identify areas that may require improvement. Target maturity levels for each of the capability domains depend on the scope and goals of a BPM initiative, and any gap between the required and available maturity levels for any of the capabilities, if not remedied, can be a potential source of risk adversely affecting successful execution of the BPM initiative. The following diagram shows capability types and maturity levels per Oracle's BPM methodology: Starting with the right business process Something that begins in the right way has a better chance of ending well. This is no different in the case of BPM projects. So, what process would you pick as the focus of your BPM project? In other words, what are the important process selection criteria? Processes can be characterized by the amount of complexity they exhibit in terms of their suitability for explicit representation (as this is needed for digital modeling), number of activities, amount of logic, diversity of process stakeholders, number and spread of the back end application they connect to, and the type and number of human user interfaces the process needs to support. Process complexity can also be interpreted as a cost and/or risk measure. Processes can also be classified on the basis of the business impact they are likely to make—this is a benefit measure. Thus, processes that have low cost or complexity and a high business impact or benefit are easy picks for starting BPM projects and should be assigned the highest priority. Conversely, processes with high complexity and low business impact should be given the lowest priority. Other possible combinations of process cost and benefit would have intermediate priorities. Of course, this cost-benefit analysis is useful when you have the possibility of choosing one or few processes from a larger set of possible candidate processes. In some cases certain organizational mandates may require you to consider a process which has been prioritized according to more diverse cost-benefit rankings, for example, a process that may be needed for ensuring certain legal compliance. Once a process is chosen for a BPM project, it is advisable for the program or project managers to assess BPM capability maturity of the teams involved in the project in the context of the requirements of that project. Should significant gaps be found between the as-is and the required capabilities, strategies for timely bridging of such gaps should be included as part of the project plan.

TYPO3 Templates Create and modify templates with TypoScript and TemplaVoila Build dynamic and powerful TYPO3 templates using TypoScript, TemplaVoila, and other core technologies. Customize dynamic menus, logos, and headers using tricks you won’t find in the official documentation. Build content elements and template extensions to overhaul and improve TYPO3’s default back-end editing experience. Follow along with the step-by-step instructions to build a site from scratch using all the lessons in the book in a practical example. Our graphical menu, GMENU, has the ability to use a TYPO3 class, GIFBUILDER, to create images on the fly. We are going to look at GIFBUILDER in depth in just a moment, but the basic idea is that GIFBUILDER can help us build complex graphics for our menus dynamically so that we can use fonts that are not be supported by all browsers, build button-like graphics, and use drop-shadows and embossing for effect. This means that we don't need to update Photoshop every time that we want to change the menu titles or replace the font, and we also don't have to learn or use Flash or JavaScript just to create flexible menu titles. We gain a lot of freedom and power with GMENU, but it does have some disadvantages compared to TMENU. Depending on our needs, we will be generating an image for every state (normal, rollover, active, and so on), for each menu item anytime we make a change. The nice thing is that TYPO3 will cache our images, so they are only generated after we make a change and reset the cache. Overall, we will use the server a little more heavily anytime we reset the cache, and our users will need to download images for each menu item. The last disadvantage is just that it is more complex than TMENU. If our frontend developers or designers have already provided us with some awesome CSS/JavaScript or Photoshop images, then we may only need a text-based menu. In return for those possible disadvantages, we will get freedom and cross-browser compatibility, so let's see what we can do before we make any decisions. Introducing GIFBUILDER GIFBUILDER is a universal object in TypoScript that uses some basic TypoScript code to generate images using the ImageMagick (or GraphicsMagick) library in PHP. Generating images with ImageMagick is normally very complex, and we would have to learn a fair amount of PHP to make anything. Using GIFBUILDER, makes it relatively easy to make these same dynamic images without learning PHP or opening Photoshop. GIFBUILDER can actually be used for any images that we would want to create in TypoScript, but we are going to be using it specifically for GMENU in this article to turn our text fields into typographic images complete with layers and effects. We are going to learn about three main objects in GIFBUILDER that will help us create our menu items: Boxes: We can layer simple boxes to make borders or button effects. Images: We can use uploaded or external image files as backgrounds or just display them as menu items. Text: Most importantly, we can use text objects to show our page titles in non-web fonts with drop-shadow or emboss effects. A complete list of the properties available to GIFBUILDER is beyond the scope of this article, and not really necessary to build most menus. If you have any problems with GIFBUILDER, you may need to check your ImageMagic configuration in the TYPO3 Install Tool. The BOX object The BOX object is one of the key TypoScript objects in GIFBUILDER. The BOX object is, like it sounds, just a simple graphical box defined by its size and color. By itself, it's not that helpful, but we can add boxes as layers to generate borders and backgrounds that will be flattened into our final generated images. We are only going to use two properties for our boxes: BOX.dimensions defines the dimensions of the box in the format x, y, w, h where x, y is the offset for the top right-corner and w, h is the width and height of the box. BOX.color defines the color of the inside of the box. Here is an example of a gray box, 400 pixels wide, 20 pixels tall, and offset 3 pixels down and to the right: lib.subMenu.1.NO { 5 = BOX 5.color = #aaaaaa 5.dimensions = 3,3,400,20 } The IMAGE object The next object we can use, IMAGE, will bring in an image for normal display or basic tiling and masking. The IMAGE object can be used for complex displays, but we are only looking at menu applications and will just look at a few options: The TEXT object Finally, we're going to look at the options for a TEXT object in GIFBUILDER. TEXT objects are used to display any text we want in GIFBUILDER, but will be mainly using them to show the title of each page as a menu item. This list of properties is much more exhaustive because this would obviously be one of the most important objects to customize when we're creating a menu using graphical text: GIFBUILDER layers We work with GIFBUILDER by creating new objects for the GIFBUILDER, designing them with properties, and layering them by number values. Each layer is stacked in ascending order (larger numbers on top), and then TYPO3 generates a final image by flattening all of the layers into one image. It sounds a little complex, but look at this example: lib.subMenu.1.NO { 5 = BOX 5.color = #aaaaaa 5.dimensions = 3,3,400,20 10 = TEXT 10.text.field = title 10.fontSize = 12 } In the example that we just saw, lib.subMenu.1.NO is our GIFBUILDER object. Although the numbers used to identify objects (5 and 10 in the example) are sometimes arbitrary in TYPO3, they are very important for GIFBUILDER because they define the ordering in layers. GIFBUILDER stacks it's subobjects from lowest number to highest. So, in the example that we just saw, TYPO3 is generating an image in a logical sequence: A gray box is defined. The dimensions of the gray box are defined to make it 400 pixels wide and 20 pixels. A text object is created on top of the gray box to show the title field of the page from the menu item. The size of the text for the title is set to 12 pixels. TYPO3 generates a flattened image of our menu item title in a gray box. Using this system, we can stack very simple objects on top of each other to draw basic buttons. GIFBUILDER properties The GIFBUILDER object will apply itself to all items in a GMENU menu. For the basic GIFBUILDER object, we are only going to look at two properties: XY defines the size of the image (width and height) backColor defines the background color for the entire image The interesting trick for XY (and some of the other dimension properties) is that it can be based on hard-coded numbers and TypoScript constants, or it can be a calculation based on the size of another item. In the following code, the size of the GIFBUILDER object is tied directly to the size of the TEXT object declared below it: 10 = TEXT 10.text.field = title XY = [10.w]+10,[10.h]+10 The references [10.w] and [10.h] read the current width and height of the object associated with 10. Then, we add 10 pixels onto each one to give ourselves a little bit of room for spacing. We'll use this technique in GMENU to make sure that our boxes and graphic objects always line up with our titles. GMENU properties The first thing that you'll probably notice going from TMENU to GMENU is that we are about to multiply the number of properties at our disposal dramatically. We've already covered the common menu properties. We're just going to cover the most basic or necessary properties in the following tables to get an idea of what we can do. If it looks intimidating, don't worry. Most of the properties are created logically and build upon our earlier knowledge. Most importantly, there's no requirement to learn all of GIFBUILDER before we start playing around. The menu object itself has just a few key properties that we need to look at: Creating our first graphic menu The first change we can accomplish is updating our main menu with a custom font and some rollover functionality. We can do that with minimum fuss, and it'll update our whole look nicely. I chose a freeware font from Larabie Fonts (http://www.larabiefonts.com) called Deftone because it'll show off GIFBUILDER, and my boss loves it. You can use any TrueType font file you would like, though. Some fonts seem to work better with ImageMagick then others, so you may need to experiment. In any case, let's start updating our menu: We need to change lib.mainMenu.1 = TMENU to lib.mainMenu.1 = GMENU to use the GMENU objects. We want a consistent height for our entire menu, so we'll enable useLargestItemY in our template: lib.mainMenu.1.useLargestItemY = 1 Let's update the normal menu state first. We won't be using the div tags around our menu items, so want to add a class to our images: lib.mainMenu.1.NO.ATagParams = class="menu-link" We can set the background color and dimensions of our menu items. We are going to use 10 for our text object, so we can go ahead and use that as part of the size calculation to make our items exactly the same width and 5 pixels taller than the text: lib.mainMenu.1.NO { backColor = #ffffff XY = [10.w],[10.h]+5 } Now we can create the TEXT object. This is our main menu, so we're just going to use the title as our text content. We're also going to use the Deftone font at a size of 36 in a classic black: lib.mainMenu.1.NO { 10 = TEXT 10.text.field = title 10.fontFile = fileadmin/templates/deftone.ttf 10.fontSize = 36 10.fontColor = #000000 10.align = left } The main menu is already looking better, but we can add some flair by tilting the text up with the angle property. Because of the angle changing the dimensions, we'll push the text down a little more by adding a 50 pixel offset to the height: lib.mainMenu.1.NO { 10.offset = 0,50 10.angle = 3 } After all of our modifications, this is what our menu should look like:

  Drupal 6 Theming Cookbook Over 100 clear step-by-step recipes to create powerful, great-looking Drupal themes Take control of the look and feel of your Drupal website Tips and tricks to get the most out of Drupal's theming system Learn how to customize existing themes and create unique themes from scratch Part of Packt's Cookbook series: Each recipe is a carefully organized sequence of instructions to complete the task as efficiently as possible         Read more about this book       (For more resources on Drupal, see here.) Introduction One of the more prevalent adages with respect to Drupal development and theming is: Do not hack core! Modules, themes, and other files which come with a stock Drupal installation should never be edited directly. In other words, we really should not need to modify anything outside the sites folder which is designed to contain all our changes and customizations. The reasoning behind this is that most, if not all, aspects of core are accessible and modifiable through a clean and non-invasive process using Drupal's APIs. Therefore, hacking core modules and themes to get things done is almost always unnecessary and ill-advised. Another reason why directly editing core modules and themes, or for that matter, even contributed modules and themes, is that whenever an upgrade of Drupal or said modules and themes takes place, we will very likely be overwriting the changes we have made, or at the very least, make the upgrade a trying exercise. With respect to themes, let us take the example of a core theme such as Garland. As previously mentioned, it is a poor practice to edit the theme directly. The Drupal way is to extend the existing core theme using a sub-theme which, by default, is more or less an identical copy. This sub-theme can then be extended further and customized by overriding elements of the base theme,such as its stylesheets, template files, template variables, and so on. In this article, we will look at the building blocks of a basic theme and then familiarize ourselves with the concept of the sub-theme and the various techniques available to extend, override and modify it according to our requirements. Understanding the anatomy of a theme Drupal themes can consist of a multitude of files each with its own purpose, format, and syntax. This recipe will introduce each of these types with an explanation of what they do. Getting ready It will be useful to navigate to the Garland folder at themes/garland to browse and view the files inside a typical, fully featured theme. Garland also uses the PHPTemplate theming engine which is the most commonly used and recommended engine across Drupal's core and contributed themes. How to do it... The following table outlines the types of files typically found inside a theme's folder and the naming conventions to be followed for some of them. Type Mandatory? Description mytheme.info Yes Configuration file which provides information to Drupal about a theme named mytheme. page.tpl.php Yes A template file which determines the layout of all Drupal pages. node.tpl.php No A template file which determines the layout of a node inside a Drupal page. block.tpl.php No A template file which determines the layout of a block. *.tpl.php No Other template files which allow the customization and styling of themable aspects of Drupal. style.css No CSS stylesheet-if this file exists, it will be automatically included in the theme. script.js No Javascript file-if this file exists, it will be automatically included in the theme. *.js No Other Javascript files which will need to be explicitly included in the .info file. favicon.ico No Shortcut icon-if this file exists, it will be automatically included in the theme unless overridden from within Drupal. logo.png No Site logo-if this file exists, it will be automatically included in the theme unless overridden from within Drupal. screenshot.png No Theme preview image-if this file exists, it will be automatically included in the theme. template.php No PHPTemplate master file where some of the more complicated and powerful tweaks and overrides occur. Perusing the contents of each of the available files will prove very useful as we go along developing our theme. How it works... When a theme is added, Drupal first parses its .info file. This file, as its extension suggests, provides information about the theme such as its name, Drupal version compatibility, regions declared, CSS stylesheets used, JavaScript files included, and so on. In other words, Drupal uses it to find out the configuration and features of a theme. The .info file also specifies the theming engine being used by the theme which, by default, is PHPTemplate. Theme engines allow theme developers to communicate with Drupal using a simpler and more convenient interface commonly via template files. A number of them also introduce their own language formats for use in these template files. Template files in PHPTemplate themes are those that use the .tpl.php extension. Unlike other engines, these files just use PHP and HTML and do not rely on any special markup languages. There's more... Other theme engines besides PHPTemplate are also available. However, only a handful of themes in Drupal's contribution repository rely on them. Other theme engine types The PHPTemplate engine is the most widely prevalent theming engine used in the Drupal ecosystem and is a part of the Drupal core package. Themes using other engines such as Smarty or Xtemplate are rare and will be structured quite differently. A list of engines can be found at http://drupal.org/project/Theme+engines. Engine-less theme The Chameleon theme which is a part of core is a theme which does not use a templating engine and relies on straight PHP to get things done. Creating a sub-theme based on a core theme This recipe details the steps involved in creating a sub-theme of an existing core theme. Getting ready Create a folder named mytheme inside sites/all/themes. This name is usually also the name of the new theme and it is best to keep things uncomplicated by not using spaces and special characters. While mytheme is suitable for the purpose of this recipe, it will be a good idea to give the theme a unique and pertinent name based on its design and use. It is also important to ensure that there are no name-conflicts with other existing core or contributed themes. How to do it... A sub-theme of a core theme can be created through the following procedure: Create a file named mytheme.info inside the mytheme folder. Edit this new file and add the following code inside it: name = Mythemedescription = My new sub-theme (CSS, phptemplate, 3-col)base theme = garlandcore = 6.xengine = phptemplatestylesheets[all][] = mytheme.css It is useful to add an informative description field as it will be visible in the theme administration page. Specifying the key characteristics of the theme can save time and effort as the administrator gets a quick overview of the design. Save the file. Create an empty CSS file named mytheme.css inside the mytheme folder. Next, visit admin/build/themes (Home | Administer | Site building | Themes) to check if our new theme is available. As the preceding screenshot attests, the theme administration page should now include our new theme—Mytheme. Enabling it should confirm that it is more or less identical to Garland and can now be extended further as per our requirements. How it works... Drupal uses the .info file to learn about our new sub-theme. The name and description variables, rather unsurprisingly, represent the name of the theme and a description that customarily includes details about the layout of the theme. The base theme variable denotes the parent theme which our sub-theme is based on. By using this variable, we are informing Drupal that it should use the layout and styling of the base theme—in this case Garland—unless we indicate otherwise. This process is commonly referred to as overriding the base theme. Finally, the core variable denotes the compatibility of our theme with Drupal 6, while engine indicates that the theme uses PHPTemplate as its templating engine. PHPTemplate is the most widely used system. Other engines, which include Smarty, PHPTal, and Xtemplate, are seldom used and themes using them are few and far between. The stylesheets variable declares the CSS stylesheets to be included with the theme. When it comes to sub-themes, the stylesheets of base themes are automatically included unless explicitly overridden. However, due to a quirk in Drupal's theming system, base theme stylesheets are not inherited by the sub-theme unless the latter declares at least one stylesheet of its own. We have worked around this by including an empty stylesheet named mytheme.css. There's more... Drupal core provides an excellent example of a sub-theme based on a core theme. Garland and Minnelli Garland already has a sub-theme named Minnelli which is in a folder titled minnelli inside themes/garland. The difference between the two is that Garland uses a fluid layout while Minnelli is a fixed-width version of the same theme. Chaining Sub-themes can be chained, if necessary. For example, our mytheme could have used Minnelli as the base theme even though it is a sub-theme itself.

Executing Koha's web installer In this section of the article, we will learn how to execute Koha's web installer. The web installer performs several important functions such as creating Koha's database structure or populating mandatory administrative settings. It can also populate optional settings and sample data such as MARC frameworks or patron categories. The installer is launched from the staff client interface using Koha's MySQL user and is a series of interactive steps. At the end of the process we will be able to launch Koha's staff interface and its OPAC. Understanding the web installer's functions Koha's web installer performs the following functions: Checks for the existence of Koha's database, the connectivity to the database, and if the database user has the required privilege on the Koha database. Creates Koha's database structure—its tables, relationships between tables, database constraints, and other rules. Accepts user input on important configuration questions such as Language or MARC flavor. Populates the Koha database with several mandatory administrative settings such as the default system preferences. Populates the Koha database with several optional administrative settings and sample data such as MARC bibliographic frameworks, sample libraries, or sample patron categories. Configures Koha catalog search to use Zebra or to use database indexing. Understanding how to execute the web installer Here are some important points to note about executing Koha's web installer: The web installer is launched from the staff interface. We use a MySQL database user and password to login into the installer; this user must have privileges over Koha's database. Choosing the correct MARC flavor—MARC21 or UNIMARC is very important; it is not possible to change this configuration once the database is created. If you are evaluating or testing Koha, you should choose to import most or all of the optional settings and sample data. This way you can start using Koha right away. The optional settings and sample data can be deleted or edited from Koha's staff client at any time, but this can be significant amount of work. If you have made a mistake in the configuration settings and want to start over, simply drop and recreate Koha's database from the MySQL prompt; you will be able to launch the web installer once again. Understanding optional data available for import Let us understand some of the optional setting and sample data that we can choose to install using the web installer. Settings for MARC frameworks MARC frameworks define how data is captured for different types of material. The frameworks control things such as, which MARC fields are used, which of these fields is mandatory, or which fields are under authority control. The installer has three sets of optional settings that we can import: Matching rules: Matching rules are used during import of catalog records to match incoming records to those already in the database. Further action can be taken on matched records such as overwriting old records or adding holdings records. Two matching rules are available: one matches on ISBN and other on ISSN. Fast Add framework: This framework is designed for quickly adding catalog records; it has fewer fields when compared to other frameworks. Simple MARC 21 Bibliographic frameworks: A set of bibliographic frameworks for common types of material such as books, CDs, or serials. Other data Here is a listing of data we can import under the Other data section: Authorized values: Authorized values are lists of values that control data entry into catalog fields. Here we can import lists along with sample values for fields such as collections, shelving locations, or item statuses. Currencies: A set of currencies with sample exchange rates for use in Koha's Acquisitions module. Sample patron types and categories: A set of sample patron categories such as Student, Teacher, or Staff. Patron categories are used to define rules such as membership duration; the categories are also used to define circulation policy such as loan period. Sample Label and Patron Card Data: A set of sample layouts and templates for use in Koha's label and patron card generation, and printing tool. Sample Holidays: A sample set of holidays for use in Koha's calendar. The calendar is used in Koha's circulation module to calculate due dates and fines. Default Item Types: A sample set of item types. Item types are used to define circulation policy such as loan period or fine amount. Sample Libraries: A sample set of libraries, patrons, catalog items, circulation rules are linked to libraries. Sample News Items: A set of sample news items, for display on the OPAC and the staff interface. Default messages or notices: A set of sample notices. These are used in various Koha modules, for instance the Overdue notice can be configured to be sent to patrons with overdue items. Sample Patrons: A set of patron records. Sample Z3950 servers: A sample set of Z39.50 servers such as that of the Library of Congress. These servers are used in Koha's cataloging module for copy catalog records into Koha. Executing the web installer Here are step-by-step instructions on executing the web installer: Log in using the MySQL user and password; in this article we have used the user kohaadmin. In Step 1, choose your language; you should see just one option here—en for English or fr for French. In Step 2, the installer checks the database connectivity and user privileges. In Step 3, the installer populates the database with tables before prompting the user to install basic configuration settings. Select your MARC flavor—Unimarc or MARC 21. It is important to make the right choice here. Consult with your library staff if you are unsure of what to choose. Choose to import optional data related to MARC frameworks. Choose to import other optional data such as authorized values, currencies, or patron categories. Click on Import to install the settings and sample data. Choose to use Zebra or the regular database indexing. Click on Finish to complete the execution of the web installer. Launching Koha Once the installer finishes it should automatically redirect to the staff interface: Log in using the MySQL user and you should see Koha's staff interface home page: To launch the OPAC navigate to the OPAC url and you should see a screen such as this:  

  Apache Roller 4.0 – Beginner's Guide A comprehensive, step-by-step guide on how to set up, customize, and market your blog using Apache Roller   Create, optimize, and maintain your own blog server using Apache Roller Incorporate multimedia content from popular web tools like YouTube, Google Maps, Twitter. and SlideShare in your posts Customize the appearance of your blog with visually appealing, powerful themes and templates Increase your blog's search engine ranking and keep track of visitors using Google Webmaster Tools         Read more about this book       For the following exercise, you'll need to download Chapter 7's support code from the book's website. Extract the chapter07.zip file's contents into a directory in your hard disk. For example, I used Ubuntu Linux in the exercise, created a chapter07 directory inside my Desktop directory, and copied the mytheme directory inside Desktop/chapter07. All the steps in the exercise are based on these assumptions. Creating a directory for your theme Every Roller theme has a directory and some required files such as weblog.vm, _day.vm, and theme.xml. The next exercise will show you how to create a directory for your new theme inside Roller's themes directory, and how to copy these required files from the support files. Time for action – creating a directory for your theme Now, I'll show you all the necessary steps to create your new theme directory inside Roller's themes directory in a Linux Ubuntu system, and then copy all the required files. If you're using Windows or any other flavor of Linux, the procedure is very similar: Go to your Roller themes directory and create a directory named mytheme: Open a terminal window, go to the themes subdirectory inside Desktop/chapter07, and type sudo cp * /usr/local/tomcat/webapps/roller/themes/mytheme to copy all the mytheme files to your Roller installation: In the end, your mytheme directory will have four files, as shown in the following screenshot: Now restart Tomcat and wait until it's running again. Then open your web browser, log into Roller, and go to the Design tab to see the Weblog Theme page: Click on the Shared Theme option and select My First Roller Theme from the drop-down listbox: Click on the Update Theme button to change your current Roller theme, and then click on the See how your blog will look with this theme link: Roller will open a new web browser tab to show you a preview of the new theme you selected: Close the preview tab and leave the Front Page: Weblog Theme page open for the next exercise. What just happened? The mytheme theme has a very basic functionality. That's because the CSS stylesheet (mystylesheet.css) is empty, so I'm going to show you how to add styles to your headings, links, and all the other elements displayed in your weblog. However, first we need to see a quick introduction to the four files that every Roller theme must have in order to run without any trouble: File Definition Tip weblog.vm Describes the main page of your weblog. In this file, you set the structure for your weblog, using macros and elements from Roller and the Velocity template language. _day.vm   Describes how to display one day's worth of entries in your weblog. Here you can configure how to display each entry's title, content, and comments, for example. You can set the font's color and size of each element, based on the CSS stylesheet definitions. mystylesheet.css Stylesheet override file that defines the CSS style code used by your weblog. Here you define all your weblog's styles, such as size and color for headings and fonts used in your posts. theme.xml Theme definition file that describes each file used in your weblog. You need to include some basic data about your theme, the stylesheet file, the weblog and _day templates, and every other file and/or resource used in your weblog. The stylesheet override file The first thing we need to do in order to change your new theme's visual appearance is edit the stylesheet override file: mystylesheet.css. We can do this in two ways: Edit the file directly from the mytheme directory inside Roller's themes directory, or use Roller's Custom Theme feature. If we use the first option, we'll need to restart Tomcat every time we make a modification to mystylesheet.css. On the other hand, if we choose the second option, we can edit the stylesheet inside Roller's admin interface and see how our changes affect our weblog's visual appearance immediately, so I'm going to show you how to use the second option. Time for action – editing the stylesheet override file It's very easy to edit the stylesheet override file for your custom theme inside Roller, and the next exercise will show you how to do it: Go to the Front Page: Weblog Theme tab in your web browser, select the Custom Theme option, click on the I want to copy the templates from an existing theme into my weblog checkbox, and click on the Update Theme button: Roller will show you the following success message: Now click on the Templates link to see a list of the templates you currently have in your custom space: Looking at the template list in the previous screenshot, there are some templates from the other custom theme and we need to remove them now. Click on the Remove link of the custom.css, mytemplate, and _css templates to delete them from your custom space, as we won't need them anymore, and they don't belong to mytheme. After removing all the unneeded files, there should be only two templates in your list: Now click on the Stylesheet link to see and start editing your mystylesheet.css file's code: As you can see, your custom stylesheet is empty. If you click on the Front Page link in Roller's menu bar, you'll see your weblog's current front page: Now click on your web browser's Back button to return to the stylesheet editing page, and add the following code to your custom stylesheet: div.dayTitle { color:brown; font-weight:bold; font-size:90%; text-transform:uppercase; border-bottom:1px dotted #666;}.entryTitle { font-weight: bold;} Your stylesheet should now contain the line beginning with /*, along with the code you've just entered: Click on the Save button to apply the changes to your stylesheet, and then select the Front Page link to see how the code you entered affects your weblog's visual appearance: If you compare the previous screenshot with the one from step 7, you'll see that the code you entered into the override stylesheet changed the way your weblog displays the day and entry titles. Now click on the Back button of your web browser to return to the stylesheet editing page, and add the following lines of code above the lines you entered in step 8: a { text-decoration: none;}a:link { color: blue; font-weight: medium;}a:visited { color: purple; font-weight: medium;}a:hover { text-decoration: underline overline;}body { font-family:"Lucida Grande", lucida, Geneva, Arial, sans-serif; background:#FFFFCC;} Your stylesheet should now look like this: Click on the Save button and then select the Front Page link to see your weblog's front page: Click on the Back button to return to your stylesheet editing page. What just happened? In the previous exercise, you edited your stylesheet override file (mystylesheet.css) to change your weblog's visual appearance. To understand what these code segments do, let's take a look at the _day template's code: <div class="dayBox"> <div class="dayTitle"> $utils.formatDate($day, "EEEE MMM dd, yyyy") </div> #foreach( $entry in $entries ) <div class="entryBox"> <p class="entryTitle">$entry.title</p> <p class="entryContent"> #if($model.permalink) $entry.displayContent #else $entry.displayContent($url.entry($entry.anchor)) #end </p> <p class="entryInfo"> Posted at <a href="$url.entry($entry.anchor)">$utils.formatDate ($entry.pubTime, "hh:mma MMM dd, yyyy")</a> by $entry.creator.userName in <span class="category">$entry.category.name</span> &nbsp;|&nbsp; #if ($utils.isUserAuthorizedToAuthor($entry.website)) <a href="$url.editEntry($entry.anchor)">Edit</a> &nbsp;|&nbsp; #end #if($entry.commentsStillAllowed || $entry.commentCount > 0) #set($link = "$url.comments($entry.anchor)" ) <a href="$link" class="commentsLink">Comments[$entry.commentCount] </a> #end </p> </div> #end</div> The lines in bold are the ones directly involved with the CSS code you entered in the exercise: <div class="dayTitle"> $utils.formatDate($day, "EEEE MMM dd, yyyy")</div> The div element represents a "division" or a section in a web page. The only code inside this division is $utils.formatDate($day, "EEEE MMM dd, yyyy"). This is a property from the $utils object used to show the date and time of each day containing one or more posts in the weblog, in the format specified by the "EEEE MMM dd, yyyy" string. The class="dayTitle" code segment indicates that this division will use the styles defined in the .dayTitle class from the stylesheet: div.dayTitle { color:brown; font-weight:bold; font-size:90%; text-transform:uppercase; border-bottom:1px dotted #666;} This CSS code indicates that every text element inside this division will be shown in brown color, in bold style, with a smaller size (90%) than the other fonts outside the division, and the text will be converted to uppercase. The last CSS element indicates that there will be a one pixel-wide, dotted grey border at the bottom of each text element (#666 is a hexadecimal color code). All this stuff means that each day in the weblog will be shown like this: Now, the next line in the _day template: <p class="entryTitle">$entry.title</p> The <p> HTML tag indicates a paragraph inside your web page, and $entry.title is the only code inside this paragraph. As we saw before, $entry.title shows the title of an entry in your weblog. The class="entryTitle" element is related to the .entryTitle code block in your stylesheet: .entryTitle { font-weight: bold;} This CSS code indicates that all the text inside the paragraph will be shown in bold. In this case, each entry's title of your weblog will be shown in bold: The rest of the bold lines in the _day template use an <a> element, known as an anchor in HTML. This element is used to display links in web pages, and is related to all the a elements in the stylesheet: a { text-decoration: none;}a:link { color: blue; font-weight: medium;}a:visited { color: purple; font-weight: medium;}a:hover { text-decoration: underline overline;} These elements define how the links in your weblog will be displayed. The first block of code indicates that the links won't have a text decoration (that is, links won't be underlined, as in most web pages), the color of each link will be blue, the font weight will be medium, and the color of visited links will be purple. The last block of code indicates that, if someone positions the mouse cursor over a link, it will be underlined and overlined. The following screenshot shows what happens when you put your mouse cursor over the date and time hyperlink created with the <a href="$url.entry($entry.anchor)">$utils.formatDate($entry.pubTime, "hh:mma MMM dd, yyyy")</a> line in the _day template: You can see the underline and overline effects from the a:hover CSS element, along with the purple color due to the a:visited CSS element. The <a href="$url.editEntry($entry.anchor)">Edit</a>  |  line from the _day template has similar effects: The last block of code we used in the previous exercise is: body { font-family:"Lucida Grande", lucida, Geneva, Arial, sans-serif; background:#FFFFCC;} In this case, the body CSS element defines the font used to display your weblog's data. There are several fonts included, to maximize browser compatibility. You can experiment with different fonts and font families to see how your changes affect your weblog's way of displaying data. Summary In this article we saw how to create a Roller theme from scratch. We also saw how to edit the mystylesheet.css stylesheet override file and how the _day.vm template uses CSS styles and Velocity code to display your weblog's data.

  IBM InfoSphere Replication Server and Data Event Publisher Design, implement, and monitor a successful Q replication and Event Publishing project Covers the toolsets needed to implement a successful Q replication project Aimed at the Linux, Unix, and Windows operating systems, with many concepts common to z/OS as well A chapter dedicated exclusively to WebSphere MQ for the DB2 DBA Detailed step-by-step instructions for 13 Q replication scenarios with troubleshooting and monitoring tips Written in a conversational and easy to follow manner Checking the state of a Q subscription The state of a Q subscription is recorded in the IBMQREP_SUBS table, and can be queried as follows: db2 "SELECT SUBSTR(subname,1,10) AS subname, state FROM asn.ibmqrep_subs" SUBNAME STATE -------- ----- DEPT0001 A XEMP0001 A Stopping a Q subscription The command to stop a Q subscription is STOP QSUB SUBNAME <qsubname>. Note that if Q Capture is not running, then the command will not take effect until Q Capture is started, because the STOP QSUB command generates an INSERT command into the IBMQREP_SIGNAL table: INSERT INTO ASN.IBMQREP_SIGNAL (signal_type, signal_subtype, signal_input_in) VALUES ('CMD', 'CAPSTOP', 'T10001'); In a unidirectional setup, to stop a Q subscription called T10001 where the Q Capture and Q Apply control tables have a schema of ASN, create a text file called SYSA_qsub_stop_uni.asnclp containing the following ASNCLP commands: ASNCLP SESSION SET TO Q REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER CAPTURE TO DB DB2A; SET SERVER TARGET TO DB DB2B; SET CAPTURE SCHEMA SOURCE ASN; SET APPLY SCHEMA ASN; stop qsub subname T10001; In bidirectional or peer-to-peer two-way replication, we have to specify both Q subscriptions (T10001 and T10002) for the subscription group: ASNCLP SESSION SET TO Q REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET CAPTURE SCHEMA SOURCE ASN; SET APPLY SCHEMA ASN; SET SERVER CAPTURE TO DB DB2A; SET SERVER TARGET TO DB DB2B; stop qsub subname T10001; SET SERVER CAPTURE TO DB DB2B; SET SERVER TARGET TO DB DB2A; stop qsub subname T10002; In a Peer-to-peer four-way setup, the commands would be in a file called qsub_stop_p2p4w.asnclp containing the following ASNCLP commands: ASNCLP SESSION SET TO Q REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET CAPTURE SCHEMA SOURCE ASN; SET APPLY SCHEMA ASN; SET SERVER CAPTURE TO DB DB2A; SET SERVER TARGET TO DB DB2B; stop qsub subname T10001; SET SERVER CAPTURE TO DB DB2A; SET SERVER TARGET TO DB DB2C; stop qsub subname T10002; SET SERVER CAPTURE TO DB DB2A; SET SERVER TARGET TO DB DB2D; stop qsub subname T10003; Dropping a Q subscription The ASNCLP command to drop a Q subscription is: DROP QSUB (SUBNAME <qsubname> USING REPLQMAP <repqmapname>); In a unidirectional setup, to drop a Q subscription called T10001, which uses a Replication Queue Map called RQMA2B, create a file called drop_qsub_uni.asnclp containing the following ASNCLP commands: ASNCLP SESSION SET TO Q REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER CAPTURE TO DB DB2A; SET SERVER TARGET TO DB DB2B; SET CAPTURE SCHEMA SOURCE ASN; SET APPLY SCHEMA ASN; drop qsub (subname TAB1 using replqmap RQMA2B); We can use the SET DROP command to specify whether for unidirectional replication the target table and its table space are dropped when a Q subscription is deleted: SET DROP TARGET [NEVER|ALWAYS] The default is not to drop the target table. In a multi-directional setup, there are three methods we can use: In the first method, we need to issue the DROP QSUB command twice, once for the Q subscription from DB2A to DB2B and once for the Q subscription from DB2B to DB2A. In this method, we need to know the Q subscription and Replication Queue Map names, which is shown in the qsub_drop_bidi0.asnclp file: ASNCLP SESSION SET TO Q REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET CAPTURE SCHEMA SOURCE ASN; SET APPLY SCHEMA ASN; SET SERVER CAPTURE TO DB DB2A; SET SERVER TARGET TO DB DB2B; drop qsub (subname T10001 using replqmap RQMA2B); SET SERVER CAPTURE TO DB DB2B; SET SERVER TARGET TO DB DB2A; drop qsub (subname T10002 using replqmap RQMB2A); In the second method, we use the DROP SUBTYPE command, which is used to delete the multi-directional Q subscriptions for a single logical table. We use the DROP SUBTYPE command with the SET REFERENCE TABLE construct, which identifies a Q subscription for multi-directional replication. An example of using these two is shown in the following content file, which drops all the Q subscriptions for the source table eric.t1. This content file needs to be called from a load script file. SET SUBGROUP "TABT1"; SET SERVER MULTIDIR TO DB "DB2A"; SET SERVER MULTIDIR TO DB "DB2B"; SET REFERENCE TABLE USING SCHEMA "DB2A".ASN USES TABLE eric.t1; DROP SUBTYPE B QSUBS; The USING SCHEMA part of the SET REFERENCE TABLE command identifies the server that contains the table (DB2A) and the schema (ASN) of the control tables in which this table is specified as a source and target. The USES TABLE part specifies the table schema (eric) and table name (t1) to which the Q subscription applies. When we use this command, no tables or table spaces are ever dropped. The SUBGROUP name must be the valid for the tables whose Q subscriptions we want to drop. We can find the SUBGROUP name for a table using the following query: db2 "SELECT SUBSTR(subgroup,1,10) AS subsgroup, SUBSTR(source_ owner,1,10) as schema, SUBSTR(source_name,1,10) as name FROM asn. ibmqrep_subs" SUBSGROUP SCHEMA NAME ------ ------- ------ TABT2 DB2ADMIN DEPT TABT2 DB2ADMIN XEMP The preceding ASNCLP command generates the following SQL: -- CONNECT TO DB2B USER XXXX using XXXX; DELETE FROM ASN.IBMQREP_TRG_COLS WHERE subname = 'T10001' AND recvq = 'CAPA.TO.APPB.RECVQ'; DELETE FROM ASN.IBMQREP_TARGETS WHERE subname = 'T10001' AND recvq = 'CAPA.TO.APPB.RECVQ'; DELETE FROM ASN.IBMQREP_SRC_COLS WHERE subname = 'T10002'; DELETE FROM ASN.IBMQREP_SUBS WHERE subname = 'T10002'; -- CONNECT TO DB2A USER XXXX using XXXX; DELETE FROM ASN.IBMQREP_SRC_COLS WHERE subname = 'T10001'; DELETE FROM ASN.IBMQREP_SUBS WHERE subname = 'T10001'; DELETE FROM ASN.IBMQREP_TRG_COLS WHERE subname = 'T10002' AND recvq = 'CAPB.TO.APPA.RECVQ'; DELETE FROM ASN.IBMQREP_TARGETS WHERE subname = 'T10002' AND recvq = 'CAPB.TO.APPA.RECVQ'; A third method uses the DROP SUBGROUP command, as shown: SET SUBGROUP "TABT2"; SET SERVER MULTIDIR TO DB "DB2A"; SET SERVER MULTIDIR TO DB "DB2B"; SET MULTIDIR SCHEMA "DB2A".ASN ; DROP SUBGROUP; With this command, we just need to specify the Q subscription group name (SUBGROUP). The preceding ASNCLP command generates the following SQL: -- CONNECT TO DB2A USER XXXX using XXXX; DELETE FROM ASN.IBMQREP_TRG_COLS WHERE subname = 'T10002' AND recvq = 'CAPB.TO.APPA.RECVQ'; DELETE FROM ASN.IBMQREP_TARGETS WHERE subname = 'T10002' AND recvq = 'CAPB.TO.APPA.RECVQ'; DELETE FROM ASN.IBMQREP_SRC_COLS WHERE subname = 'T10001'; DELETE FROM ASN.IBMQREP_SUBS WHERE subname = 'T10001'; -- CONNECT TO DB2B USER XXXX using XXXX; DELETE FROM ASN.IBMQREP_SRC_COLS WHERE subname = 'T10002'; DELETE FROM ASN.IBMQREP_SUBS WHERE subname = 'T10002'; DELETE FROM ASN.IBMQREP_TRG_COLS WHERE subname = 'T10001' AND recvq = 'CAPA.TO.APPB.RECVQ'; DELETE FROM ASN.IBMQREP_TARGETS WHERE subname = 'T10001' AND recvq = 'CAPA.TO.APPB.RECVQ'; In a peer-to-peer three-way scenario, we would add a third SET SERVER MULTIDIR TO DB line pointing to the third server. If we use the second or third method, then we do not need to know the Q subscription names, just the table name in the second method and the Q subscription group name in the third method. Altering a Q subscription We can only alter Q subscriptions which are inactive. The following query shows the state of all Q subscriptions: db2 "SELECT SUBSTR(subname,1,10) AS subname, state FROM asn.ibmqrep_subs" SUBNAME STATE ---------- ----- DEPT0001 I At the time of writing, if we try and alter an active Q subscription, we will get the following error when we run the ASNCLP commands: ErrorReport : ASN2003I The action "Alter Subscription" started at "Friday, 22 January 2010 12:53:16 o'clock GMT". Q subscription name: "DEPT0001". Q Capture server: "DB2A". Q Capture schema: "ASN". Q Apply server: "DB2B". Q Apply schema: "ASN". The source table is "DB2ADMIN.DEPT". The target table or stored procedure is "DB2ADMIN.DEPT". ASN0999E "The attribute "erroraction" cannot be updated." : "The Subscription cannot be updated because it is in active state" : Error condition "*", error code(s): "*", "*", "*". This should be resolved in a future release. So now let's move on and look at the command to alter a Q subscription. To alter a Q subscription, we use the ALTER QSUB ASNCLP command. The parameters for the command depend on whether we are running unidirectional or multi-directional replication. We can change attributes for both the source and target tables, but what we can change depends on the type of replication (unidirectional, bidirectional, or peer-to-peer), as shown in the following table: ParameterUniBiP2PSource table:ALL CHANGED ROWS [N | Y]YY HAS LOAD PHASE [N | I |E]YYYTarget table:CONFLICT RULE [K | C | A] Y CONFLICT ACTION [I | F | D | S | Q] Y ERROR ACTION [Q | D | S]YYYLOAD TYPE [0 | 2 | 3 | 4 | 104 | 5 | 105]YYYOKSQLSTATES ["sqlstates"]YYY For unidirectional replication, the format of the command is: ALTER QSUB <subname> REPLQMAP <mapname> USING REPLQMAP <mapname> DESC <description> MANAGE TARGET CCD [CREATE SQL REGISTRATION|DROP SQL REGISTRATION|ALTER SQL REGISTRATION FOR Q REPLICATION] USING OPTIONS [other-opt-clause|add-cols-clause] other-opt-clause: SEARCH CONDITION "<search_condition>" ALL CHANGED ROWS [N|Y] HAS LOAD PHASE-- [N|I|E] SUPPRESS DELETES [N|Y] CONFLICT ACTION [I|F|D|S|Q] ERROR ACTION [S|D|Q] OKSQLSTATES "<sqlstates>" LOAD TYPE [0|1|2|3|4|104|5|105] add-cols-clause: ADD COLS (<trgcolname1> <srccolname1>,<trgcolname2> <srccolname2>) An example of altering a Q subscription to add a search condition is: ASNCLP SESSION SET TO Q REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET CAPTURE SCHEMA SOURCE ASN; SET APPLY SCHEMA ASN; SET SERVER CAPTURE TO DB DB2A; SET SERVER TARGET TO DB DB2B; ALTER QSUB tab1 REPLQMAP rqma2b USING OPTIONS SEARCH CONDITION "WHERE :c1 > 1000" ; In multi-directional replication, the format of the command is: ALTER QSUB SUBTYPE B FROM NODE <svn.schema> SOURCE [src-clause] TARGET [trg-clause] FROM NODE <svn.schema> SOURCE [src-clause] TARGET [trg-clause] src-clause: ALL CHANGED ROWS [N/Y] HAS LOAD PHASE [N/I/E] trg-clause: CONFLICT RULE [K/C/A] +-' '-CONFLICT ACTION [I/F/D/S/Q] ERROR ACTION [Q/D/S] LOAD TYPE [0/2/3] OKSQLSTATES <"sqlstates"> If we are altering a Q subscription in a multi-directional environment, then we can use the SET REFERENCE TABLE construct. We need to specify the SUBTYPE parameter as follows: Bidirectional replication: ALTER QSUB SUBTYPE B Peer-to-peer replication: ALTER QSUB SUBTYPE P Let's look at a bidirectional replication example, where we want to change the ERROR ACTION to D for a Q subscription where the source table name is db2admin.dept. The content file (SYSA_cont_alter02.txt) will contain: SET SUBGROUP "TABT2"; SET SERVER MULTIDIR TO DB "DB2A"; SET SERVER MULTIDIR TO DB "DB2B"; SET REFERENCE TABLE USING SCHEMA "DB2A".ASN USES TABLE db2admin.dept; ALTER QSUB SUBTYPE B FROM NODE DB2A.ASN SOURCE TARGET ERROR ACTION D FROM NODE DB2B.ASN SOURCE TARGET ERROR ACTION D; We have to specify the SOURCE keyword even though we are only changing the target attributes. The ALTER QSUB statement spans the three last lines of the file. Starting a Q subscription An example of the ASNCLP command START QSUB to start a Q subscription can be found in the SYSA_qsub_start_db2ac.asnclp file. We just have to plug in the Q subscription name (T10002 in our example). ASNCLP SESSION SET TO Q REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET CAPTURE SCHEMA SOURCE ASN; SET APPLY SCHEMA ASN; SET SERVER CAPTURE TO DB DB2A; SET SERVER TARGET TO DB DB2C; START QSUB SUBNAME T10002; Run the file as: asnclp -f SYSA_qsub_start_db2ac.asnclp We cannot put two START QSUB statements in the same file (as shown), even if they have their own section. So, we cannot code: ASNCLP SESSION SET TO Q REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER CAPTURE TO DB DB2A; SET SERVER TARGET TO DB DB2D; SET CAPTURE SCHEMA SOURCE ASN; SET APPLY SCHEMA ASN; START QSUB SUBNAME T10003; SET SERVER CAPTURE TO DB DB2A; SET SERVER TARGET TO DB DB2C; START QSUB SUBNAME T10002; Sending a signal using ASNCLP For signals such as CAPSTART, CAPSTOP, and LOADDONE to be picked up, Q Capture needs to be running. Note that Q Capture does not have to be up for the signals to be issued, just picked up. As they are written to the DB2 log, Q Capture will see them when it reads the log and will action them in the order they were received. Summary In this article we took a look at how we can stop or drop or alter a Q subscription using ASNCLP commands and how we can issue a CAPSTART command. Further resources on this subject: Lotus Notes Domino 8: Upgrader's Guide [Book] Q Replication Components in IBM Replication Server [Article] IBM WebSphere MQ commands [Article] WebSphere MQ Sample Programs [Article] MQ Listener, Channel and Queue Management [Article]

Joomla! 1.5 Cookbook Over 60 quick and direct recipes to help you overcome common Joomla! queries. Find quick solutions to common Joomla! problems Part of Packt's Cookbook series: Each recipe is a carefully organized sequence of instructions to complete the task as efficiently as possible Look at recipes that cover the portions of Joomla! 1.6 that are brand new Over 60 practical recipes covering a range of site management and core Joomla! activities         In this recipe, we'll look at all aspects of a module. How to do it... Installing a Module Login to your Administrator Console. Click Extensions | Install/Uninstall. Once you are in here, you'll have a few options to choose from: There are three methods to install a module, in this section we'll focus on the first method. We'll examine the other two in a moment. Click Browse... and find the file. Click Upload File & Install.Once you successfully installed the module, Joomla! will indicate this with this message: How it works... Module installation is a very similar process to components. The Joomla! universal installer has made it very simple. The installer will write the appropriate settings to the database and will copy the files down to their respective locations. There's more... There comes a time when you no longer need a module. Or you may wish to disable it or even create a new one that didn't exist before. As modules are essentially very lightweight in nature, creating them and placing them is easy. The next few recipes cover these items. Deleting modules There are two methods to delete a module. METHOD 1: Click Extensions | Install/Uninstall. Click Modules. Check the module you wish to delete. Once you check the module(s) you wish to delete, click Uninstall in the upper right-hand side: Once you successfully uninstall the module, Joomla! will indicate this with this message: METHOD 2: Click Extensions | Module Manager. Check the module you wish to delete. Click Delete in the upper right-hand side, the key difference is the message:

  Inkscape 0.48 Essentials for Web Designers Use the fascinating Inkscape graphics editor to create attractive layout designs, images, and icons for your website The first book on the newly released Inkscape version 0.48, with an exclusive focus on web design Comprehensive coverage of all aspects of Inkscape required for web design Incorporate eye-catching designs, patterns, and other visual elements to spice up your web pages Learn how to create your own Inkscape templates in addition to using the built-in ones Written in a simple illustrative manner, which will appeal to web designers and experienced Inkscape users alike Designing the background In Inkscape, since your canvas is white, it looks like your web page might have a white background. It does not, without creating a background image, currently it would be transparent or 0 percent opacity. So we need to start by determining which colors to use for the background. You can get really creative here, as you don't need to use just one color! Create a header background color, one for the main body, and then another for the footer area. Let's start by creating a simple background based on our Basic Layout layer. Making the header background To start, we're going to create a simple header background—a rectangle with a simple divider line and drop shadow. Here are the detailed steps to make this header background: With your new document open and the newly created guides viewable, first lock the Basic Layout layer (click the lock icon) and hide its elements (click the Eye icon). Now create a Background Layer. Draw a rectangle that fills the header and navigational areas. We're going to create only one background for both of these, as the navigation will be in the same color and area as the header. Choose a fill color and no stroke (border). If you decide you want to change either of the option, open the fill and stroke dialog box (from the main menu select File and then Fill and Stroke or the keypad shortcut Shift + Ctrl + F) and adjust colors accordingly. Want to add in a gradient? Click the Gradient icon, and adjust how you want your gradient to appear. By default the Inkscape gradient applies an alpha setting of 0 to the stop gradient, which will be fully transparent. This means, in the above settings, the right side of the gradient would be transparent. Click Edit to change this setting. From the Linear gradient field, choose the Add stop. Change the alpha opacity setting (A) to a solid color—either move the slider to the left side of the screen or change the value to 255. Next change the solid color value. In this example, we used white and changed the R, G, B values to achieve the results. For this example, the gradient goes from a bit darker green on the left to a lighter shade on the right side. Next, let's add a simple drop shadow. From the main menu select Filters, Shadows and Glows, and then Drop Shadow. For this example, the Blur Radius px 10, Opacity, 20% and a vertical offset px of 5 and click Apply. Close the drop shadow box and then save your file. Your header is complete! Now let's add to this to create the main content background. To change the gradient orientation, you can drag the outer two gradient stop nodes indicated by the square and circle handles on the object. You can also add more gradient stops and edit their transparency (A) values and colors to adjust to your liking. Building the main body background For the main part of the web page sample, we're using a white box as a background with a similar drop shadow. Here's how to add this to your Background layer: Draw a rectangle that fills the entire content, main content area. This includes the entire middle portion of your web page, and covers all the 'sections' between the header and the footer in the basic layout. The example above shows white as the fill color and no stroke (border). Let's also put a drop shadow on this box as well. From the main menu select Filters, Shadows and Glows, and then Drop Shadow. Adjust the settings to be the same as the previous drop shadow so they match (Blur Radius px 10, Opacity, 20% and a vertical offset px of 5) and click Apply. Close the drop shadow box and then save your file. The main content background is complete. Lastly, we need to create the footer background. Creating the footer background Creating a footer background is the last step to this process. Very much like the header, we'll follow these steps: Duplicate the header background. Select the header and from the main menu, choose Edit and then Duplicate. Drag the duplicate rectangle down to the footer area of the page and adjust the size so it fits within the footer defined area. Notice, since the object was duplicated all formatting—gradients and drop shadows—were maintained. Save your file. Now that your footer background is complete, so is the entire web page background. Let's move on to details. Designing the header Now that we have the entire background already created, it's time to add details to the header area like a logo and company name. Here are the steps to add in these basic details to our example design: Before any more work is done, it makes sense to 'lock' the background layer. We don't want any items shifting, or any elements being selected accidentally when we are working on other layers. To lock the background layer, click the lock icon in the Background layer dialog box. Create a new layer and name it Logo. To create a new layer, you can use the Shift+Ctrl+N keyboard shortcut. Within the Logo layer, create and/or import the logo and place it on the header background. If you are importing a graphic that has already been created, it's as simple as clicking File and selecting Import. Find the logo file and use the selection tool to place it correctly in the header area. Lock the logo layer, and then create a new layer and name it Title. Within this layer, use the Create and Edit Text tool and type in the business name and then place it on the header background. Save your file. Next up, is to create the Navigation tool bar.

How to create a menu in Joomla! 1.5 Carrying on with our Agora example, let's create a menu for Agora so our WidgetWorld Users can post threads on the products. How to do it... Log in to your Administrator Console. Click Menus and choose the menu you wish - in this case, use Main Menu - thus Menus | Main Menu. Click New in the upper right-hand corner. The above screenshot is a snippet of the Select Menu Item Type - Yours will vary. In this example, we see several items - we want Agora Forum. Click Agora Forum. Scroll down and fill out the details as you see here (use your own details): This will give the forum menu on the home page a title called WidgetWorld FORUM. Click Save.Now when we visit this from the front of the site we see the completed WidgetWorld FORUM on our menu: How it works... The creation and location for the component is stored in the database. When the Joomla! template renders the page, it will include the component. Thus - when you create a menu item for the component you are giving the user the ability to 'use' the component. There's more... As you gain more experience with Joomla!, you'll want to work with the menu to give it a more custom feel. Let's look at changing the location of menus. Changing the location of the menu You likely noted that the forum in the last example was at the bottom of the Main Menu. Let's change the order. Click Menu | Main Menu - see the Order column. This is the order of display. Type 2 in the Order number box for the WidgetWorld FORUM. Click the Floppy disk <save> icon next to Order - the result should be as you see in the following screenshot: Here are the menus before and after side-by-side:   Further resources on this subject: Joomla! 1.5: Installing, Creating, and Managing Modules Installation and Introduction of K2 Content Construction Kit Managing Articles Using the K2 Content Construction Kit Joomla! 1.5: Installing and Managing Components

  Inkscape 0.48 Essentials for Web Designers Use the fascinating Inkscape graphics editor to create attractive layout designs, images, and icons for your website The first book on the newly released Inkscape version 0.48, with an exclusive focus on web design Comprehensive coverage of all aspects of Inkscape required for web design Incorporate eye-catching designs, patterns, and other visual elements to spice up your web pages Learn how to create your own Inkscape templates in addition to using the built-in ones Written in a simple illustrative manner, which will appeal to web designers and experienced Inkscape users alike Architecting a web site Although as a web designer you will usually be regarded as the "look and feel" person for a web site, you are also a key partner in determining the site architecture. As you design, you often define how the site will be navigated. Is this web site one page or will an end-user "click around" the site to other areas or sub-pages and explore? Where will each page inter-link or link out to other websites? What is the main navigational element: a navigation bar? Where will it reside on all the pages? Is this site content or search driven? All these questions (and many more) require the entire team's involvement (and a client's opinion) to make the appropriate decisions. As the web designer, it is your job to work with all of these elements at a visual level—navigation bars, search fields, buttons, title bars, footers, and more—and fit them into the overall web site design. Web layout—principles and basics Designing for the web and for print are similar in that they have the same principles and goals for an end-viewer: appealing content that works together in the space. Although the principles are basic, they represent guidelines that improve any web page design. Here are the techniques: Proximity or grouping similar information together on a web page. You can get creative in how you group this information by using alignment, icons, and even just white space, but regardless, the technique and principles are the same. Information that belongs together should be together. Alignment is the simple idea of making sure all of the elements line up on the screen. If you have everything left aligned, keep it that way on the page. Use natural alignments within an entire web space when you use more than one graphical element such as photos, graphics, and/or text. Repetition can help unify a web page. Repeating elements such as buttons, shapes (graphical or just placement), or colors can really make an impact and keep the design simple and clean, thus, easier for a viewer to navigate. Contrast can have a huge and favorable impact in web design, as long as it is used effectively. Contrast is achieved with size, colors, direction, shapes, and fonts (mixing modern with old style). Even font weight can help create contrast. Just make sure that all of these elements still work well with the content on the web page itself—not for the sake of contrast. The basic design Before designing the layout in Inkscape, it can help to plan the placement of the main areas of a web page—in essence to help with the design's overall alignment of items and proximity of similar items. For our purposes, we'll create a simple main web page for a small business. This main page will have these areas: Header Footer Sidebar Content Navigation Each web page project is different and you may have to add more page elements to this list or delete some so that the final list of elements fits the needs of the overall design. For the purposes of getting agreement from a team working on this project, a good practice is to create a basic layout showing where each of the areas will be placed on the screen—and is often referred to as the web page wireframe. Typically, wireframes are completed before any graphics are created. The following screenshot illustrates a basic layout or wireframe: This high-level approach is a great start to actually building the page design. It gives us general placements of each area of the design and then we can set up grids and guidelines. Starting a new design project When you open Inkscape, it opens to a new document. However, we want to ensure that we have a page size that is the right size for our web page, so we create a new document based on predefined desktop sizes, which are common web page sizes, as follows: From the main menu select File and then New. A pop-up menu appears showing a number of default page sizes to choose from. Choose a template size based on the browser standards or specifications. Most of the templates in this menu are based on web designs. If you want to view the print media template sizes, go to the main menu and select File and Document Properties and view the Format section. We'll choose desktop_800x600. However, the dimensions should be specified by how your target viewer will view the site, whether it is via a computer, or via a mobile device. Also, sometimes your client or company will specify a specific size your web pages need to be. A new document opens in Inkscape and you are ready to begin. Let's set a few more preferences and then save the file with your project name before we start designing. Using grids and guidelines When designing any space on the web keep the page clean and—as stated in the design principles and techniques—aligned. So let's make the canvas grid viewable on the screen and set up some guidelines based on our wireframes. Viewing the grid With your new document still open on your computer, on the Inkscape main menu select View and then Grid. You'll see that a blue grid will appear across the entire canvas area. We'll use these grids to create basic areas of our layout and then create guides to begin creating our actual layout elements. Making guides Guides are lines on the screen that you will use for aligning i.e. guiding objects. These lines are only seen while you are working in Inkscape and we can set objects to "snap to" them when we are designing. Both of these simple tools (guides and the Snap to feature) will give you automatic alignment for the basic areas of your web page layout—which in turn will help your web page have the best design. To create a guide in any open document, make sure the Select tool is selected and drag from the left side or top of the screen towards your page as shown in the following screenshot. A red line represents the guide until you 'let go' of the guide and place it on the page. Then the line turns blue. You can move the guides after placing them on the page, by using the select tool and clicking and dragging the circle node on the guide. Now let's discuss how to use wireframes and create guides based on those web page layout elements. Creating a new layer When you create documents within Inskcape, you can have layers of objects. This gives great flexibility when creating web layouts. You can move groups of objects on a layer, separate objects by layer, and 'stack', re-ordered, or hide layers. Settings can be set by layer, so you can save drafts or different versions of mockups and keep all of this in one file. The layer you are currently using is called the drawing layer. It is selected in the Layer Dialog and is shown in a darker color. In your open document with viewable grids let's make the layers viewable and create a layer called Basic Layout. To make the Layers Dockable Dialog viewable, from the main menu select Layer and then Layers. On the right side of your screen the Layers Dialog is displayed. You can also press Shift + Ctrl + L on your keyboard to display the Layers Dialogue. In the Layers Dialog, press the + button to create a new layer. In the Layer Name field type the name: Basic Layout and click Add. You will notice the new layer is added above the existing one in the Layers Dialog. Creating basic design areas in Inkscape Here's where we begin to transfer our wireframes into Inkscape so we can start the design process. To start: Use the Rectangle Tool to draw rectangles for each of your layout areas in your basic design. For now, use different shades of gray for each area so you can easily distinguish between them at a glance. To change the fill color of a particular rectangle, left click the rectangle and choose a gray shade for the rectangle. Or drag the gray shade from the color palette onto the rectangle. Use sharp edged (not rounded) rectangles. If you need to change to sharp, click the Make Corners Sharp button in the Tool Controls Bar. Make sure your rectangle shapes do not have an outline or stroke. Use the Shift + Left click keypad shortcut to open the Stroke dialog and choose No Color (the icon with an X) to delete the stroke. Position the rectangles so there are no white spaces in between them. From the main menu choose Object and then Align and Distribute. In the Remove Overlaps section, click the icon. This makes sure that the bounding boxes around each object don't overlap each other and place the objects tangent to each other. Use the Tool Controls Bar W(width): number field to apply a setting of 800.0 px. The X:0.0 and Y:0.0 fields reference the bottom left corner of your page border. Here's roughly what your canvas should look like: Converting shapes to guides Once all of your areas are blocked out on the canvas, we'll need to convert the current rectangles into guides so we can use the guides when creating our web page layout graphics. We can easily keep the Basic Layout Export layer intact; we need to copy all of the rectangles in this layer. On the main menu, select Edit and then Select All (or use the keyboard shortcut keys Ctrl + A). Then select Edit and Duplicate (or use the keyboard shortcut Ctrl + D) to duplicate all of the elements in this layer. Now you are ready to convert these current shapes into guides. First, select all the rectangles in the top (duplicate) layout. Do this by clicking a rectangle and then hold the Shift key on your keypad. Then click/select the next rectangle. When you have all five rectangles selected, from the main menu select Object and then Object to Guide. Your duplicate rectangles will be removed from the canvas and replaced with blue guides. To better see the guides, turn off the grid (from the main menu choose View and Grid). You'll also notice your originally created basic layout areas defined on the screen. We'll use these shapes later on to help export our design into workable graphics for the HTML programmers. Now it is time to save this new document before you start the details of the design. From the main menu select File and then Save As. Choose an appropriate file name for your project and save it. Make sure you save this document in the native Inkscape format of SVG to retain its editable features and layers. Project file management To keep all files for this project in an easy-to-find location, it might make sense to create a project folder on your computer and save this design file within that folder. As you export designs for use within web pages and HTML, you will need a number of files. Using a directory or folder to house all project files makes them easier to find. Summary In this article we took a look at architecting a web site. We discussed design techniques that can make web pages move from good to great. In the next article, Creating a Layout Example in Inkscape, we will see an example to create a web page layout. Further resources on this subject: Creating a Layout Example in Inkscape [Article] Logos in Inkscape [Article] Web Design Principles in Inkscape [Article] Creating Web Templates in Inkscape [Article]

  Moodle 1.9 Top Extensions Cookbook Over 60 simple and incredibly effective recipes for harnessing the power of the best Moodle modules to create effective online learning sites Packed with recipes to help you get the most out of Moodle modules Improve education outcomes by situating learning in a real-world context using Moodle Organize your content and customize your courses Reviews of the best Moodle modules—out of the available 600 modules Installation and configuration guides Written in a conversational and easy-to-follow manner         Read more about this book       (For more resources on Moodle, see here.) Involving students in assessment design Who said writing questions was the teacher's job? For students, the challenge of creating questions encourages them to think in a new and different way about the material they are studying. The incentive of being able to create questions that may be used in their own future assessment is also a thrill. Question Creation module Extending quizzes Like many parts of Moodle, the Quiz module is extensible. New question types can be added to the Quiz module so that teachers can produce more creative questions and challenge learners from a wider range. Drag-and-drop matching question type Drag-and-drop ordering question type Image target question type Simple formative feedback Students are motivated to earn marks, but that doesn't mean you can't sneak in a bit of formative assessment without them realizing it. Simply encouraging students to anticipate small snippets of the material can probe their knowledge, reinforcing their correct understandings and challenging their misunderstandings. Hidden Text filter Encouraging competition It is a disservice to delude students into believing that they standout when they are in fact falling behind. Displaying the highest standard for assignments and other assessable items on a leader-board can motivate students to compete, while recognizing those who are excelling. Course Results block Allowing students to contribute to assessment Name Question Creation Module Module type Activity Author Jamie Pratt Released 2008 Maintained Actively Languages English, Spanish Compliance Good Documentation Limited online documentation, help files Errors Some errors displayed when error reporting is turned on The Question Creation Module allows students to contribute Quiz questions and be rewarded with marks. This is a great pedagogical activity and the questions produced by students can be used in creative ways. Getting ready Unzip and copy the module directory into the /moodle/mod/ directory then visit the Notifications page. How to do it... After adding the Question Creation Module you can create an instance of this activity from the Add an activity... menu. The configuration page for this module is somewhat overcomplicated, however, once you have used it, the settings become apparent. (Move the mouse over the image to enlarge.) Like most modules, there is a Name. There is also a description that appears as an Introduction to students in their view of the activity. A time period for the activity can be specified with an opening and closing date. In the Grading section, there are a number of options, some of which are obvious and some that require explanation. A Question Creation activity can contribute to a course assessment and as such there is a Grade value. This grade value is constituted from a mix of: Automatic grading (based on number of questions created by a student, that is, a participation mark) Manual grading (based on a judgment of quality by the teacher A 50%/50% mix means that the student gains half the available marks by simply creating the required number of questions and the other half based on the judgment of the teacher. A different ratio can be chose to shift this balance depending on the teacher's preference. For a fully automated assessment, a ratio of 100%/0% can be used. For a grade that is wholly based on the teacher's judgment a ratio of 0%/100% can be used. The number of questions that need to be created can be specified. The grade value is then distributed across this number of questions. The types of Quiz questions can be restricted to specific types or students can be allowed to create questions of any type. The teacher can direct that the student create a minimum number of questions of specified question types. For example, the teacher could direct that two of the questions that a student creates should be Multiple Choice. Such enforcement is achieved in the sections labeled (rather incomprehensibly) as Will Grade Minimum Number of Questions of Type (optional). At the bottom of the configuration page, there is a setting that controls what level of editing students have over their own questions. It is not clear at first what each level of access means, nor why access needs to be restricted. Students can be controlled in their freedom to create, preview, edit, and delete questions. The module author suggests that there may be complications if a student edits a question after it has been graded, although he also suggests that students could improve questions based on feedback and such questions could then be re-graded (and the module facilitates this). For the most intuitive setup for students, the highest level of access is probably best. The teacher could then grade the questions after a set deadline. In a two phased approach that allows questions to be improved, questions could be checked at a specified date, with final question edits required by the set deadline. Students have an interface to launch the question creation process. When a question type is selected, students then create a question of that type using the same interface that a teacher uses when they create questions for a quiz. Students can create more than the required number of questions. Their final mark is based on the best questions they have created. Questions created by students appear in a list much like an assignments submission table. In this view, a teacher can preview a question and grade it. They can also provide comments on each question. The final grade is calculated when the teacher clicks the button at the bottom of this page labeled Save all grades & feedback. Grades are calculated according to how many of the required questions a student has created and the quality of each question. The student's final grade is the calculated value across all of their questions. How it works... Questions created by students are stored in the Moodle Question Bank. In that form they can be used by teachers in the course like any other question in the Question Bank. There's more... Requiring students to create questions is a great learning exercise. It forces students to think about the course materials at a higher level in order to form questions that someone else will find challenging. The real possibilities of this activity fall not in what the students can create, but in what the teacher can do with the questions that students have made. Here are some ideas: Using the best questions for regular quizzes (keeping in mind that at least one student will already know the answer) Using the best questions for quizzes for a successive cohort Using student created questions as the basis for a final exam