Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds

How-To Tutorials - Web Development

1797 Articles
article-image-drupal-web-services-twitter-and-drupal
Packt
26 Nov 2010
10 min read
Save for later

Drupal Web Services: Twitter and Drupal

Packt
26 Nov 2010
10 min read
Drupal Web Services Integrate social and multimedia Web services and applications with your Drupal Web site. Explore different Web services and how they integrate with the Drupal CMS. Reuse the applications without coding them again using the Web services protocols on your Drupal site. Configure your Drupal site to consume various web services by using contributed Drupal modules for each specific task or application. Drive the content from your Drupal site to Facebook, Twitter and LinkedIn using effective Drupal Web services An easy to follow guide that opens up a method of easily sharing data and content resources between applications and machines that are running different platforms and architecture. Introduction Twitter is a popular and widely used micro-blogging application and website. You can sign up for a Twitter account and post tiny snippet-based blog entries, 140 characters or less, to your Twitter home page. You can log in to your Twitter account and post your 140 character entry into the What's happening? text area box and then click on the Tweet button to publish it. The tweet will appear on your account's home page—your default Twitter home page—and it will be shared on the main Twitter home pages of your followers. To send a tweet to another user, you can use the hash tag in front of their username in your post. So, for example, if I was going to send myself a tweet, I would add this in my text area box before adding my post: #jamesweblabs. For more on the history and functionality of Twitter, check out the Wikipedia entry at: http://en.wikipedia.org/wiki/Twitter. Twitter also has a detailed Help and support documentation section on its main site at http://support.twitter.com/.   You may want to integrate Twitter with your Drupal site, to do things such as posting all of your most recent tweets into a Drupal block that will appear on your home page. You also may want to run this block automatically via a web service integration so that the block updates automatically whenever you post a new tweet to your Twitter account. Drupal and Twitter can easily integrate through these web services by using contributed modules. In this article, we're going to install, configure, and use the Twitter module so that we can integrate our Twitter account with our Drupal user account; we can also post tweets to the sidebar block on our site. With the Twitter module, we'll also expose some of its fields to the Views module and be able to create more powerful and dynamic listings of Twitter-based content. We'll also look at other contributed modules including Tweet. The Twitter API The Twitter API and service integration with Drupal uses the REST (Representational State Transfer) API protocol and a Streaming API protocol. Twitter does state in its API documentation that the service does not offer unlimited usage. Twitter does impose limits on the number of requests and updates made to its service API. The REST service is HTTP-based and uses GET and POST requests. GET is used to retrieve data so, in our case, this will be used when our Drupal site tries to receive the latest Tweet posted to your Twitter account. POST requests are used when you submit, update, or delete node data that you have sent over to Twitter and posted as a Tweet using the Twitter module. Using REST as the protocol, the API does support various formats for data transfer including XML, JSON, RSS, and Atom. For more details on the Twitter API and how to use it, see the Twitter API documentation for developers at: http://dev.twitter.com/pages/every_developer. The Twitter module The Twitter module is available via its Drupal project page at http://drupal.org/project/twitter. The module allows for integration with Twitter's API web service. It allows you to integrate your Twitter account with your Drupal user account; post Tweets to a block in Drupal; and allows your Drupal users to post to their Twitter account using Drupal node content. Drupal Views also integrates with the module and you can create your own customized Views-based listings of Twitter content. The module gives you a default block called User Tweets and also a user profile page titled user's tweets. We'll set both of these up in the examples that follow. Integrating the Twitter module with Drupal Download the 6.x-3.0-beta2 version of the Twitter module. This is the Other release version, not the recommended release. The reason we're going to install the Other release version is that recently Twitter changed their web service API to use authentication provided by the OAuth protocol. This change happened recently, in September 2010, when Twitter redesigned their website and made other security improvements and enhancements to their API. In order to support OAuth in the integration, you need to make sure to use the 3.0-beta2 version of the Twitter module. You can download it from: http://drupal.org/project/twitter It's listed under the Other releases heading: Once downloaded, upload this Twitter module folder to your /sites/all/modules location on your web server. You also need to download the OAuth module and add that to your /sites/all/modules. OAuth is required by the Twitter module, so you must install it. The OAuth module is available at: http://drupal.org/project/oauth. Again, with this module, you need to make sure to use the other release (earlier version) of 6.x-2.02. This 2.x version is the version that works with the Twitter 3.0-beta2 module. Make sure you have the correct versions of both of these modules before uploading to your site. This is very important. If the module versions are not the ones mentioned here, you may run into errors or other issues with functionality. So, make sure to install these exact versions. Go ahead and upload both of these modules to your /sites/all/modules. Once uploaded, browse to your modules admin page and look for the OAuth and Twitter module suites under the Other modules fieldset. For OAuth, you're looking for the Oauth and the OAuth Client Test modules. Enable the OAuth module as shown in the following screenshot: Then, scroll down and look for the Twitter, Twitter actions, Twitter Post, and Twitter Signin modules. Enable all four of these modules: Save your module configuration. Registering your website with Twitter Now that we've installed the necessary modules on our Drupal site, we need to set up the Twitter side of our functionality. In order to integrate the Twitter module with the Twitter web service, you need to create two Twitter-related items. The first is a Twitter account. If you do not already have a Twitter account, you can go to twitter.com and sign up for a brand new Twitter account. Go to: https://twitter.com/ Click on the Sign Up button and then proceed through the account sign-up steps. Setting up a Twitter application Now, we need to configure a new Twitter developer application. Once you have a Twitter account, log in to your Twitter account and then go to the twitter.com/apps URL to sign up for a new developer's application on Twitter. Make sure you are signed into your Twitter account already when you go to the apps URL. Launch the apps URL from: https://twitter.com/apps This page will show you any applications you have configured in Twitter. For our site, we're going to set up a brand new application, so, click on the Register a new application hyperlink: Clicking on that link will load a Register an Application form as shown in the following screenshot. Let's fill that out with the following info: Application Name Description of application Application Website (this is the URL of your website) Organization Name Website address (again this is the URL/home domain of your website) Scroll down on the form and then complete the form by adding and completing the following fields: Application Type—make sure to select Browser here Callback URL—this is the callback URL that the Drupal Twitter module provides The Callback URL is information that is provided by your Twitter module settings inside your Drupal site. To locate the correct Callback URL to add to the application sign-up form, go to your Twitter setup configuration settings in your Drupal site by browsing to: Site configuration | Twitter setup (admin/settings/twitter). On this page, you will see the Callback URL noted at the top of the OAuth Settings fieldset. You should see something similar to this: Go back to your Twitter application sign-up form and add this Callback URL. Now, make sure the Default Access type is set to Read & Write. Finally, make sure to check the Yes, Use Twitter for login. This will allow you to authenticate your posts to your Twitter account username and password when you try to post Drupal content to your Twitter account. So, make sure that box is checked. Your app form should now look like this: Complete the reCAPTCHA field at the bottom of the form and then click on the Save button. Twitter will load a page confirming your application is successfully configured and show you your application details. This includes your Consumer key, Consumer secret, Request token URL, Access Token URL, and Authorize URL. For integration with our Drupal site, we're going to need the Consumer key and secret. Leave this app details confirmation page open and then open up your Drupal site in another browser tab. Configuring the Twitter module once you have your app setup With your Drupal site open, go back to your Twitter module configuration form in your Drupal site at the following path: admin/settings/twitter. Here, you want to copy and paste your Twitter Consumer key and secret code into the respective fields for OAuth Consumer key and OAuth Consumer secret. Also, make sure to check the box next to Import Twitter Statuses. This will allow for your Drupal site to request posts from your Twitter account and add links to these tweets on your user account page, and also in a User Tweets block in one of your site's regions. This is what allows for the total cross-pollination and integration of your Drupal site with your Twitter account. It's very powerful and flexible for running the Twitter import functionality on your site. Finally, set the Delete old statuses drop down to 1 week. This will keep your Tweets block up to date on your Drupal site and show only updated and recent tweets. Let's go ahead and do that. You should have a screen that looks like this: Go ahead and Save configuration. Now, let's check and tweak some of the other Twitter module settings before we test our posts. Click on the Post link at the top of your Twitter setup page. On this page, you can specify what content types and respective Drupal content you want to announce and post to your Twitter account. Let's make sure we check the boxes next to the Blog entry, Page, and Story types. Of course, you can enable all of your content types if you need to, but for this example, we'll just post our new blog entries over to our Twitter account. The Default format string field shows you the format of the link that will be posted over to your Twitter account announcing your new Drupal content. So, when you post a node to your Drupal site using the blog type, the post will appear on your Twitter account in the following format as a hyperlink back to your post on Drupal: New post: !title !tinyurl This will show the Drupal node title, !title, value along with a tinyurl formatted hyperlink back to your Drupal post. So, for example, the resulting post on Twitter will look like this: ·New post: Testing post to Twitter http://tinyurl.com/33jnclx — 1 hour 53 min ago Your Post screen should now look like this: Save your Post page configuration.
Read more
  • 0
  • 0
  • 3956

