One aspect of “open culture” is that people are informal. People address each other by first name. They tend to speak directly to one another, regardless of social status or formal title. Disagreements about code, whether as profound as which algorithm is most appropriate, or as seemingly mundane as how many spaces are used for indentation, are aired in public. This process is very intimidating to newcomers, who might be concerned about having their words immortalized on the Internet, and worse, saying something wrong or embarrassing. The only way to get over this fear is to practice and participate publicly.
Although “open culture” is generally informal, it is important to remember that you still need to mind your manners when participating in conversations.
Open source communication can vary a lot. A core value held in common is that sharing code is good. Regardless of license, language or indentation style, open source developers create, share and modify source code together.
Working on code together means a lot of things: transparency, directness and cooperation are words that are often mentioned by developers when describing the process. It can involve bug reports, code refactoring, implementing new features, documentation, project management and advocacy.
Amazingly, the ways in which people actually share code are as varied as the individuals involved. Even if you have previous experience with other open source projects, keep in mind that you still need to take the time to learn how the new open source project works, and acquaint yourself with their particular brand of sharing.
(reference : http://en.flossmanuals.net/GSoCStudentGuide/ch013_open-source-culture/ )
My proposal was accepted for GSoC 2012. I had faith , and I will prove that I really deserve it. Thanks all of you , for help me to achieve this ultimate glory.
The final component from our initial architectural diagram is the theme system.
Drupal separates the look-and-feel components of the system from the rest of
Drupal, and provides a programmatic way for theming data. The system for
handling this is collectively called the theme system.
Some of the theme system resides in the Drupal core libraries. This part is
responsible for initializing themes and locating what theme functions and
templates should be applied under certain circumstances.
However, the majority of the theme code resides in themes and modules.
A theme is a structured bundle of code (like a module) that provides tools
for transforming raw data into formatted output. Sites use at least one theme
to apply a consistent and custom look-and-feel to all of the pages on the site.
However, Not all theme code resides inside of a theme. One of the distinct
advantages offered by Drupal is the capability to define default theming inside
modules, and then provide mechanisms by which the theme layer can selectively
override those themes. In other words, a module might declare a rough layout for a
component, but Drupal provides the structure for a theme developer to later modify
the theme (not the module) to re-layout that component in a different way.
We have taken a brisk walk through a typical Drupal request, and we have learned a
little about modules and libraries. However, what about the database?
Unlike many architectures, for Drupal the database doesn’t stand front and center.
The database layer is not a module, nor do modules need to declare a specific
relationship with the database. In fact, many Drupal modules do not ever interact
directly with the database.
Instead of treating the database as a central architectural component, Drupal merely
provides an API for working with the database. In Drupal, the database is just a
place to store data. Need custom tables? Drupal provides a system for declaring
them. Need to get data out of the database, or insert or update new data? Drupal
provides functions and an OO library for doing so. However, if you don’t need such
features for your code, you needn’t work with the database at all. In fact, in the next
chapter we will write our first module without writing a single SQL query.
While Drupal may not be database centric, it most certainly requires a database.
During initialization, Drupal will connect to a database and retrieve certain
configuration data. Later, as many of the core modules load, they too, contact the
database to retrieve or update information. For most Drupal modules, the database
is the location for data storage.
As noted earlier, Drupal provides several core modules. These modules cannot be
disabled, as their capabilities are integral to the standard functioning of Drupal. Just
like other modules (including the ones we will be writing), core modules function by
implementing Drupal hooks.
As Drupal invokes these hooks, each core module will respond as necessary,
performing crucial functions at specific times during the course of a request.
we will discuss several core modules in more detail, explaining what purposes these modules serve.
The Drupal core doesn’t attempt to do the processing for each of these steps. Instead,
after each step, it offers one or more modules the opportunity to handle that step. Put in
Drupal parlance, it offers opportunities for modules to hook into the lifecycle.
For example, we noted that Drupal checks to see if any module needs to be
initialized. What it actually does, is look to see if any modules implement a hook for
initialization. How does it do this? It scans the loaded modules to see if any of them
implement the function
hook_init(). To implement a hook in Drupal is to declare a
function that follows the hook naming pattern. For a fictional module named
hello to implement hook_init(), it would merely need to declare a function named
hello_init() (replacing the word hook with the name of the module).
Through this hook_init() hook, Drupal provides modules the ability to initialize
themselves or their own resources right at the beginning of the request. Once
all of these modules have been initialized, Drupal moves on to the next step. As
it progresses through the request, it calls hook after hook, giving modules the
opportunity to do their thing. Finally, it makes one last call for modules that
hook_exit(), and then it returns any remaining data to the client
and terminates the request.
Drupal’s hook system is perhaps the single most important aspect of Drupal
programming. Most (if not all) modules are nothing more than a collection of hook
implementations that Drupal automatically calls as it works its way through the
request lifecycle. It’s not just the Drupal core that declares and calls hooks. Any module
can declare and call its own hook. Many modules do in fact declare their own hooks,
offering other modules the opportunity to integrate deeply with their services.
The core libraries provide the functions and services used throughout Drupal.
Facilities for interacting with the database, translating between languages, sanitizing
user data, building forms, and encoding data are all found in Drupal’s core libraries.
These tools are what we might call utilities: They facilitate effective data processing,
but are not responsible for handling the lifecycle of a request. The lifecycle is handled
Once Drupal has loaded core libraries and initialized the database, it loads the
enabled modules and themes, and then it begins a systematic, step-by-step process
of handling the request. This process is what I call the lifecycle of a request. It works
Drupal steps through a number of pre-determined operations. It checks to see if any
modules need to be initialized. It looks up what code is responsible for handling the
given URL. It checks whether the current user has access to the requested resource. It
checks to see if some data can be retrieved from cache. It continues stepping through
such operations until the request is complete.
However, the most important thing about this step-by-step process is the way
Drupal does it.