I introduce object and the object literal I then define arrays and discuss their relationship to an object. The slides for this are available at http://www.slideshare.net/charles_russell/js-objects-34362836
No title available
Game of Thrones Daily

#extradirty
Three Goblin Art
Sweet Seals For You, Always

izzy's playlists!

Kaledo Art

Andulka
"I'm Dorothy Gale from Kansas"

shark vs the universe

titsay
noise dept.
we're not kids anymore.
Show & Tell
Alisa U Zemlji Chuda
h
Monterey Bay Aquarium
d e v o n
No title available
$LAYYYTER
seen from Singapore
seen from United States
seen from Malaysia

seen from Pakistan

seen from Germany

seen from France
seen from United Kingdom

seen from Indonesia
seen from United States
seen from Netherlands
seen from Indonesia
seen from Malaysia
seen from Spain

seen from Slovenia

seen from United States

seen from Germany
seen from China

seen from United States
seen from United States

seen from United States
@caught-in-the-web
I introduce object and the object literal I then define arrays and discuss their relationship to an object. The slides for this are available at http://www.slideshare.net/charles_russell/js-objects-34362836
The Drupal Default Adminstrative Tool Bar (A short break from JS)
I recently set up a Drupal site for somebody new to Drupal to begin to learn and experiment with. I want to give him a place to begin to grasp the limitless possibilities that Drupal represents. Those of us who have ridden the Drupal roller coaster know there is a lot to learn for a first time Drupal user. There are also many approaches to beginning to learn Drupal. The Drupal.org documentation starts with understanding Concepts the Technology stack terms etc. But most people I find want to get right in there start doing something. Given this instinct to jump in I thought a good place to begin to learn Drupal would be the thing most obvious to an administrative user who has just gone to his new site, the Drupal ToolBar.
I begin the discussion of functions in JavaScript. I discuss how to invoke them. I also show how to create them. I introduce scope and the this keyword. The slides for this video can be found here http://www.slideshare.net/charles_russell/js-functionintro
This is a live code demo showing use of JavaScript Operators, Conditional statements and loops. In other words this the application of the subjects we have been discussing in the past several slides.
In this video I discuss various looping techniques available in JavaScript. The slides for this video are at http://www.slideshare.net/charles_russell/js-iteration
In this video I talk about comments, why they are important and how to add them to your code. I then tackle the conditional statement family if, else, else if, and switch
In this video I continue the discussion of operators starting with the logicals, I then discuss the conditional opeator and finally grouping. After the discusion of the opoerators I discuss precedence.
In this first video on operators I define operators, discuss coercion. I also define unary, binary and ternary. In addition I go over the mathematical operators, comparison operators and assignment operators
Getting Modular Drupal .info files the final chapter
In the review mirror
So I discussed in my first in this series the .info file in general and emphasized the keys that both the module .info file and the theme .info file have in common. I then discussed the theme .info file and went into detail on the keys specific to it. In this, the last of the trilogy I am going to concentrate on the keys specific to creating modules.
Finding my place the Package key
One very useful key available to is much appreciated by those using your module, that is the package key. This key is suggested when your module is comes with a lot of other modules or when a module is extends some other module and is intended to be used only by that module. That is according to the Drupal Documentation. I have one other case that I think is appropriate if you have a Website with a lot of custom modules I like to group those custom modules with the name of the company the site is for. In a sense it is sort of the case that these custom modules are part of a larger group and putting them in their own package makes finding them a lot easier for the owner/maintainer of the site.
Outside of these cases you should not use this key. Modules that don't use this key get categorized under other. The key looks like this when used
package = “Package Name”
An example would be that you have written a module that is meant to add functionality to the Organic Groups module it would logical to add your module to the organic groups package.
Coulda, Shoulda, Woulda, and I knew better. The stylesheets and scripts key again
In my first article in this series I was trying to put into it keys that are common to both modules and themes. At the time I wrote that and the next I was thinking back-end, front-end and I forgot something I knew but did not think about until I got here the stylesheets key and the scripts key can go here as well. If your module uses Ajax for instance you are going to have some JavaScript that needs to be inserted as well as the PHP response. It is also possible that you will need to have some sort of administration page that you want laid out in a particular way so you need some CSS but I did not mention in my first article on this. I did however cover these two keys in my previous article on the theme.info file.
Taking attendance and organizing my helpers. The dependencies key
It is not uncommon that you will want to leverage work done in other modules. If these modules are not loaded then your code won't work. In fact there are some modules like Entities that are designed to be used in this way. Drupal will check to make sure what you need is available but you need to provide the roster. This is where the dependencies key is used is syntax is like this:
dependencies[] = module (major.minor)
Notice the square brackets. Just like with the stylesheets and script keys it implies that there may be more than one, and that assumption would be right . You would add a line for each module you module depended on. The minor.major refers to the version of the module that you need. If you leave off the version information it would be assumed that any version of the supporting module would work. Be sure to get the version in parenthesis as shown.
One other note on the version, you can use comparison operators like >, <, >=, <=, and != . As an example lets say that your module needs views but can not work with views 2 then you could use a statement like this dependencies[] = views (>= 3.0) cool isn't it.
Getting Dynamic, the files key
Good news Drupal is becoming better at the use of objects and one of the things the are doing is dynamic loading of classes and interfaces. What this means is that a class will autoload when it is first accessed at run time. Why do this? Because do you want all of the classes and implmentation just taking up resources when they are not being used. Drupal keeps a list of all of the classes for each module and loads them automatically as used but in order to do this you need to tell Drupal what your class files are the key to do that is files. It look like this
files[] = class.php
Create an entry in your .info for every class or interface you have in your module. I may do an article in the future on autoload but for now just accept the magic.
Allowing user to tailor your module for their application with the configure key
You may have a module that allows the user to customize your module for their application. You may have provided a page for the users to do that. If you look at the modules page you may have noticed two links to the left of the title of some of the modules Configure and Permissions. The configure key tells you module to create that link and then where it is. It presence tells Drupal that you have a configuration page and the value is the path that link should go to. It looks like this
configure = path/to/my/config/page
There are a few other keys like hidden and require but these are less commonly used or should only be used by modules in core. So with that I think I will leave the subject of .info files and find some other interesting Drupal stuff to write about.
In this video I do some practical illustration of the principles discussed in the previous videos.
This is a continuation of the discussion on Data Types began in the previous video. In this I continue with a discussion of the Number data type and a brief introduction to the Math object. I then go on to discuss the String Data type
This is the first of two videos on the subject of JavaScript Data Types. In this video I list the JavaScript Data types and discuss the typeof operator. I go on to discuss the Null, Undefined, Object, and Boolean Data Types in detail
25 posts!
In this video we discuss variables in the JavaScript language, what they are, how they are used, and how to name them.
This video is a discussion of the tools needed or would be useful in writing or maintaining JavaScript. We talk about text editors, IDE, etc. In this video we also show how to add JavaScript to your web page.
In this introduction I try to clear some confusion about the language, look at the who controls the standard and other ways JavaScript is being used.
Looking Pretty, Drupal's Theme .info file
Looking Backward
Lets start where we left of last time and define the common key value pairs
;Set the basic parts defined in the introduction to the .info file. name = My Cool Theme description = Stylin' with My Cool Theme, a demo theme by Charles Russell. core = 7.x php = 5.3
This describes your theme to Drupal and would alone cause you file to be shown in the list of disabled themes. If you enabled the theme you would get the default regions and styles provided by Drupal There is a theme called Stark that will show you this plain vanilla theme.
Getting A Head Start, base themes.
One of the easiest ways to create a new theme is with subthemes. Subthemes will cause Drupal to look for any resources you have not defined in your theme in another theme and render them as defined in that theme. Your themes resources will override the base theme. In other words Drupal will look at your file first resolving any conflicts between the basetheme in favor of your theme. There are many themes available that are intended to be used this way. Some of the more popular base themes are Zen, Omega, Adaptive, and Mothership. More of these base themes are appearing everyday. The line to use a base theme is like this
base theme = zen
You will of course need to have downloaded the base theme into you sites/all/themes directory for this to work.
Getting The Picture, showing a logo or screen shot of your theme
When looking at the them listing on the appearance page you see an image next to the theme listing. This image is from a key called screenshot. It is normally just that, a screenshot of your theme, but often in the case of base themes it is a logo. If this key is omitted Drupal will look for a file called screenshot.png. If your file is named anything other than screenshot.png and is anyplace other than your themes root directory you will need to set this key if you want a picture. This is the first place we are referencing a file so we need to talk a bit about paths. Paths in the .info file are relative to the root of the theme that contains the .info file. If, for example, you are declaring all of your CSS files in a directory of your theme called images and the file is named cool.png the path is images/cool.png. So lets see what this key value pair look like
screenshot = images/cool.png
V8 or V6, template engines
In previous versions of Drupal you had to declare which template engine you were going to use. By Drupal 7 a consensus grew around PHP Template and that became the default so you only had to declare the engine if it was not PHP Template. Now I think we may be changing again. In Drupal 8 they are going to make Twig the default engine but PHP Template will still be supported and support for other template engines like Smarty is being restored. The key of this is engine and looks like this.
engine = phptemplate
Framing The House, regions
Regions are the blocks into which you put your content. In fact what you see when you go to structure blocks is a listing of those regions. Notice that the key name I am referring to is plural. That is because there is more than one region. So how do we identify a unique region? The answer is that we need to names one for Drupal called the machine name and another for us humans. This is what this key value pair looks like:
regions[machine_name] = Human Name
I for clarity used machine_name and Human Name in real life you want to make the names similar to save confusion later. You may remember that all you needed was the information form the previous article to get your theme to list. This implies that there are default regions and you would be right. There are nine of them and here they are
regions[page_top] = Page Top regions[header] = Header regions[highlighted] = Highlighted regions[help] = Help regions[content] = Content regions[sidebar_first] = Sidebar First regions[sidebar_second] = Sidebar Second regions[footer] = Footer regions[page_bottom] = Page Bottom
You should also take note of the underscores in the machine name. Uppercase letters and spaces are not permitted in the machine name. Also you will need to add the markup to your page.tpl.php file to define these areas. Another important note once you have defined a region you have overridden the defaults. So you will have to explicitly declare all regions.
Stylin', adding CSS to your pages
Regions provide a place to put our content but has no effect how the page will look. To modify this you need to include stylesheets with your CSS rules. The key to define your style is stylesheets. Again notice that this is plural. It is often the case that there is more than one stylesheet. This is especially true if you are using some sort of CSS framework like Blueprint CSS or 960gs. Set lets add a general stylesheet.
stylesheets[all][] = global.css
Again, file paths are relative to the theme root. You should notice there are two square brackets, the second is always empty. The first in the case illustrated contains the word all, that does not refer to all pages, it is reference to media type in this case all types. Other valid media types are print and screen. Styles are going to be added in the order declared. Later stylesheets will override earlier ones when a conflict occurs.
Getting Dynamic with JavaScript
So we have now defined structure and style but what about the third leg of front end development, behavior. In client side web development this is normally done with JavaScript. Drupal is already going to include jQuery and jQuery UI but you may want to add other libraries or plugins or your own script. The key to add JavaScript is scripts. Scripts are added in the order declared. This key is used like this:
scripts[] = global.js
Styles and scripts declared in the .info file apply to all of the pages on your site. If you want to style an individual page and not on others you will have to use other techniques that are beyond the scope of this article.
Honorable mentions
There are two other keys that I am going to mention but omit the details of as this is already pretty and long that is features and settings. Features defines what choices are available to the user and settings are used to set the default of those features. Look at the documentation at https://drupal.org/node/171205 for more on these two .
Summary
As you can see the .info file in your theme will give you a lot more control off how the page displays. It provides the global information that your theme needs to give the look and feel that you want. It is not the only skill a good themer needs but it is an essential one.
I keep telling myself to get a little more frequent with these posts, however life keeps getting in the way. I will try to get better and my apologies to those who are following me.