article-image-opencart-faqs
Packt
25 Nov 2010
4 min read
Save for later

OpenCart FAQs

Packt
25 Nov 2010
4 min read
OpenCart 1.4 Beginner's Guide Build and manage professional online shopping stores easily using OpenCart. Develop a professional, easy-to-use, attractive online store and shopping cart solution using OpenCart that meets today's modern e-commerce standards Easily integrate your online store with one of the more popular payment gateways like PayPal and shipping methods such as UPS and USPS Provide coupon codes, discounts, and wholesale options for your customers to increase demand on your online store With hands-on examples, step-by-step explanations, and illustrations Q: What are the system requirements for OpenCart? A: The following screenshot shows the minimum system requirements for OpenCart for installation and running without problems. You should contact your hosting provider if you are not sure whether these settings are set or not. Q: What are the methods to upload files to a web host? A: There are two common methods for uploading files to a web host: Using cPanel File Manager Utility Using an FTP Client Q: Can we run more than one store on a single OpenCart installation? A: Yes. We can run more than one store on a single OpenCart installation. Q: What are GeoZones? A: Geo Zones represent the groups of countries or smaller geo sections under these countries. A Geo Zone can include countries, states, cities, and regions depending on the type of country. OpenCart uses Geo Zones to identify shipping and tax rate price regulations for a customer's order. Here is an example: Q: What if we want to edit anything in Geo Zones? A: If we want to edit any Country and / or Zone definition in Geo Zones, we should visit System | Localisation | Zones menu in the administration pane. Q: What is SEO? A: SEO (Search Engine Optimization) is a group of processes which is applied for websites to increase their visibility in search engine results to get more qualified traffic. For an online store, it is very important to apply at least the basic SEO techniques. Q: Where can we find the new modules of OpenCart? A: www.OpenCart.com contributions and forum pages are the essential sources to find new modules and/or ask for new ones from developers. Q: What do you mean by Payment Gateway? A: A payment gateway is an online analogue of a physical credit card processing terminal that we can locate in retail shops. Its function is to process credit card information and return the results back to the store system. You can imagine the payment gateway as an element in the middle of an online store and credit card network. The software part of this service is included in OpenCart but we will have to use one of the payment gateway services. Q: What are the payment methods in OpenCart? A: The current OpenCart version supports many established payment systems, including PayPal services, Authorize.net, Moneybookers, 2Checkout, and so on, as well as basic payment options such as Cash on Delivery, Bank Transfer, Check/money order, etc. Q: In which currency is the total amount calculated? A: PayPal automatically localizes the total amount according to the PayPal owner's account currency. Q: Whats the difference between PayPal Website Payment Standard and PayPal Website Payment Pro? A: PayPal Website Payment Standard is the easiest method to implement accepting credit card payments on an online store. There are no monthly fees or setup costs charged by PayPal. PayPal Website Payment Pro is the paid PayPal solution for an online store as a payment gateway and merchant account. The biggest difference from PayPal Website Payment Standard is that customers do not leave the website for credit card processing. The credit card information is completely processed in the online store as it is the popular method of all established e-commerce websites. Q: Which of the two PayPal products is recommended? A: For a beginner OpenCart administrator who wants to use PayPal for the online store, it is recommended to get experience with the free Standard payment option and then upgrade to the Pro option.
Read more
  • 0
  • 0
  • 2233

article-image-installing-drupal-7
Packt
24 Nov 2010
9 min read
Save for later

Installing Drupal 7

Packt
24 Nov 2010
9 min read
Drupal 7 First Look Learn the new features of Drupal 7, how they work and how they will impact you Get to grips with all of the new features in Drupal 7 Upgrade your Drupal 6 site, themes, and modules to Drupal 7 Explore the new Drupal 7 administration interface and map your Drupal 6 administration interface to the new Drupal 7 structure Complete coverage of the DBTNG database layer with usage examples and all API changes for both Themes and Modules         Read more about this book       (For more resources on Drupal, see here.) Drupal's installation process has always been very easy to use, and the Drupal 7 installation makes things even easier. Before beginning to install Drupal 7, you will need a web server running the Apache HTTPD web server. You can also use IIS on Microsoft Windows, but the Apache server is preferred and you will be able to obtain support from the community more easily if you use the Apache server. Want to easily install Apache onto a Microsoft Windows machine? Try XAMPP, which is published by Apache Friends. This package includes Apache, MySQL, and PHP with a standard Microsoft Windows installer. You can download XAMPP from http://www.apachefriends. org/en/xampp.html. Other options include WAMP (http://www. wampserver.com/en/) and MoWeS Portable (http://www. chsoftware.net/en/mowes/mowesportable/mowes.htm). Your server will also need PHP installed on it. Drupal requires at least PHP version 5.2.0. As of this writing, there are some hosts that still do not have PHP 5.2.0 or later installed on their shared hosting accounts, and Red Hat does not include PHP 5.2.0 or later in its default distribution. Check with your host or system administrator before installing Drupal to make sure that the correct version is available. In addition to the web server and PHP, you will also need a database. MySQL and PostgreSQL are the databases that are most frequently used with Drupal, and of the two, MySQL is much more widely used. That being said, you can use Drupal with many different databases and the new DBTNG database abstraction layer will make it easier to deploy to any database. If you are using MySQL, you will need version 5.0.15 or later installed. If you are using PostgreSQL, you will need PostgreSQL 8.3.0 or later. SQLite is also officially supported for use with Drupal and you will need version 3.4.2 or later. After you have a server set up with the proper software, you can download Drupal and begin the installation process. Obtaining Drupal If you have used previous versions of Drupal, the process for downloading Drupal is the same as always. If you are new to Drupal, you will use the following process: Go to the Drupal project page on Drupal.org: http://drupal.org/project/ drupal. Find the latest official release of Drupal 7 and click on the Download link. The release will be named 7.0 or similar. Your browser will ask whether you want to download or Open the file. Make sure to download it to your computer. The file you downloaded is a .tar.gz file, which is a compressed archive similar to a .zip file. You will need to extract the files from this archive onto your computer. If your computer doesn't already have a program that can open .tar.gz files, try 7-Zip, an open source application that easily handles these files. You can download 7-Zip from http://www.7-zip.org. After you have extracted the files, you will need to copy them to your web server's document root. You are now ready to start the installation process. Simply navigate to http://yoursite.com/install.php. Let's step through the installation process in detail now. Selecting an installation profile The first step in the installation process is selecting an installation profile. Drupal prompts you with a screen asking for which installation profile you want to use during the installation: By default, Drupal comes with two installation profiles, the Standard profile and the Minimal profile. Custom distributions may come with additional profiles. Minimal profile The Minimal profile installs a basic configuration of Drupal with only the required functionality enabled. This profile is even more minimal than the base Drupal 6 installation. This profile should be used if you are very familiar with setting up Drupal and don't want some of the additional features activated in the Standard profile. Standard profile The Standard Drupal profile installs and activates several commonly-used features to make your Drupal site more useful immediately. These additional features include: Search form installed on the left sidebar. Powered by Drupal block enabled in the footer. A basic page content type is automatically created to store static content on your site. An article content type is automatically created to store time-specific content. The article content type replaces the story content type from Drupal 6. Both content types are set up with RDF capabilities. User profiles have pictures enabled by default. Profile pictures can have a maximum size of 1024x1024 pixels and be up to 800 KB when they are uploaded. They will be displayed using the thumbnail image style. A taxonomy called Tags is created to allow easy categorization of content on your site. The article content type is enhanced by adding an image field, which allows PNG, GIF, and JPG files to be attached to the article. An administrator role is created that has all permissions activated for it. As new modules are activated, the administrator role will automatically be updated with the permissions for the new module. The Seven theme is activated for the administration section of the site. In most cases, you will want to start with the Standard installation profile, especially if you are setting up an entirely new site or if you are new to Drupal. Language selection The next step in the installation is choosing the language with which you want to install Drupal. By default, Drupal only includes an English installer. If you want to want to install Drupal in another language, you will need to download a translation from Drupal.org. A complete list of translations is available at http://drupal.org/ project/translations. After you download the translation you want to use, you will need to unpack the translation and copy it to your document folder. The process to unpack and copy the files is similar to the process we used when we unpacked and copied the core Drupal files to your server. For now, we will continue with the English installation. Requirements check Drupal will now check the requirements of your server to ensure that it meets the minimum requirements to run Drupal and to ensure that everything is ready for the installation to proceed. The requirements check will appear similar to the following: If Drupal does discover any problems, it will give you information about how to correct the problem. In our case, it looks like we forgot to set up our settings file. The settings file tells Drupal which database to connect to as well as the connection information. To create a settings file, navigate to your document root and then navigate to the sites/default folder. Copy the default.settings.php file to settings.php. You do not need to change any of the information within the file. After you have corrected any problems, click on the proceed with the installation link. Drupal will re-evaluate the requirements and let you know if anything else needs to be changed. This screen has been enhanced in Drupal 7 to provide much more information about your current server settings. Database configuration The next step in installing Drupal is configuring the database where Drupal will store the content and configuration information for your site. The functionality of this screen has also been enhanced in Drupal 7. The key difference is that Drupal 7 will automatically check which types of databases are available to you based on your server setup. Then, it will only allow you to select a database which will work. If you want to run Drupal using a different database server than your web server, you can use the ADVANCED OPTIONS link to configure the database server and port. You can also use ADVANCED OPTIONS if you are setting up multiple sites within a single database. For a Standard installation, enter the name of your database as well as the username and password for the database. This functionality remains the same as in Drupal 6. You will need to create a database outside of the Drupal installation. The actual steps for creating a new database vary depending on your website host. Many hosts have installed phpMyAdmin, which allows you to manage your databases with an easy-to-use web-based interface. If you use phpMyAdmin to create your database, you will need to log in to phpMyAdmin and create a database. You can create a new database from the home page, which should appear similar to the following screenshot depending on the version of phpMyAdmin you are using: You can create a new user for the database in the Privileges tab. After you have entered your database settings, click on the Save and continue button. Drupal will now configure the database and set up your site. As the installation proceeds, Drupal will display its progress. The installation may take several minutes to complete. In the unlikely event that you have problems during the installation, try emptying the database, increasing the amount of memory available to Drupal, and increasing the maximum execution time for a PHP script. You can increase the available memory and execution time in your php.ini file. The relevant sections in php.ini to control memory and execution time are shown in the following screenshot:
Read more
  • 0
  • 0
  • 1610
