How-To Tutorials - Web Development

  Learning Ext JS 3.2 Build dynamic, desktop-style user interfaces for your data-driven web applications using Ext JS Learn to build consistent, attractive web interfaces with the framework components Integrate your existing data and web services with Ext JS data support Enhance your JavaScript skills by using Ext's DOM and AJAX helpers Extend Ext JS through custom components An interactive tutorial packed with loads of example code and illustrative screenshots           Read more about this book       (For more resources on Ext JS, see here.) Objective: Button focus and tab orders are built in. Tip: Button focus and tab orders are built into Ext JS Components. For the MessageBox Component, the OK or Yes button will be the default action, so pressing Enter on our keyboard when a MessageBox appears will trigger that button, and pressing Tab will move us through the buttons and other items in the MessageBox. Windows have the ESC key mapped to the Close tool. When using button bars in other Componenets, tabbing through the buttons is enabled by default and in Toolbars like the PagingToolbar tabbing is also built in. Objective: Duplicate Component ID's must be avoided. Tip: Having duplicate IDs in our document can lead to strange behavior, such as a widgets always showing up in the upper-left corner of the browser, and must therefore be avoided. Objective: Other uses of Button config on a MessageBox. Tip: The buttons config for a MessageBox can also specify the text to display on the button. Instead of passing a Boolean value, just pass it the desired text to display, for example, {yes: 'Maybe'}. Objective: Ext does not require any pre-existing markup. Tip: Ext does not require any pre-existing markup for it to function, this is because it generates everything it needs on its own. This let's us start with a very simple HTML document containing an empty body. Objective: Avoid using the built in JavaScript alert messages. Tip: Standard JavaScript alert messages pause code execution, which can cause unexpected results. You should not be using the built in JavaScript alert messages, and instead use Ext's MessageBox widget or console messages (when available), which does not pause that code execution. Objective: Creating form Field validation types (vType). Tip: A search of the Ext JS forum is likely to come back with a vType that someone else has created with exactly what you need, or close enough to use as a starting point for your own requirements, so search the Ext JS Forums before trying to write your own. Objective: Simple and quick static options for a ComboBox. Tip:; A quick way to specify a few static options for a ComboBox is to pass an array to the store config, which will auto-create the store for you. So if we wanted a ComboBox that had 'Yes' and 'No' as options, we would provide ['Yes','No'] as the store config value.

  Ext GWT 2.0: Beginner's Guide Portlet class The Portlet class extends ContentPanel to provide a special type of panel that can be repositioned in the Viewport by the user with a Portal container. It may appear similar to a window in a desktop application. Creating a Portlet is similar to creating other containers. This code: Portlet portlet = new Portlet(); portlet.setHeight(150); portlet.setHeading("Example Portlet"); creates a Portlet like this: A Portlet can be excluded from being repositioned by pinning it using: portal.setPinned(true); Apart from that, a Portlet inherits all the features of a standard ContentPanel. The Portal class A Portal is a special container for Portlet components. In fact, it is a Container containing a collection of LayoutContainer components arranged using ColumnLayout. Each of those LayoutContainer components in turn is able to contain Portlet components, arranged using a RowLayout. Portal also supports dragging and dropping of Portlet components, both in terms of changing the row it is in within a column and the column within the Portal. When creating a Portal, we need to set the number of columns the Portal should create in the constructor. We also need to set the widths of each column before using the setColumnWidth method of the Portal. So to create a Portal with two columns, (one using 30 percent of the width and the second 70 percent) we would define it as follows: Portal portal = new Portal(2); portal.setColumnWidth(0, 0.3); portal.setColumnWidth(1, 0.7); We can then add a Portlet to each column like this: Portlet portlet1 = new Portlet(); portlet1.setHeight(150); portlet1.setHeading("Example Portlet 1"); portal.add(portlet1, 0); Portlet portlet2 = new Portlet(); portlet2.setHeight(150); portlet2.setHeading("Example Portlet 2"); portal.add(portlet2, 1); This will produce the following output: Both Portlet components can be dragged and dropped into different positions. The Portlet turns into a blue box while being dragged as shown in the following screenshot: A Portlet will automatically resize and ft into the column in which it is dropped, as seen in the next screenshot: ToolButton Like ContentPanel that Portlet extends, we can add ToolButton components to the header. These can be very useful for making a Portlet look and behave even more like windows in a desktop application. portlet.getHeader().addTool(new ToolButton("x-tool-minimize")); portlet.getHeader().addTool(new ToolButton("x-tool-maximize")); portlet.getHeader().addTool(new ToolButton("x-tool-close")); The output can be seen as shown in the following screenshot: At the moment, we are using ContentPanel components in our example application and laying them out using a BorderLayout. We shall now see that it does not take much to change the ContentPanel components into Portlet components and manage them using a Portal. Portlet components are ideally suited to being independent, self-contained user interface elements that respond to the data passed to them. Rather than tying them into a Portal directly, we can use the MVC components to cause the Portal to respond to the creation of a new Portlet to preserve that independence. Time for action – creating a Portal Controller and a Portlet View The first thing we need to do is add a new EventType to the existing AppEvents class named NewPortletCreated. We will fire this when we create a new Portlet. public static final EventType NewPortletCreated = new EventType(); Create a new class named PortalController that extends Controller. public class PortalController extends Controller { Create a new class named PortalView that extends View. public class PortalView extends View { Create a constructor that sets the Controller of the PortalView. public PortalView(PortalController portalController) { super(portalController); } Returning to PortalController, create a variable to hold the PortalView and override the initialize method to set the view. private PortalView portalView; @Override public void initialize() { super.initialize(); portalView = new PortalView(this); } Create a constructor that registers each EventType the PortalController should observe, specifically NewPortletCreated creation and Error. public PortalController() { registerEventTypes(AppEvents.NewPortletCreated ); registerEventTypes(AppEvents.Error); } Override the handleEvent method to forward any events to the View apart from errors which for the time being we will just log to the GWT log. @Override public void handleEvent(AppEvent event) { EventType eventType = event.getType(); if (eventType.equals(AppEvents.error)) { GWT.log("Error", (Throwable) event.getData()); } else { forwardToView(portalView, event); } } Returning to PortalView, create a new portal field consisting of a Portal component with two columns. private final Portal portal = new Portal(2); Override the initialize method to set the width of the two columns, the first to 30 percent of the width of the Portal and the second to 70 percent. @Override protected void initialize() { portal.setColumnWidth(0, 0.3); portal.setColumnWidth(1, 0.7); } Now create a Viewport, set the layout to FitLayout, add the Portal, and then add the Viewport to GWT's RootPanel. @Override protected void initialize() { portal.setColumnWidth(0, 0.3); portal.setColumnWidth(1, 0.7); final Viewport viewport = new Viewport(); viewport.setLayout(new FitLayout()); viewport.add(portal); RootPanel.get().add(viewport); } We also need to implement the handleEvent method of the View. For now, we will catch the NewPortletCreated event, but we will not do anything with it yet. @Override protected void handleEvent(AppEvent event) { EventType eventType = event.getType(); if (eventType.equals(AppEvents.NewPortletCreated )) { } } Finally, go to the onModuleLoad method of the EntryPoint RSSReader class and instead of creating an AppController, create a PortalController, and remove the line that forwards an Init AppEvent, as we will not be using it. The onModuleLoad method will now look like this: public void onModuleLoad() { final FeedServiceAsync feedService = GWT.create(FeedService.class); Registry.register(RSSReaderConstants.FEED_SERVICE, feedService); Dispatcher dispatcher = Dispatcher.get(); dispatcher.addController(new PortalController()); } What just happened? We created the basic framework for a Portal layout of our application. However, if we started it now, we would just get a blank screen. What we need to do is add Portlet components. The actual Portlet components are not too complicated. They will just act as wrappers.

  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.       What are web services? In order for our Drupal site to communicate and interact with other web applications, such as Flickr, Amazon, Mollom, or Twitter, we need to use standard communication protocols in the web development world called web services. Web service protocols will allow applications that reside on external websites and servers to interact and communicate with our Drupal website that is running on our own server. Web services will also allow our Drupal site to pass along content and data to external web applications existing on remote servers. When we define web services, we need to point out that this type of communication provides for interoperability. This means that a web service communication can happen between two completely different environments but still work because we use standard protocols to make it happen. Web services allow us to call another application on a remote server. A good analogy to this is using your cell phone to call a friend or colleague. You have one type of cell phone using one type of cell phone service. You call your colleague's cell phone. They have another type of cell with a different service provider, but the call goes through and is successful because the two services communicate with each other using standard cell phone communication protocols. The web service call happens through coded protocols that are translated into a language and standard protocol that both computers can understand. Generally, this is done by using the XML language to translate the programmed request into the other external applications. Web applications have a standard in which they can usually read XML files. XML is a text-based format, so nearly all computer systems and applications can work with the XML format. The web services protocol also uses a concept called remoting or Remote Procedure Calling (RPC) that allows one application to initiate or "call" a function inside of an application on a remote server. Our Drupal site can communicate with an application on a remote server and call a function in that application. For example, we might want to make our Drupal website call and interact with our Flickr photo gallery, or we may want to take all of our Drupal home page content and push it over to our Facebook account. We can do both of these actions using the web service protocols. XML and web services As mentioned above, the base foundation for web services is a protocol or code called XML. For our Drupal site residing on our server, to talk and interact with a website or application on another server, we need to use XML, which is a language commonly understood between different applications. Our site and server understands XML as does the application we want to communicate with. We can do this over the standard HTTP protocol for website communication, as HTTP is the most standard protocol for Internet communication. The reason we use XML for communication between the applications and the sites is because XML replaces the proprietary function (whether the function is in RPC or another programming language or interface) and formats it into the standard XML code format. This allows applications to understand each other easily. An analogy to this is: if we have two people, one from Germany and the other from France, speaking to one another, and neither person knows the other's language but both of them know English, then they must speak in English, as it's a language they both understand and can easily communicate in. It's a similar situation when XML is used to translate a web service's function into a commonly understood format. So first we need to send the function call to a remote application. Our calling application or website creates the XML document that will represent the programmed function we want to execute. The XML is then transmitted over HTTP to the remote application and it can then be interpreted and understood by the remote application. The remote application then executes the function based on the XML formatting. Some examples of web service's methods are SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery and Integration), WSDL (Web Services Description Language), XML-RPC (XML Remote Procedure Call), JSON (JavaScript Object Notation), JSON-RPC, REST (Representational State Transfer), and AMF (Action Message Format). We are not going to look at these interfaces in detail now. For now, it's helpful for us to understand that these protocols and platforms exist and that our Drupal site can provide web services to other applications via these multiple interfaces and platforms. Here's a diagram that outlines a simple web service request and response. This is a request sent from our Drupal site (client) over HTTP to an external server to request data. The data exists on the server (remote) in the form of a URI (Uniform Resource Identifier) item. The response is sent back to our Drupal site through XML. The REST protocol Let's look briefly at one web service protocol and technology, and define it. As mentioned before, there are many technologies you can use to implement web services. REST (Representational State Transfer) is one such technology. The reason REST is a preferred technology within the web development and Drupal community is due to its flexibility and standards. REST allows us to do the following when we initiate a web service using its protocol: Use a standard method such as XML as our message format Send the message over standard protocol such as HTTP Provide or connect to specific resources where each resource (image, document, page, and node) is given a unique resource identifier (a URI) We can take this concept and try it out on our Drupal site by writing some PHP code that makes an HTTP request to another web application resource. For example, we may want to make a call to a Picasa photo gallery and feed a select number and type of photos back to our Drupal site and display the photos in a Drupal node on our site. The request targets this specific resource by making a GET request to the URI of the resource. The application we are communicating with sends a response back to us in XML format. That XML can then be integrated into our Drupal site using a module, for example. The request might be made to a user's Flickr or Picasa photo gallery. The request gets returned to our Drupal site as XML and we parse this XML into our Drupal site and the user's photos or gallery then get displayed on our site. This is just one protocol example. Greg Hines of pingVision provides a good introductory resource on REST and Drupal in the document titled RESTful Web Services and Drupal. The document is available on pingVision's website as a PDF download from: http://pingvision.com/files/restful_web_services_and_drupal.pdf Standards compliance As discussed in the REST protocol's example, web services and Drupal's use of web services follow specific standards. In order to maintain as much interoperability and flexibility as possible, all of the protocols used respond for the most part using XML as the standard response mechanism and format. Additionally, all the communication between services, in our example between a client and a server, happens over HTTP (the standard web protocol). This is a uniform protocol that is used for transport and communication of the service. All transports take place uniformly using GET, POST, PUT, and DELETE requests, for example. The HTTP requests are stateless, meaning that the request over HTTP happens once at one given moment and is isolated from all other activated requests. So the request stands alone. If it succeeds, it gets a response. If it fails, it gets no response from the server or application it's communicating with. The request can be repeated an infinite number of times. Finally, all of the resources we try and access are those that we are sending to another application using a unique resource identifier (URI) to identify and define what they are. So images on our site have unique identifiers as well as those residing in another web application. Each of these unique identifiers allows for addresses or locations for each node or file in question. So each resource in a web service's communication has an address. Each resource has one URI and each address has one URI. Some examples of this would be the following locations on my Drupal site: http://variantcube.com/ http://variantcube.com/recommended-drupal-resources http://variantcube.com/node/68 http://variantcube.com/search/node/podcast http://variantcube.com/rss.xml Another reason we want to be standards compliant, when writing or working with web services, is for simplicity. We do not need any special tools to program web services as long as we follow these standards. We can use the web application modules and PHP, and stick to these coding standards and protocols. Why are web services useful? Web services are useful for a number of reasons, especially when it comes to Drupal and Drupal's relationship and interaction with other web content management systems and applications. The web has a huge number of web applications, so web developers and content developers can pass their content to the web browsers and make it available to the web visitors. This is why the Internet is useful to us. We can go to a website and view the content. Whenever we do that, we're looking at content that is proprietary to a specific web application. In Drupal, our content is in the form of nodes, for example. We may want to share these nodes with other websites that are non-Drupal, such as a Wordpress-powered site. Web services are useful because they present us with an architecture where a resource on a site (an image, textual content, such as a node ID or block ID, a video or audio file) is given a unique identifier. For example, in Drupal, every node has an ID. Every file you upload to a Drupal site also has a unique path to it. This is extremely useful since all applications share this common semantic standard. We name things similarly on all of our web applications. We can then leverage this by writing code in PHP, for example, the one that calls these resources. The application server that houses the resource then responds to our request using an XML document. Why use web services in Drupal? With web services, we can take our Drupal content and share this content with other web applications and, essentially, with the web at large. Our content is no longer just our content and it is not specific to our Drupal website. It can be shared and integrated. Drupal's codebase is PHP-based and many of the popular web applications being used today, including Wordpress, Joomla!, and Flickr, are also PHP-based. So we have a common programming language we can work with and use to integrate these applications. Here are some concrete examples. Perhaps your Human Resources Department wants to integrate its job postings and applications with another web application such as Monster.com. Web services can allow this to happen. Your office's payroll department may want to connect to its bank account in order to pass data from the payroll reports over to its bank reporting mechanism. Web services can allow this to happen. You may want to take all of the photos you upload to your Drupal site in image galleries built with the Views module, and take these photos and send them to Flickr so that they automatically show up in your Flickr account or on Flickr's public site. Web services can make this happen. This leads to another advantage of using web services with Drupal and why we would choose to use Drupal in the first place. Instead of having to upload our photos twice—once to our Drupal site and then repeating the procedure to our Flickr site—web services allows us to upload the images to our Drupal site once and then automatically send that data over to Flickr without having to upload one (or even a batch of images) again. It saves us time and speeds up the entire process of generating web-based content. Additionally, there may be applications we want to use in our Drupal site, for example applications where we want to consume content without having to code again. We can just reuse these applications using the web services protocols and get this application content into our Drupal site. So we can consume web services. Examples of this would be converting currency on our site, feeding weather reports and other weather data into our site, feeding natural disaster scientific data into our site from services that provide it, feeding language translation services, feeding music podcasts, and more. Instead of having to reprogram this type of content, we can grab it from another web application and show it automatically on our site using web services Simply put, this opens up a method of easily sharing data and content resources between applications and machines that are running on different platforms and architecture. We have opened up a gold mine of capabilities here because we can talk to applications that run different software from our Drupal site and on different computing platforms. How Drupal uses web services Drupal can use web services following any of the protocols mentioned earlier, including XML-RPC, REST, and SOAP. Drupal can consume web services by requesting data from other web applications using RSS and XML-formatted requests. As a web developer, you can write your own service code in Drupal using PHP. You can also use the Services module as well as other service-specific contributed modules to create these web service requests. In this next section, we're going to look at both these examples. First, we'll see how Drupal works as a service consumer, where basically it is a client requesting data from an external server. We'll also look at how Drupal can provide services using the Services module, RSS, AMFPHP, and XML-RPC. Drupal as a service consumer Let's outline some brief examples of how Drupal consumes content and data from other web applications, including Mollom, Flickr, and Facebook. You can configure your Drupal site to consume various web services by using contributed Drupal modules for each specific task or application you are trying to consume. Drupal can consume services from applications that will help your website prevent spam, integrate photos, integrate taxonomy and tags, and enhance your Drupal free tagging and autotagging abilities, and integrate with applications such as Facebook and Twitter.

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.