Visually different images

article-image-google-web-toolkit-2-creating-page-layout
Packt
24 Nov 2010
7 min read
Save for later

Google Web Toolkit 2: Creating Page Layout

Packt
24 Nov 2010
7 min read
Google Web Toolkit 2 Application Development Cookbook Over 70 simple but incredibly effective practical recipes to develop web applications using GWT with JPA , MySQL and i Report Create impressive, complex browser-based web applications with GWT 2 Learn the most effective ways to create reports with parameters, variables, and subreports using iReport Create Swing-like web-based GUIs using the Ext GWT class library Develop applications using browser quirks, Javascript,HTML scriplets 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   The layout will be as shown in the diagram below: Creating the home page layout class This recipe creates a panel to place the menu bar, banner, sidebars, footer, and the main application layout. Ext GWT provides several options to define the top-level layout of the application. We will use the BorderLayout function. We will add the actual widgets after the layout is fully defined. The other recipes add the menu bar, banner, sidebars, and footers each, one-by-one. Getting ready Open the Sales Processing System project. How to do it... Let's list the steps required to complete the task. Go to File | New File. Select Java from Categories, and Java Class from File Types. Click on Next. Enter HomePage as the Class Name, and com.packtpub.client as Package. Click on Finish. Inherit the class ContentPanel. Press Ctrl + Shift + I to import the package automatically. Add a default constructor: package com.packtpub.client; import com.extjs.gxt.ui.client.widget.ContentPanel; public class HomePage extends ContentPanel { public HomePage() { } } Write the code of the following steps in this constructor. Set the size in pixels for the content panel: setSize(980,630); Hide the header: setHeaderVisible(false); Create a BorderLayout instance and set it for the content panel: BorderLayout layout = new BorderLayout(); setLayout(layout); Create a BorderLayoutData instance and configure it to be used for the menu bar and toolbar: BorderLayoutData menuBarToolBarLayoutData= new BorderLayoutData(LayoutRegion.NORTH, 55); menuBarToolBarLayoutData.setMargins(new Margins(5)); Create a BorderLayoutData instance and configure it to be used for the left-hand sidebar: BorderLayoutData leftSidebarLayoutData = new BorderLayoutData(LayoutRegion.WEST, 150); leftSidebarLayoutData.setSplit(true); leftSidebarLayoutData.setCollapsible(true); leftSidebarLayoutData.setMargins(new Margins(0, 5, 0, 5)); Create a BorderLayoutData instance and configure it to be used for the main contents, at the center: BorderLayoutData mainContentsLayoutData = new BorderLayoutData(LayoutRegion.CENTER); mainContentsLayoutData.setMargins(new Margins(0)); Create a BorderLayoutData instance and configure it to be used for the right-hand sidebar: BorderLayoutData rightSidebarLayoutData = new BorderLayoutData(LayoutRegion.EAST, 150); rightSidebarLayoutData.setSplit(true); rightSidebarLayoutData.setCollapsible(true); rightSidebarLayoutData.setMargins(new Margins(0, 5, 0, 5)); Create a BorderLayoutData instance and configure it to be used for the footer: BorderLayoutData footerLayoutData = new BorderLayoutData(LayoutRegion.SOUTH, 20); footerLayoutData.setMargins(new Margins(5)); How it works... Let's now learn how these steps allow us to complete the task of designing the application for the home page layout. The full page (home page) is actually a "content panel" that covers the entire area of the host page. The content panel is a container having top and bottom components along with separate header, footer, and body sections. Therefore, the content panel is a perfect building block for application-oriented user interfaces. In this example, we will place the banner at the top of the content panel. The body section of the content panel is further subdivided into five regions in order to place these—the menu bar and toolbar at the top, two sidebars on each side, a footer at the bottom, and a large area at the center to place the contents like forms, reports, and so on. A BorderLayout instance lays out the container into five regions, namely, north, south, east, west, and center. By using BorderLayout as the layout of the content panel, we will get five places to add five components. BorderLayoutData is used to specify layout parameters of each region of the container that has BorderLayout as the layout. We have created five instances of BorderLayoutData, to be used in the five regions of the container. There's more... Now, let's talk about some general information that is relevant to this recipe. Setting the size of the panel The setSize method is used to set the size for a panel. Any one of the two overloaded setSize methods can be used. A method has two int parameters, namely, width and height. The other one takes the same arguments as string. Showing or hiding header in the content panel Each content panel has built-in headers, which are visible by default. To hide the header, we can invoke the setHeaderVisible method, giving false as the argument, as shown in the preceding example. BorderLayoutData BorderLayoutData is used to set the layout parameters, such as margin, size, maximum size, minimum size, collapsibility, floatability, split bar, and so on for a region in a border panel. Consider the following line of code in the example we just saw: BorderLayoutData leftSidebarLayoutData = new BorderLayoutData(LayoutRegion.WEST, 150) It creates a variable leftSidebarLayoutData, where the size is 150 pixels and the region is the west of the border panel. rightSidebarLayoutData.setSplit(true) sets a split bar between this region and its neighbors. The split bar allows the user to resize the region. leftSidebarLayoutData.setCollapsible(true) makes the component collapsible, that is, the user will be able to collapse and expand the region. leftSidebarLayoutData.setMargins(new Margins(0, 5, 0, 5)) sets a margin where 0, 5, 0, and 5 are the top, right, bottom, and left margins, respectively. Classes and packages In the preceding example, some classes are used from Ext GWT library, as shown in the following table: ClassPackageBorderLayoutcom.extjs.gxt.ui.client.widget.layoutBorderLayoutDatacom.extjs.gxt.ui.client.widget.layoutContentPanelcom.extjs.gxt.ui.client.widgetMarginscom.extjs.gxt.ui.client.utilStylecom.extjs.gxt.ui.client See also The Adding the banner recipe The Adding menus recipe The Creating the left-hand sidebar recipe The Creating the right-hand sidebar recipe The Creating main content panel recipe The Creating the footer recipe The Using HomePage instance in EntryPoint recipe Adding the banner This recipe will create a method that we will use to add a banner in the content panel. Getting ready Place the banner image banner.png at the location webresourcesimages. You can use your own image or get it from the code sample provided on the Packt Publishing website (www.packtpub.com). How to do it... Create the method getBanner: public ContentPanel getBanner() { ContentPanel bannerPanel = new ContentPanel(); bannerPanel.setHeaderVisible(false); bannerPanel.add(new Image("resources/images/banner.png")); Image("resources/images/banner.png")); return bannerPanel; } Call the method setTopComponent of the ContentPanel class in the following constructor: setTopComponent(getBanner()); How it works... The method getBanner() creates an instance bannerPanel of type ContentPanel. The bannerPanel will just show the image from the location resources/images/banner.png. That's why, the header is made invisible by invoking setHeaderVisible(false). Instance of the com.google.gwt.user.client.ui.Image class, which represents the banner image, is added in the bannerPanel. In the default constructor of the HomePage class, the method setTopComponent(getBanner()) is called to set the image as the top component of the content panel. See also The Creating the home page layout class recipe The Adding menus recipe The Creating the left-hand sidebar recipe The Creating the right-hand sidebar recipe The Creating main content panel recipe The Creating the footer recipe The Using HomePage instance in EntryPoint recipe  
Read more
  • 0
  • 0
  • 1980

article-image-getting-started-selenium-grid
Packt
23 Nov 2010
6 min read
Save for later

Getting Started with Selenium Grid

Packt
23 Nov 2010
6 min read
Important preliminary points For this section you will need to have Apache Ant on the machine that you are going to have running Grid instances. You can get this from http://ant.apache.org/bindownload.cgi for Windows and Mac. If you have Ubuntu you can simply do sudo apt-get install ant1.8, which will install all the relevant items that are needed onto your Linux machine. Visit the project site to download Selenium Grid. Understanding Selenium Grid Selenium Grid is a version of Selenium that allows teams to set up a number of Selenium instances and then have one central point to send your Selenium commands to. This differs from what we saw in Selenium Remote Control (RC) where we always had to explicitly say where the Selenium RC is as well as know what browsers that Remote Control can handle. With Selenium Grid, we just ask for a specific browser, and then the hub that is part of Selenium Grid will route all the Selenium commands through to the Remote Control you want. Selenium Grid also allows us to, with the help of the configuration file, assign friendly names to the Selenium RC instances so that when the tests want to run against Firefox on Linux, the hub will find a free instance and then route all the Selenium Commands from your test through to the instance that is registered with that environment. We can see an example of this in the next diagram. We will see how to create tests for this later in the chapter, but for now let's have a look at making sure we have all the necessary items ready for the grid. Checking that we have the necessary items for Selenium Grid Now that you have downloaded Selenium Grid and Ant, it is always good to run a sanity check on Selenium Grid to make sure that we are ready to go. To do this we run a simple command in a console or Command Prompt. Let's see this in action. Time for action – doing a sanity check on Selenium Grid Open a Command Prompt or console window. Run the command ant sanity-check. When it is complete you should see something similar to the next screenshot: What just happened? We have just checked whether we have all the necessary items to run Selenium Grid. If there was something that Selenium relied on, the sanity check script would output what was needed so that you could easily correct this. Now that everything is ready, let us start setting up the Grid. Selenium Grid Hub Selenium Grid works by having a central point that tests can connect to, and commands are then pushed to the Selenium Remote Control instances connected to that hub. The hub has a web interface that tells you about the Selenium Remote Control instances that are connected to the Hub, and whether they are currently in use. Time for action – launching the hub Now that we are ready to start working with Selenium Grid we need to set up the Grid. This is a simple command that we run in the console or Command Prompt. Open a Command Prompt or console window. Run the command ant launch-hub. When that happens you should see something similar to the following screenshot: We can see that this is running in the command prompt or console. We can also see the hub running from within a browser. If we put http://nameofmachine:4444/console where nameofmachine is the name of the machine with the hub. If it is on your machine then you can place http://localhost:4444/console. We can see that in the next screenshot: What just happened? We have successfully started Selenium Grid Hub. This is the central point of our tests and Selenium Grid instances. We saw that when we start Selenium Grid it showed us what items were available according to the configuration file that is with the normal install. We then had a look at how we can see what the Grid is doing by having a look at the hub in a browser. We did this by putting the URL http://nameofmachine:4444/console where nameofmachine is the name of the machine that we would like to access with the hub. It shows what configured environments the hub can handle, what grid instances are available and which instances are currently active. Now that we have the hub ready we can have a look at starting up instances. Adding instances to the hub Now that we have successfully started the Selenium Grid Hub, we will need to have a look at how we can start adding Selenium Remote Controls to the hub so that it starts forming the grid of computers that we are expecting. As with everything in Selenium Grid, we need Ant to start the instances that connect. In the next few Time for action sections we will see the different arguments needed to start instances to join the grid. Time for action – adding a remote control with the defaults In this section we are going to launch Selenium Remote Control and get it to register with the hub. We are going to assume that the browser you would like it to register for is Firefox, and the hub is on the same machine as the Remote Control. We will pass in only one required argument, which is the port that we wish it to run on. However, when starting instances, we will always need to pass in the port since Selenium cannot work out if there are any free ports on the host machine. Open a Command Prompt or console window. Enter the command ant –Dport=5555 launch-remote-control and press Return. You should see the following in your Command Prompt or console: And this in the Selenium Grid Hub site: What just happened? We have added the first machine to our own Selenium Grid. It has used all the defaults that are in the Ant build script and it has created a Selenium Remote Control that will take any Firefox requests, located on the same machine as the host of Selenium Remote Control Grid. This is a useful way to set up the grid if you just want a large number of Firefox-controlling Selenium Remote Controls.
Read more
  • 0
  • 0
  • 1734

article-image-first-steps-selenium-rc
Packt
23 Nov 2010
4 min read
Save for later

First Steps with Selenium RC

Packt
23 Nov 2010
4 min read
Selenium 1.0 Testing Tools: Beginner’s Guide Important preliminary points To complete the examples of this article you will need to make sure that you have at least Java JRE installed. You can download it from http://java.sun.com. Selenium Remote Control has been written in Java to allow it to be cross platform, so we can test on Mac, Linux, and Windows. What is Selenium Remote Control Selenium IDE only works with Firefox so we have only been checking a small subsection of the browsers that our users prefer. We, as web developers and testers, know that unfortunately our users do not just use one browser. Some may use Internet Explorer, others may use Mozilla Firefox. This is not to mention the growth of browsers such as Google Chrome and Opera. Selenium Remote Control was initially developed by Patrick Lightbody as a way to test all of these different web browsers without having to install Selenium Core on the web server. It was developed to act as a proxy between the application under test and the test scripts. Selenium Core is bundled with Selenium Remote Control instead of being installed on the server. This change to the way that Selenium tests are run allowed developers to interact with the proxy directly giving developers and testers a chance to use one of the most prominent programming languages to send commands to the browser. Java and C# have been the main languages used by developers to create Selenium Tests. This is due to most web applications being created in one of those languages. We have seen language bindings for dynamic languages being created and supported as more developers move their web applications to those languages. Ruby and Python are the most popular languages that people are moving to. Using programming languages to write your tests instead of using the HTML-style tests with Selenium IDE allows you, as a developer or tester, to make your tests more robust and take advantage of all setups and tear down those that are common in most testing frameworks. Now that we understand how Selenium Remote Control works, let us have a look at setting it up. Setting up Selenium Remote Control Selenium Remote Control is required on all machines that will be used to run tests. It is good practice to limit the number of Selenium Remote Control instances to one per CPU core. This is due to the fact that web applications are becoming more "chatty" since we use more AJAX in them. Limiting the Selenium instances to one per core makes sure that the browsers load cleanly and Selenium will run as quickly as possible. Time for action – setting up Selenium Remote Control Download Selenium Remote Control from http://seleniumhq.org/download. Extract the ZIP file. Start a Command Prompt or a console window and navigate to where the ZIP file was extracted. Run the command java –jar selenium-server-standalone.jar and the output should appear similar to the following screenshot: What just happened? We have successfully set up Selenium Remote Control. This is the proxy that our tests will communicate with. It works by language bindings, sending commands through to Selenium Remote Control which it then passes through to the relevant browser. It does this by keeping track of browsers by having a unique ID attached to the browser, and each command needs to have that ID in the request. Now that we have finished setting up Selenium Remote Control we can have a look at running our first set of tests in a number of different browsers. Pop quiz – setting up Selenium Remote Control Where can you download Selenium Remote Control from? Once you have placed Selenium Remote Control somewhere accessible, how do you start Selenium Remote Control? Running Selenium IDE tests with Selenium Remote Control The Selenium IDE to create all the tests have only been tested on applications in Firefox. This means the testing coverage that you are offering is very limited. Users will use a number of different browsers to interact with your application. Browser and operating system combinations can mean that a developer or tester will have to run your tests more than nine times. This is to make sure that you cover all the popular browser and operating system combinations. Now let's have a look at running the IDE tests with Selenium Remote Control.
Read more
  • 0
  • 0
  • 5925
Unlock access to the largest independent learning library in Tech for FREE!
Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
Renews at €14.99/month. Cancel anytime
article-image-introduction-moodle-modules
Packt
22 Nov 2010
8 min read
Save for later

Introduction to Moodle Modules