IBM InfoSphere Replication Server and Data Event Publisher Design, implement, and monitor a successful Q replication and Event Publishing project Covers the toolsets needed to implement a successful Q replication project Aimed at the Linux, Unix, and Windows operating systems, with many concepts common to z/OS as well A chapter dedicated exclusively to WebSphere MQ for the DB2 DBA Detailed step-by-step instructions for 13 Q replication scenarios with troubleshooting and monitoring tips Written in a conversational and easy to follow manner We use the ASNMCMD command to manage a running RAM monitor. When we issue the asnmcmd command, we need to specify: The monitor server name The monitor name And then one of the following keywords: chgparms <parameters>, reinit, status, stop, qryparms, suspend, resume. Where <parameters> can be: monitor_interval=<n>, autoprune= [yn], alert_prune_limit=<n>, trace_limit=<n>, max_notifications_per_alert=<n>, max_notifications_minutes=<n>| We can issue this command from a different screen from which the monitor was started. Checking which monitors are active To check which monitors are active, we can use the ASNMCMD command with the STATUS parameter. So to check the status of the monac1 monitor on mondb, we would issue: $ asnmcmd MONITOR_SERVER=mondb MONITOR_QUAL=monac1 STATUS ASN0600I "AsnMcmd" : "" : "Initial" : Program "asnmcmd 9.1.0" is starting. ASN0520I "AsnMcmd" : "MONAC1" : "Initial" : The STATUS command response: "HoldLThread" thread is in the "is resting" state. ASN0520I "AsnMcmd" : "MONAC1" : "Initial" : The STATUS command response: "AdminThread" thread is in the "is resting" state. ASN0520I "AsnMcmd" : "MONAC1" : "Initial" : The STATUS command response: "WorkerThread" thread is in the "is resting" state. If there is nothing running, then we get the following messages: ASN0600I "AsnMcmd" : "" : "Initial" : Program "asnmcmd 9.1.0" is starting. ASN0506E "AsnMcmd" : "ASN" : "Initial" : The command was not processed. The "Monitor" program is presumed down. Note that there is a slight delay of a few seconds between the ASN0600I message and the ASN0506E message. We can check when a monitor last ran using the following query: $ db2 "SELECT SUBSTR(monitor_qual,1,10) AS monqual, last_monitor_time, start_monitor_time, end_monitor_time, lastrun, lastsuccess, status FROM asn.ibmsnap_monservers" MONQUAL LAST_MONITOR_TIME START_MONITOR_TIME MONAC1 2007-03-16-10.18.57.750000 2007-03-16-10.18.57.750000 END_MONITOR_TIME 2007-03-16-10.18.59.765000 LASTRUN LASTSUCCESS STATUS 2007-03-16-10.18.57.750000 2007-03-16-10.18.57.750000 0 Changing or reinitializing a monitor If we change any of the following while the monitor is running such as contact information, alert conditions, or parameter values: $ asnmcmd MONITOR_SERVER=mondb MONITOR_QUAL=monac1 CHGPARMS MONITOR_INTERVAL=10 Then we do not have to stop and start the monitor, we can just reinitialize it as follows: $ asnmcmd MONITOR_SERVER=mondb MONITOR_QUAL=monac1 REINIT Stopping a monitor To stop a monitor called monac1, we would issue the following command: $ asnmcmd MONITOR_SERVER=mondb MONITOR_QUAL=monac1 STOP Suspending or resuming a monitor We cannot suspend a monitor from the Replication Center, we can only use ASNCLP scripts. We can stop checking Q Capture and Q Apply for all defined alert conditions using the ASNMCMD SUSPEND command. When we want to resume monitoring again, then we issue the ASNMCMD RESUME command. Note that using the ANSMCMD command is an all or nothing approach. The SUSPEND option will suspend all monitoring qualifiers. So what happens if we just want to suspend monitoring one monitored sever (DB2A or DB2B)? In this case, we would have to create a monitor suspension. We can suspend a monitor once only or on a repeatable basis. If we want to suspend a monitor on a repeatable basis, then it's best to first create a suspension template and then create a monitor suspension. If we want to suspend a monitor server once only, then we just need to create a monitor suspension. All dates and times for monitor suspensions are based on the clock at the system where the monitor is running (MONDB). The time format is HH:MM:SS and the date format is YYYY-MM-DD. The ASNCLP command to create a monitor suspension template is: CREATE MONITOR SUSPENSION TEMPLATE <template_name> START TIME <starting_time> REPEATS occ-clause Where occ_clause can be: DAILY FOR DURATION <n> [HOURS | MINUTES] Or: WEEKLY DAY OF WEEK <day> FOR DURATION <n> [HOURS/MINUTES/DAYS] Where <day> can be Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, or Saturday. The ASNCLP command to create a monitor suspension is: CREATE MONITOR SUSPENSION <name> [FOR SERVER <server_name> | ALIAS <server_alias>] STARTING DATE <date> [USING TEMPLATE <template_name> | STARTING TIME <starting_time>] ENDING DATE <date> ENDING TIME <ending_time> So when should we use templates? We should use them: If we want to suspend more than one monitor at the same date or time. If we want to suspend a monitor on anything but a daily basis. Note that, we can specify a day of week when we create a monitor suspension template, which is not possible in the monitor suspension definition. There are eight ASNCLP commands which deal with monitor suspensions: ASNCLP command:Description:LIST MONITOR SUSPENSIONGenerates a list of suspensions on a monitor control server.ALTER MONITOR SUSPENSIONAllows us to change the following properties of a monitor suspension: • The template that is used • The start or end date for using a template • The start or end date for suspending the monitor program one timeDROP MONITOR SUSPENSIONDeletes a monitor suspension from the monitor control tables.LIST MONITOR SUSPENSION TEMPLATEGenerates a list of monitor suspension templates on a monitor control server.ALTER MONITOR SUSPENSION TEMPLATEAllows us to change the frequency and length of monitor suspensions as defined in a suspension template.DROP MONITOR SUSPENSION TEMPLATEDeletes a monitor suspension template from the monitor control tables.CREATE MONITOR SUSPENSION TEMPLATECreates a monitor suspension template.CREATE MONITOR SUSPENSIONCreates a monitor suspension. Even though we want to monitor Q replication, we need to specify SQL replication in the ASNCLP SESSION line. So let's look at the ASNCLP command to create a monitor suspension template called LUNCH which starts daily at 12:00 and lasts for one hour: ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; CREATE MONITOR SUSPENSION TEMPLATE lunch START TIME 12:00:00 REPEATS DAILY FOR DURATION 1 HOURS; In the preceding command, we have not specified a server on which to apply the suspension—we have only defined the monitor server where to store the metadata. We have also not specified a start and end date—only a start and end time. Once we have created a monitor suspension template, we can define a monitor suspension for a specific server (that is, source or target) and a specific date range, which uses the template we defined previously. ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; SET SERVER TARGET TO DB db2b; CREATE MONITOR SUSPENSION NAME s1 FOR SERVER db2b STARTING DATE 2007-03-20 USING TEMPLATE lunch ENDING DATE 2007-12-31; In the above monitor suspension code, we do not have to specify a time value, because the time value is specified in the template definition. Note that now we have to specify a server for the template to work against. We can also define a monitor suspension without making reference to a template by specifying all the information that we need (this would be the once only processing model): CREATE MONITOR SUSPENSION NAME s2 FOR SERVER db2a STARTING DATE 2007-03-20 STARTING TIME 12:00:00 ENDING DATE 2007-12-31 ENDING TIME 13:00:00 In the above monitor suspension definition we have not specified a template, so we have included the start and end dates and times. We can list our monitor suspension templates and monitor suspensions using the following ASNCLP command: ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; LIST MONITOR SUSPENSION TEMPLATE; LIST MONITOR SUSPENSION; This produces the following output: ==== CMD: LIST MONITOR SUSPENSION TEMPLATE; ==== TEMPLATE NAME START TIME FREQUENCY DURATION UNITS ------------------ ---------- --------- -------- ------- LUNCH 12:00:00 SUNDAY 1.0 HOURS 1 Template(s) found. ==== CMD: LIST MONITOR SUSPENSION; ==== SUSPENSION NAME SERVER NAME TEMPLATE NAME FREQUENCY DURATION ------------------ ------------------ ------------------ --------- S1 TARGET LUNCH SUNDAY 1.0 SUSPENDUNITS FIRST SUSPENSION STOP -------- ------- ------------------- ------------------- HOURS 2007-03-20-12:00:00 2007-12-31-00:00:00 1 Suspension(s) found. We can see the monitor suspension template called LUNCH, which we created and the monitor suspension S1. We can alter a monitor suspension template by using the ASNCLP command ALTER MONITOR SUSPENSION. Suppose we want to change the suspension day from Sunday to Monday, then the ASNCLP command would be: ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; ALTER MONITOR SUSPENSION TEMPLATE lunch; LIST MONITOR SUSPENSION TEMPLATE; To drop a monitor suspension, we would use the DROP MONITOR SUSPENSION ASNCLP command: ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; SET SERVER TARGET TO DB db2b; DROP MONITOR SUSPENSION s1; Dropping a monitor suspension involves running the following SQL: DELETE FROM ASN.IBMSNAP_SUSPENDS WHERE SUSPENSION_NAME = 'S1' To drop a monitor suspension template, we would use the DROP MONITOR SUSPENSION TEMPLATE ASNCLP command: ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; DROP MONITOR SUSPENSION TEMPLATE lunch; Dropping a monitor suspension template involves running the following SQL: DELETE FROM ASN.IBMSNAP_TEMPLATES WHERE TEMPLATE_NAME = 'LUNCH' So let's look at an example in a bidirectional scenario as shown in the following diagram: In this example, we have created four monitors to monitor Q Capture and Q Apply on each of the two servers. The monitor_qual are MONAC1, MONAA1, MONBA1, and MONBC1. The monitor_server is MONDB. If we want to perform maintenance on the DB2B database every Sunday afternoon at 16:00 for one hour, we would create a monitor suspension template as follows: ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; CREATE MONITOR SUSPENSION TEMPLATE tmaintbaft START TIME 16:00:00 REPEATS WEEKLY DAY OF WEEK SUNDAY FOR DURATION 1 HOURS; And then, we would create a monitor suspension as follows: ASNCLP SESSION SET TO SQL REPLICATION; SET RUN SCRIPT NOW STOP ON SQL ERROR ON; SET SERVER MONITOR TO DB mondb; SET SERVER TARGET TO DB db2b; CREATE MONITOR SUSPENSION NAME maintbaft FOR SERVER DB2B STARTING DATE 2007-03-20 USING TEMPLATE tmaintbaft ENDING DATE 2007-12-31; The ibmsnap_alerts table The IBMSNAP_ALERTS table contains a record of all the alerts issued by the Replication Alert Monitor. The table records what alert condition occurred, at which server, and when they were detected. Some common errors in the ALERT_CODE column are: ASN5153W MONITOR "<monitor_qualifier>". The latency exceeds the threshold value for program "<program_name>". The server is "<server_name>". The schema is "<schema>". The latency is "<latency>" seconds. The threshold is "<threshold>" seconds. ASN5157W MONITOR "<monitor_qualifier>". The Q subscription "<subscription_name>" is inactive. The server is "<server_name>". The schema is "<schema>". State information: "<stateinfo>". Summary In this article we described the Replication Alert Monitor and how to monitor the Q replication setup. Further resources on this subject: Lotus Notes Domino 8: Upgrader's Guide [Book] Q Replication Components in IBM Replication Server [Article] IBM WebSphere MQ commands [Article] WebSphere MQ Sample Programs [Article] Q Subscription Maintenance in IBM Infosphere [Article]