Packt
22 Nov 2010
8 min read
  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       Introduction Moodle is an open source Learning Management System (LMS). Image source: http://moodle.org/ The word Moodle is actually an acronym. The 'M' in Moodle stands for Modular and the modularity of Moodle has been one of the key aspects of its success. Being modular means you can: Add modules to your Moodle instance Selectively use the modules you need M.O.O.D.L.E. The acronym Moodle stands for Modular Object-Oriented Dynamic Learning Environment. It is modular because you can add and remove modules. The programming paradigm used to create Moodle code is Object-Oriented. It is dynamic because it can be used for information delivery and interactivity, in a changeable and flexible way. It is a learning environment designed for teaching at many levels. Because Moodle is modular and open source, many people have created modules for Moodle, and many of those modules are available freely for you to use. At time of writing, there are over 600 modules that you can download from the Moodle Modules and plugins database. Some of these are popular, well designed, and well maintained modules. Others are ideas that didn't seem to get off the ground. Some are contributed and maintained by large institutions, but most are contributed by individuals, often teachers themselves, who want to share what they have created. If you have an idea for something you would like to do with Moodle, it's possible that someone has had that idea before and has created and shared a module you can use. This article will show you how to download and test contributed Moodle modules, to see if they suit your needs. Origins of Moodle Moodle began in 1999 as postgraduate work of Martin Dougiamas, "out of frustration with the existing commercial software at the time". Considering the widespread use of Moodle around the world (over 40,000 registered sites in over 200 countries), Martin is a very humble man. If you ever make it to a MoodleMoot and Martin is in attendance, be sure to introduce yourself. A test server If you only want to test modules, consider setting up your own basic web server, such as XAMPP (http://www.apachefriends.org/en/xampp.html) and installing Moodle from the Moodle Downloads page (http://download.moodle.org/). If you are a Windows or Mac user, you can even download and install Moodle packages where these two ingredients are already combined and ready to go. Once installed, add a course or two. Create some dummy students to see how modules work within a course. Have a play around with the modules available—Moodle is quite hard to break—don't be afraid to experiment. Getting modules you can trust The Moodle Modules and plugins database is filled with modules great and small. This article will help you to know how you can find modules yourself. Getting ready You may have an idea in mind, or you may just want to see what's out there. You'll need a web browser and an active Internet connection. How to do it... Point your browser to the Moodle Modules and plugins database. Refer http://moodle.org/mod/data/view.php?id=6009: Image source: http://moodle.org/mod/data/view.php?id=6009 As you scroll down you will see list of modules that can be downloaded. At the bottom of the page is a Search facility: Image source: http://moodle.org/mod/data/view.php?id=6009 You can also try an advanced search to get more specific about the following: What type of module you want What version of Moodle you have A number of other features The following is a search result for the term 'progress': Image source: http://moodle.org/mod/data/view.php?id=6009 Each entry has a type, the version of Moodle that it is compatible with, and a brief description. Clicking on the name of the module will take you to a page with details about the module. This is the module's 'entry': Image source: http://moodle.org/mod/data/view.php?d=13&rid=2524&filter=1 On each entry page there is a wealth of information about the module. The following is a list of questions you will want to answer when determining if the module is worth testing. Will it work with your version of Moodle? Is documentation provided? When was the module released and has there been activity (postings on the page below) since then? Is the module author active in the discussion about the module? Is the discussion positive (don't be too discouraged by bug reports if the author is involved and reporting that bugs have been fixed)? From discussion, can you tell if the module is widely used with a community of users behind it? What is the rating of the module? If you are happy with your answers to these questions, then you may have found a useful module. Be wary of modules that do what you want, but are not supported; you may be wasting your time and putting the security of your system and the integrity your teaching at risk. There's more... Here is some additional information that may help you on a module hunt. Types of modules In order to get a sense of how modules will work, you need to have an understanding of the distinction between different module types. The following table describes common module types. Amid the array of modules available, the majority are blocks and activity modules. Activity moduleActivity modules deliver information or facilitate interactivity within a course. Links to activity modules are added on a course main page and the activity module itself appears on a new page when clicked. Examples in the core installation are 'Forums' and 'Quizzes'.Assignment typeAssignment types are a specific type of activity module that focus on assessable work. They are all based on a common assignment framework and appear under 'Assignments' in the activities list. Examples in the core installation are 'Advanced upload of files' and 'Online text' assignments.BlockBlocks usually appear down each side of a course main page. They are usually passive, presenting specific information, and links to more information and activities. A block is a simpler type of module. Because they are easy to create, there are a large number of these in the Modules and Plugins database. Examples in the core installation are the 'Calendar' and 'Online Users' blocks.Course formatA course format allows the structure of a course main page to be changed to reflect the nature of the delivery of the course, for example, by schedule or by topic.FilterFilters allow targeted text appearing around a Moodle site to be replaced with other content, for example, equations, videos, or audio clips.IntegrationAn integration module allows Moodle to make use of systems outside the Moodle instance itself.Question typeWithin a quiz, question types can be added to enable different forms of questions to be asked. Checking your version If you are setting up your own Moodle instance for teaching or just for testing, take note of the version you are installing. If you have access to the Site Administration interface (the Moodle site root page when logged in as an administrator), clicking on Notifi cations will show you the version number near the bottom, for example Moodle 1.9.8 (Build: 20100325). The first part of this is the Moodle version; this is what you need when searching through modules on the Modules and plugins database. The second part, labeled "Build" shows the date when the installed version was released in YYYYMMDD format. This version information reflects what is stored in the /version.php file. If you are not the administrator of your system, consult the person who is. They should usually be able to tell you the version without looking it up. Moodle 2.0 The next version of Moodle to follow version 1.9 has been "on the cards" for some time. The process of installing modules will not change in the new version, so most of the information in this book will still be valid. You will need to look for versions of modules ready for Moodle 2.0 as earlier versions will not work without adjustment. As modules are usually contributed by volunteers, there may be some waiting before this happens; the best way to encourage this re-development is to suggest an improvement for the module on the Moodle bug tracker system at http://tracker.moodle.org/. See also Adding modules to Moodle
Read more
  • 0
  • 0
  • 5519

article-image-customizing-backend-editing-typo3-templates
Packt
22 Nov 2010
11 min read
Save for later

Customizing the Backend Editing in TYPO3 Templates

Packt
22 Nov 2010
11 min read
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. Updating the rich text editor While we are making life easier for the editors, we can work on one of the areas they have to spend the most time in: the Rich Text Editor (RTE). The rich text editor allows anybody editing text or content in the TYPO3 backend to add formatting and styling such as bold or italics without using special syntax or HTML, and see the results in the text area immediately. This is also known as a WYSIWYG (What You See Is What You Get) editor and we've used it in the previous chapters to edit our own content: Out of the box, TYPO3 comes with the htmlArea RTE (extension key: rtehtmlarea), and it really is a good editor to work with. The problem is that it's configured by default to fit everybody, so it doesn't really fit anybody particularly well without a little bit of modification: it has it's own classes that we probably don't actually use, toolbars that may give too many options, and it blocks some handy tags such as the embed and object tags that we need for embedded video. Luckily, the htmlArea RTE is very configurable like everything in TYPO3 and allows us to override or add to almost all of its rules. There's an entire TSref document (http://typo3.org/documentation/documentlibrary/extension-manuals/rtehtmlarea/current), so we're not going to try to cover everything that is possible. The TSref is being updated with the new releases, so I recommend checking it out if you have any questions or want to get more information on configurations that we have only glossed over or skipped. As a final note, some of the configuration properties in this section will work on other RTE options, but many are special for the htmlArea RTE. We are going to talk about the htmlArea RTE because it is already installed by default and has a lot of powerful options, but you may choose to install a different editor as an extension in the future. TYPO3 allows us to replace the RTE in the backend with TYPO3 extensions, and we might want to replace the default htmlArea RTE if we need to support older browsers or use special features like plugins for editing images. If you are using a different editor, you may need to look at its documentation for any differences in configuration. Editing the TSconfig Configuration of the RTE is done completely in the TSconfig for the user or the page. We've used the TypoScript template for frontend configuration and layout, but the TSconfig is mainly used for configuring backend modules in TYPO3 like the RTE. The rich text editor is a backend module, so we need to use the TSconfig to configure it for our editors. The TSconfig can be modified through the Page properties view on any page in the Options tab (shown in the following screenshot): Above you can see an example of the TSconfig with some of the modifications that we are going to look at for the RTE. Of course, you can edit the TSconfig on any page in the page tree that you would like, but we are going to be working on the Root page. Like templates, the TSconfig is inherited from the parent pages in the page tree, so we can modify all of the instances of the RTE in the entire site by modifying the Root page. CSS properties The first thing that we want to update in our editor is the CSS. Without special configuration, the htmlArea RTE uses its own default CSS to decide how the different options such as headings, bold, italics, and so on, look in the text area preview. We can update the TSconfig, to load our own external stylesheet for the RTE that more closely resembles our working frontend site; the editors will see the same basic styling for paragraphs and headings as the visitors and have a better idea of what their content will look like in the frontend. According to the TSref on htmlArea, the following stylesheets are applied to the contents of the editing area by default in ascending order (we'll talk about each one in a moment): The htmlarea-edited-content.css file from the current backend TYPO3 skin (contains selectors for use in the editor but not intended to be applied in the frontend) A CSS file generated from the mainStyleOverride and inlineStyle assignments Any CSS file specified by contentCSS property in the page TSConfig We don't need to worry about the first file, htmlarea-edited-content.css. The TYPO3 skin that styles everything in the backend controls it. By default, there is an extension named TYPO3 skin, and we can simply override any of the styles by using the contentCSS property that we will see in a minute. The mainStyleOverride and inlineStyle properties are controlled by the htmlArea RTE, and TYPO3 generates a CSS file based on their settings in the extension. The mainStyleOverride contains all of the default text settings including sizes and font choices. If we are using our own CSS, we will want to ignore the original styles, so we are going to use the ignoreMainStyleOverride property in our TSconfig. To ignore set this property for our RTE, we can add the following line to the TSconfig on our main page: RTE.default.ignoreMainStyleOverride = 1 The inlineStyle assignments in TYPO3 create default classes for use in the RTE. You've probably already noticed some of them as options in the style drop-downs in the editor (Frame with yellow background, Justify Center, Justify Right, and so on). If we override the inlineStyle assignments, the default classes are removed from the RTE. Of course, we don't need to eliminate these classes just to use our own, but we can do this if we are trying to clean up the RTE for other editors or want to make our own alignment styles. Finally, we can use the contentCSS property to load our own external stylesheet into the RTE. To use our own stylesheet, we will use the following code in the TSconfig to use a new stylesheet named rte.css in our editor: RTE.default.contentCSS = fileadmin/templates/css/rte.css At this point, we're all pretty used to the syntax of TypoScript, but a review might be in order. In the previous line of TypoScript, we are updating the contentCSS property in the default instances of the RTE object with the new value fileadmin/templates/css/rte.css. If you understand that line, then everything else we're about to cover will be easy to pick up. As we want to use our own CSS file and override the defaults at once, this will be the TypoScript for our TSconfig: RTE.default { contentCSS = fileadmin/templates/css/rte.css ignoreMainStyleOverride = 1 } Of course, the next thing we need to do is create our new stylesheet. We don't want to use the complete stylesheet that we are using for the frontend because it could be thousands of lines and will have a lot of formatting and page layout rules that we don't need for simple text editing. Instead, we can just copy the most important text and paragraph styles from our style.css file in the fileadmin/templates/css/ directory into a new file called rte.css. In addition, we're going to add two new classes to style.css and copy them over; we'll create a class named blue to set the font color to pure blue and a class named red to set the font color to pure red. This should be the content of our new file, rte.css: p, ul, div { color: #666; font-size: 12px; line-height: 18px; } h1 { font-size: 24px; line-height: 36px; margin-bottom: 18px; font-weight: 200; font-variant: small-caps; } h2 { margin-bottom: 18px; line-height: 18px; font-size: 18px; } h3 { font-size: 15px; line-height: 18px; } h4, h5, h6 { font-size: 12px; line-height: 18px; } ul, ol { margin: 0px 0px 18px 18px; } ul { list-style-type: circle; } ol { list-style: decimal; } td { padding: 5px; } :link, :visited { font-weight: bold; text-decoration: none; color: #036; } .blue { color: #0000ff; } .red { color: #ff0000; } With our new CSS we will notice at least a subtle difference in our RTE. In the following screenshot, we can see the original RTE on the left and the updated RTE on the right. As you can see, our text is now spaced out better and lightened to match the frontend: As we have overridden the default classes without creating any new ones, the Block style and Text style drop-downs are both empty now. In the RTE, block styles are used for the "blocks" of our content such as paragraphs and headings while the text styles are applied directly to words or pieces of text within a larger block. Put simply, if we wanted a whole paragraph to be blue, we would use the Block style drop-down, and we would use the Text style drop-down if we only wanted a single word to be blue. Both of these drop-downs use our CSS classes for styling, so we'll go ahead and create our new classes in the TSconfig. Classes properties All of the classes in our external CSS file (rte.css) are made available as soon as we declared the file with the contentCSS property. If we want to use them, we just need to associate them with a style type (paragraph, character, image, and so on) for the default RTE. If we wanted to associate the blue and red classes with text styles, for example, we would add the following to our page's TSconfig: RTE.default.classesCharacter = blue, red Before we assign the classes to a type, we should declare them in the TSconfig so they show up properly in the RTE. By declaring the classes, we can set the titles we want to show in the RTE and how we want the titles to be styled in the drop-downs. Without declarations, the styles will still show up, but the titles will just be CSS class names. We want to declare them in TSconfig with specific title to make our editors' lives easier. We can add the following code to the TSconfig to declare the classes in our RTE and set more descriptive titles that will be shown in blue or red in the drop-down menus: RTE.classes { blue { name = Blue Text value = color: blue; } red { name = Red Text value = color: red; } } We can use CSS classes for more than just the text style, of course. The table below shows all of the main ways that we can associate and use classes in the htmlArea RTE, but you can read more in the htmlArea TSref. Go ahead and try some of them out with the example TypoScript lines that are shown. RTE class properties Toolbar properties Along with what shows up inside the content of the RTE, we can modify the toolbar itself to control what editors are able to see and use. By controlling the toolbar, we can make the RTE easier for editors and make sure that the branding and styling is consistent. The table below shows some of the most useful properties we can use to alter the toolbar available to editors. We can actually go much further in editing the individual buttons of the toolbar, but this is changing enough between major releases that I recommend using the TSref as a reference for your version of the htmlArea RTE. HTML editor properties Finally, we can change the way that the RTE works with HTML. For example, the RTE uses paragraph tags (&ltp></p>) for all blocks in our text area, but we can replace this behavior with break tags (&ltbr />) if we want. The RTE also strips certain tags, and we can change that with RTE properties as well. The following table shows the most common properties that we can use in the Page TSconfig to modify the HTML in the htmlArea RTE. Even if we don't need anything else in this section; using allowTags to allow embedded video can make our editor" lives easier if we want to embed YouTube or Vimeo players in our website. All of this information is also available in the TSref for the htmlArea if you need an updated reference.
Read more
  • 0
  • 0
  • 3755

article-image-getting-modular-moodle
Packt
22 Nov 2010
9 min read
Save for later

Getting Modular with Moodle

Packt
22 Nov 2010
9 min read
  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.) Changing site-wide settings Activity modules and blocks can have site-wide settings that you can adjust. These settings allow consistent changes in the use of the module across an entire site, but even during testing you might want to change such settings. It may be that you just want to see what settings can be changed globally for a module. Getting ready To achieve this you must have your web server running with Moodle installed. You need to be able to log in as the administrator, or get the help of someone who can. You should have installed the modules that you want to change settings for. The following steps assume you have installed the Progress Bar block, which has global settings that can be changed. How to do it... Log in as the site administrator and visit the root page of the site. To get to the global settings of a module, on the Site Administration menu, select Modules, then Activities or Blocks, whichever is appropriate. The Progress Bar block is a block, so select Blocks to reach its global settings. The next step is to select the name of the module. For our test, the module name is Progress Bar. The settings for the module should appear in a form. Not all activity modules or blocks have global settings. For many modules, this is not necessary. Changes to the global settings affect the configuration of the module, including any instances that may already exist, and any that are added in future, across the site. There's more... Be a little careful when changing global settings on a live site. If the module is currently in use, changing global settings can affect the experience of students and teachers. Accidentally using invalid global settings can detrimentally affect the running of the module on the site. See also Adding modules to Moodle Getting rid of modules Getting modules to speak your language Another feature of Moodle is its capacity for internationalization. This means that the same software can be used by people speaking different languages. While translations for over 80 languages are available for the core functionality of Moodle, most modules only offer translations for a smaller number of languages, and the language you are teaching in may not be one of them. Adding a translation for a module is simple to do. If you give your translation to the author of the module, your efforts could also benefit others who speak your language. Getting ready It is assumed that you have set the default language for your site. If not, there is more information about adding a language pack and setting the language for your site later. In order to create a translation for a module, you don't need any real programming experience; it's actually quite simple. Some understanding of HTML tags can be an advantage. You will need a text editor that can create and edit Unicode files. Word processors are not appropriate for this task, and a simple editor, such as Windows Notepad, is not up to the job. There are many free editors available that will allow you to create and edit Unicode files. One example available for Windows is Notepad++, which is a free editor and is also available as a portable application. The steps that follow provide an example that assumes the Progress Bar block has been installed. How to do it... Where the module was installed, there will usually be a /lang folder. For the Progress Bar block this is located at moodle/blocks/progress/lang. Within this folder, there are folders for different languages, most of them contributed by users around the world. If you are reading this, it is assumed you have an understanding of English, so have a look inside the en_utf8/ folder. You will see a file called block_progress.php and another directory called help/. The block_progress.php file contains strings of text used in the module, each with a code and the string displayed on screen. Open this file in your editor to see the contents. Inside the lang/help/progress/ directory there are a number of HTML files, each relating to a help topic. These appear when a help icon (usually appearing as a question mark) is clicked. Opening these files in your web browser will show you the rendered version of these files and opening them in your editor will show you the HTML source of the documents. To add a new language, you first need to find out the two letter code for your language. To see the list of supported languages visit the following site. You will also see the code letters for each language, and you need to follow the same code. Refer to http://download.moodle.org/lang16/. Return to the lang/ folder. For the Progress Bar block this is at moodle/blocks/progress/lang/. Assuming that you know English as a second language, copy the en_utf8/ folder and all of its content. Rename the folder with the two letter code for your language, for example, the folder for Afrikaans would be af_utf8/. Be sure to preserve the filenames and folder names within (they do not need translation, only the contents). Open the block_progress.php file in your Unicode editor. You need to translate the string on the right of the = symbol, within the quotes. Do not translate the code value for the string on the left. You may need to see the string in use to get a sense of what the string is intended for, in order to make an accurate translation. If you include any apostrophes within the string, escape the quote with a slash, as shown in the following example, otherwise the string will be seen as coming to an end earlier than it should. $string['owners'] = 'Owner's'; If there is code within the strings, or HTML tags, that you are unsure about, leave these and just translate any text around them. You can also translate the HTML files in moodle/blocks/progress/lang/help/progress/ to produce help files in your language. Open these in your editor and translate the text within the files. Again, avoid changing any HTML or code you don't understand. Some help files also include PHP code segments within <?php and ?> tags, avoid changing this content. Be sure to test your translated files. If, after changing a translation file, nothing appears on the course page, it may be that you have inadvertently created an error. Typically this comes from mismatched quotes around strings. Be sure each starting quote is matched with a closing quote, and any enclosed quotes are escaped. Test that your translated text items are appearing correctly and have an appropriate meaning in your language. Once created, you can use this translation throughout your site. The final step is to send your translation to the author of the module. You should be able to find their contact details on the Moodle Modules and plugins database entry page for the module. If you have translated the language strings but not translated the help files, this is still a helpful contribution that can be shared. Zip up the files you have translated and e-mail them to the author who will usually be more than happy to include your contribution within the module for future downloaders. How it works... Each time the module is loaded, its code is interpreted by the web server and HTML is produced to form the part of the page where the module will appear. Within the code, instead of writing text strings in the author's language, there are calls to functions that check the language and draw the appropriate strings from the language files. This way, all that is needed to change from one language to another is a different language file. There's more... If you want to use another language throughout your Moodle site, the following sections are a basic guide for installing and selecting the language. Adding a language pack Visit the following site to find if a language pack is available for your language: http://download.moodle.org/lang16/. If your language is available, download the appropriate zip file and extract its contents to the directory moodle/lang/. If your language is Afrikaans, for example, the language files should be contained in moodle/lang/af_utf8/. Ensure you do not introduce additional unnecessary directory levels. Selecting a language for your site and courses A language can be set as a default for courses on the site. This can be overridden at the course level if desired, or by students individually. To set the default language, log in as administrator and go to the site root page. On the Site Administration menu, select Language, then Language Settings. The default language can be set on the page that appears. Individual users can set a preferred language in their profile settings. For individual courses a language can be set. This will "force" students to use that particular language rather than their preferred language. See also If it's not quite what you want...