Important preliminary points If you are creating an extension that can be used by all, make sure that it is stored in a central place, like a version control system. This will prevent any potential issues in the future when others in your team start to use it. User extensions Imagine that you wanted to use a snippet of code that is used in a number of different tests. You could use: type | locator | javascript{ .... } However, if you had a bug in the JavaScript you would need to go through all the tests that reused this snippet of code. This, as we know from software development, is not good practice and is normally corrected with a refactoring of the code. In Selenium, we can create our own function that can then be used throughout the tests. User extensions are stored in a separate file that we will tell Selenium IDE or Selenium RC to use. Inside there the new function will be written in JavaScript. Because Selenium's core is developed in JavaScript, creating an extension follows the standard rules for prototypal languages. To create an extension, we create a function in the following design pattern. Selenium.prototype.doFunctionName = function(){ . . . } The "do" in front of the function name tells Selenium that this function can be called as a command for a step instead of an internal or private function. Now that we understand this, let's see this in action. Time for action – installing a user extension Now that you have a need for a user extension, let's have a look at installing an extension into Selenium IDE. This will make sure that we can use these functions in future Time for action sections throughout this article. Open your favorite text editor. Create an empty method with the following text: Selenium.prototype.doNothing = function(){ . . . } Start Selenium IDE. Click on the Options menu and then click on Options. Place the path of the user-extension.js file in the textbox labeled Selenium IDE extensions. Click on OK. Restart Selenium IDE. Start typing in the Command textbox and your new command will be available, as seen in the next screenshot: What just happened? We have just seen how to create our first basic extension command and how to get this going in Selenium IDE. You will notice that you had to restart Selenium IDE for the changes to take effect. Selenium has a process that finds all the command functions available to it when it starts up, and does a few things to it to make sure that Selenium can use them without any issues. Now that we understand how to create and install an extension command let's see what else we can do with it. In the next Time for action, we are going to have a look at creating a randomizer command that will store the result in a variable that we can use later in the test. Time for action – using Selenium variables in extensions Imagine that you are testing something that requires some form of random number entered into a textbox. You have a number of tests that require you to create a random number for the test so you can decide that you are going to create a user extension and then store the result in a variable. To do this we will need to pass in arguments to our function that we saw earlier. The value in the target box will be passed in as the first argument and the value textbox will be the second argument. We will use this in a number of different examples throughout this article. Let's now create this extension. Open your favorite text editor and open the user-extension.js file you created earlier. We are going to create a function called storeRandom. The function will look like the following: Selenium.prototype.doStoreRandom = function(variableName){ random = Math.floor(Math.random()*10000000); storedVars[variableName] = random; } Save the file. Restart Selenium IDE. Create a new step with storeRandom and the variable that will hold the value will be called random. Create a step to echo the value in the random variable. What just happened? In the previous example, we saw how we can create an extension function that allows us to use variables that can be used throughout the rest of the test. It uses the storedVars dictionary that we saw in the previous chapter. As everything that comes from the Selenium IDE is interpreted as a string, we just needed to put the variable as the key in storedVars. It is then translated and will look like storedVars['random'] so that we can use it later. As with normal Selenium commands, if you run the command a number of times, it will overwrite the value that is stored within that variable, as we can see in the previous screenshot. Now that we know how to create an extension command that computes something and then stores the results in a variable, let's have a look at using that information with a locator. Time for action – using locators in extensions Imagine that you need to calculate today's date and then type that into a textbox. To do that you can use the type | locator | javascript{...} format, but sometimes it's just neater to have a command that looks like typeTodaysDate | locator. We do this by creating an extension and then calling the relevant Selenium command in the same way that we are creating our functions. To tell it to type in a locator, use: this.doType(locator,text); The this in front of the command text is to make sure that it used the doType function inside of the Selenium object and not one that may be in scope from the user extensions. Let's see this in action: Use your favorite text editor to edit the user extensions that you were using in the previous examples. Create a new function called doTypeTodaysDate with the following snippet: Selenium.prototype.doTypeTodaysDate = function(locator){ var dates = new Date(); var day = dates.getDate(); if (day < 10){ day = '0' + day; } month = dates.getMonth() + 1; if (month < 10){ month = '0' + month; } var year = dates.getFullYear(); var prettyDay = day + '/' + month + '/' + year; this.doType(locator, prettyDay); } Save the file and restart Selenium IDE. Create a step in a test to type this in a textbox. Run your script. It should look similar to the next screenshot: What just happened? We have just seen that we can create extension commands that use locators. This means that we can create commands to simplify tests as in the previous example where we created our own Type command to always type today's date in the dd/mm/yyyy format. We also saw that we can call other commands from within our new command by calling its original function in Selenium. The original function has do in front of it. Now that we have seen how we can use basic locators and variables, let's have a look at how we can access the page using browserbot from within an extension method.

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.

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:

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  

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.

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.

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.

  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...

  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

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.