Read more
  • 0
  • 0
  • 6713

article-image-working-flexible-content-elements-typo3-templates
Packt
19 Nov 2010
17 min read
Save for later

Working with Flexible Content Elements in TYPO3 Templates

Packt
19 Nov 2010
17 min read
  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.        Introducing flexible content elements I just said flexible content elements are like mini-templates, but they are actually a little more sophisticated than that. TYPO3 templates, traditionally, are just used to design the pages of your website. Well, flexible content elements are there as a way to create our own specialized types of content elements. Flexible content elements give us most of the power that we've had in the main TemplaVoila templates; the workflow and structure is almost exactly the same. We still have a data structure and a mapped object for each template, and we can still create backend layouts and preview images to help our editors. So, we already have all the raw skills we need to start creating them, but we just need a few examples of where we would want them. Creating a flexible content element really is just like creating a new content type for our sites utilizing the power of TemplaVoila. Once created, they can be embedded into any templates or even other FCEs. We can use references to link them across separate pages. We can copy them around between TYPO3 installations easily. We can even update the main template object or data structure of an FCE and watch our changes reach to every instance of that content element in our page tree. The best examples of this are going to be some of the ones we're about to build: a contact section, a div to wrap around other content elements, a multi-column element, and a custom product layout. Creating our first flexible content element The first FCE we're going to create is going to be simple enough to show us the basic workflow, but it's also a pretty handy trick so that we can add our contact information onto multiple pages using consistent formatting across our site. We're going to create a new flexible content element for our contact information using microformats (http://microformats.org/) so that Google and some browsers can read our address, phone number, and email address easier. Normally, this would require a lot of extra work to place it on multiple pages, but we can create an FCE that our editors can add to any page just like a normal content element. Building the content element Of course, the first thing that we should do is create an HTML file that we can use for our mapping. FCEs are normally mapped to a part of a complete HTML template, while page templates are mapped to the whole file. For our example, we will create one universal HTML file to hold all of our flexible content element HTML snippets called template_fce_snippets.html in the fileadmin/templates/ directory. At this point, we can create our HTML that the FCE will be based on. Like we said before, we are going to use microformats so that our contact information can be read by software more easily. To use microformats, we are just going to add some specific class names to the span and div tags around our information. If you would like to see more information about microformats, I recommend going to http://microformats.org/. For now, we can add this code into our template_fce_snippets.html file: <!DOCTYPE HTML> <html> <head> <meta charset="utf-8" /> </head> <body> <div id="contact_info_section"> <h3 id="contact_info_title">Contact Us</h3> <div class="vcard"> <div class="fn org">Example.com</div> <div class="adr"> <div class="street-address">1214 Rebekah Ave. </div> <span class="locality">Dallas</span>, <span class="region">TX</span> <span class="postal-code">75154</span> <span class="country-name">USA</span> </div> <div class="tel">(212) 555-1212</div> <a class="email" href="mailto:[email protected]">[email protected]</a> </div> </div> </body> </html> We are ready to start creating the TemplaVoila structures now, so we can go to the TemplaVoila Control Center in the backend of our installation now. We can create a new data structure by going to the Template Files tab in the control center. To create a new template object and data structure simultaneously based on our new HTML file, we need to click on the Create... link for our template file, fileadmin/templates/template_fce_snippets.html. Now we need to choose the root data element. Go ahead and choose the main div tag (circled in the following screenshot). We need to make sure we set the mapping mode to OUTER (Include tag). Due to an oddity in TemplaVoila, outer mapping is the only way to make sure that we actually keep the contact_info_section class after mapping. It may be counter-intuitive, but TemplaVoila treats root elements exactly the opposite of all other elements in its implementation of outer and inner mapping modes. Click on Set to start creating our data structure. Now that we have set the root, we can add our own fields to the FCE data structure. All of our contact information can be static, so we will just create a field for the header. Like the page templates, we will create a new field by filling the in name, field_header, at the bottom of the page as shown in following screenshot, and click on Add. Now we can fill in the form for our new field. We will set the Title to Header, and we can set the Sample Data as [Header goes here]. As we are using this as a header, we can choose Header field as our Element Preset. After we have filled out the form as shown in the following screenshot, we can click on Add to save our settings. Map the header field to the h3 tag in our HTML template and click on Set to save the mapping. We've finished creating our small content element, so we can click on the Save as button in our builder screen and save our progress. We are creating a new data structure, so we will need to fill out the CREATE Data Structure/ Template Object portion of the TemplaVoila save screen. We will give our new element an easy title, Contact Information. We also need to make sure we choose Content Element from the Template Type drop down because we are creating an FCE instead of a page template this time. Our screen should look something like shown in the following screenshot before we click on the CREATE DS / TO button: Testing our new content element We can add our element to any page the same way we've been adding text or graphic elements in the past through the Page view. Go to the main page in the backend of TYPO3 and click on the new element button (circled in the following screenshot). Added to the choices of standard or extension-based elements, we can see our own flexible content element, Contact Information [Template], listed. Go ahead and choose it to add it to the page. The next screen we see is the content editing screen where we can fill in the header for our new element: Finally, we can save our new content element and see the output on the frontend (highlighted in the following screenshot): Creating a flexible HTML wrapper As a website grows, we sometimes run into times where we would like to assign a special style to a content element or group of content elements, but there is no easy way to do this in TYPO3 without creating a new page template. All we really want to do is wrap a div tag around the group of elements we are styling with a CSS class to give them any style we need from our own stylesheets. For example, we might want to highlight a group of content elements with a color background or border. We will create a flexible content element to output a div tag with a blank class attribute that can contain normal page content elements. The FCE will have a field for the class, so our editors can fill in whatever class they need to use later. We're also keeping control over the options that editors have. They are still restricted to using CSS classes, as opposed to arbitrary style attributes, so we have not given them too much freedom. Building the content element First, we can create our HTML to which the FCE will be mapped. All we need is a div tag with a blank class attribute, so we can just add our snippet to the bottom of /fileadmin/templates/template_fce_snippets.html. We will also add some HTML comments around our new snippet so that we can always identify it in the HTML file: <!-- BEGIN HTML Wrapper --> <div class=""></div> <!-- END HTML Wrapper --> Now, we go back to the TemplaVoila module in the backend. From the Template Files tab in the TemplaVoila Control Center, click on Create... next to the file fileadmin/templates/template_fce_snippets.html label. Go ahead and choose our new div tag between the HTML comments (circled in the following screenshot) and click on Set to start creating our data structure. Again, choose OUTER (Include tag) as our mapping mode. The first field we need to create is the wrapper field for the content element. We have already set the div tag as the root element, but we still need to create a separate field to handle content elements or we won't be able to add content into our new FCE in the Page view. Like before, we can create a field by filling in the new field text area with a new name, field_wrapper, and clicking on the Add button. Now we can create the field with the following values just like we did when we added fields to our main templates. Like our page templates, we are going to use the Page-Content Elements preset because it allows us to place other content elements inside our new field: Field: field_wrapper Element Title: Wrapper Sample Data: [Content goes here] Element Preset: Page-Content Elements Once we have created and saved our new field, we can map it to the div tag by clicking on the Map button. We can use inner mapping this time because we want to keep the tag and this is not the ROOT field. The next field we need to create is the class field so that we can edit the class from the page module. Instead of an element, we are creating an attribute. To create the new field, fill in the name, field_class, at the bottom of our page and click on Add. Choose Attribute from the drop down on the left side and fill out the field values: Title: Class Sample Data: [Class field] Element Preset: Plain input field After we have created the new class attribute and saved it, we can map it to the class attribute in our div tag. If we click on the Map button for the class field, we see that we can only choose the div tag to map to; this is okay. If the div tag is grayed out or disabled, we probably need to check that the root element was set with OUTER mapping. After we click on the div tag, we are presented with a slightly different mapping screen than we have seen before. Up until now, we have been mapping tags instead of attributes, so our choice has been INNER or OUTER mode. When mapping attributes, this drop down will show any blank attributes that exist within the HTML template for that tag. If we wanted to set a relation attribute, for example, the HTML just needs to have rel="" present in the tag with or without a value. For now, we can choose ATTRIBUTE "class" (= ) from the drop down and click on the Set button to continue. We've created all of the fields we need for this small content element, so we can click on the Save as button to save our progress. We will give our new element an easy title, HTML Wrapper. We also need to make sure we choose Content Element from the Template Type drop down again. Testing our new content element We now have a data structure and template object created as a flexible content element and mapped, so we are ready to test. We can test with almost any class from our stylesheet, but we'll make it easy by adding a new class style to the bottom of our style.css file with a color background, rounded corners, and a slight shadow to highlight content: .alert { background-color: #BBCCDD; padding: 10px; -webkit-border-radius: 10px; -moz-border-radius: 10px; border-radius: 10px; box-shadow: 2px 2px 5px #888; -webkit-box-shadow: 2px 2px 5px #888; -moz-box-shadow: 2px 2px 5px #888; } As an example, we can highlight a couple of bullet lists on the Bulletlist page that the TemplaVoila wizard created. Go to the Bulletlist page in the backend of TYPO3 and choose to add a new element like we did for the Contact Information FCE. This time, choose HTML Wrapper [Template] for our new element. The next screen we see is the editing screen, and we can see that the titles we gave our data structure fields are showing up along with the different form elements we just declared. We can add elements to the wrapper here, but it's easier in the page module. Instead, we'll just set the Class field to alert to match our stylesheet, and save our new element. Finally, in the page module, we can drag elements into our new content element, and our new div tag with a class we have set in the settings will wrap around them. We can drag two of our bullet lists into the FCE: If we look at our edited page on the frontend, we can see the new CSS styling applied immediately: Creating a multi-column layout element As helpful as a wrapping div tag can be, we should start getting a little bigger with our goals. One thing that we run into all the time in the real world of site development is the need to have multi-column elements. With the rise of grid-based design and content-heavy sites, it's getting more popular to start adding two columns into the main content area under a single column article or something similar. Unfortunately, there are a lot of variations on this idea of mixing and nesting multi-column layouts, and it's not always possible or smart to create a template for every possible variation in a limited amount of time. You can easily waste all your time creating templates with a two-column element over a three-column element over a two-column element over a single-column element. I know that sounded confusing, and that's the problem. Instead, we can create a handful of useful multi-column flexible content elements that our editors can use anywhere they need to and in any order they need to. They can even nest them inside of each other if we do this right. Right now, we're going to make a quick FCE with two columns that take up roughly half of the current content area. We're just going to start by adding some basic styling to our main stylesheet, fileadmin/templates/style.css: .multi_column_element { display: inline-block; width: 100%; } #nested_column_1 { float: left; clear: left; } #nested_column_2 { float: right; clear: right; } .half { width: 49%; } As you can see above, we are using inline-block as the display setting for the entire element. If we don't set that, then the elements below it can creep up when we start using floats. For more information on CSS values like inline-block, I recommend the tutorials from w3schools.com (http://www.w3schools.com/css/). In addition, our style floats the first column, nested_column_1, to the left and clears anything to its left. The second column, nested_column_2, floats to the right and clears anything to the right of it. If we assign the class half to both columns, then they will both take up a little under 50% of the total width with a little whitespace in the middle. After we've modified the CSS, we need to update our HTML file. Once again, we'll add our new HTML code with identifying comments into our HTML template, /fileadmin/templates/template_fce_snippets.html. Go ahead and add some basic code to the main FCE HTML file to create two divs for columns: <!-- BEGIN 1/2 + 1/2 Element --><div class="multi_column_element"> <div class="nested_column half" id="nested_column_1">Column 1</div> <div class="nested_column half" id="nested_column_2">Column 2</div> </div> <!-- END 1/2 + 1/2 Element --> Now we're going to follow most of the same steps from the previous examples starting with the creation of a new data structure: From the Template Files tab in the TemplaVoila Control Center, click on Create... next to the file fileadmin/templates/template_fce_snippets.html label. Choose the main div tag that wraps around the entire HTML template as the root field. Again, we need to make sure we set the mapping mode to OUTER (Include tag). Create a new field for the first column named field_column_1. As the float is set completely in CSS, we will not refer to the columns as left or right columns here. This means we could swap the columns in CSS or assign different identifiers in the HTML without breaking our data structure. Go ahead and create our new field with these values: Field: field_column_1 Element Title: Column 1 Sample Data: [Column #1 goes here] Element Preset: Page-Content Elements Save the first field and map field_column_1 to the div tag with the ID nested_column_1. Make sure that you select inner mapping so that the classes and identifiers are left in the div tag. Create a new field for the second column with almost the same values as the first column: Field: field_column_2 Element Title: Column 2 Sample Data: [Column #2 goes here] Element Preset: Page-Content Elements Save the second column field and map it to the div tag with the ID nested_column_2 in the HTML. Click on the Save as button to save our new data structure and template object. Set the title as something memorable, Two-Column Element, before choosing Content Element as the Template Type and clicking CREATE DS / TO. As easy as that, we've just created another FCE. We can test this one on the main page of our test site by creating a new content element with our new FCE, Two-Column Element, and dragging our current blocks into either side: With two even columns, our front page should look something like this:
Read more
  • 0
  • 0
  • 3077
article-image-drupal-6-theming-adding-and-optimizing-css-files
Packt
19 Nov 2010
8 min read
Save for later

Drupal 6 Theming: Adding and Optimizing CSS Files

Packt
19 Nov 2010
8 min read
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.
Read more
  • 0
  • 0
  • 2193

article-image-updating-software-koha
Packt
16 Nov 2010
4 min read
Save for later

Updating Software in Koha

Packt
16 Nov 2010
4 min read
  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.
Read more
  • 0
  • 0
  • 2179

article-image-introducing-graphic-menu-typo3
Packt
16 Nov 2010
9 min read
Save for later

Introducing Graphic Menu in TYPO3

Packt
16 Nov 2010
9 min read
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:
Read more
  • 0
  • 0
  • 1417
article-image-introducing-hierarchical-menu-typo3
Packt
16 Nov 2010
6 min read
Save for later

Introducing Hierarchical Menu in TYPO3

Packt
16 Nov 2010
6 min read
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
Read more
  • 0
  • 0
  • 2563

article-image-different-types-q-replication
Packt
16 Nov 2010
5 min read
Save for later

The different types of Q Replication

Packt
16 Nov 2010
5 min read
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.
Read more
  • 0
  • 0
  • 3433