Drupal Architecture ~ An architectural vision

By default Drupal presents the components in a list format.

At the same time provides Blocks, Views and other objects to display the information on this site.

The decision of how to do this deployment and the ability to modify it relates to an architecture appropriate content presentation.

Since there are these products, since the time of Php Nuke and similar distinction is made between a reduced format of the component, called Drupal Teaser, and an extended format which displays all of its contents, known as Body, Body, Full House, Complete, etc.

Have input from at least three variants of the presentation:

- Titles

- Teasers

- Full

The idea is to customize these parts according to the information we want to show at any time.

Drupal by default to cut number of characters, whether there are modules that create a separate field for teasers.

But the form that gives us that flexibility is Content Templates.

This module allows us to customize the output of the components.

This module allows you to create templates and systems and most importantly, they are stored on databases, therefore we speak of components that can be shared among multiple portals with the same types of user.

The decision of when to use a template or not is an important factor in architecture.

In turn, own types of Drupal can be related, both with links and inclusions, you can create complex hierarchies that make more advanced components.

This composition is a determinant of the architecture of the portal.

Therefore, the appearance of the portal not only can be modeled with the same objects themselves but also with components created by us.

I believe this ability to create custom components is one of the most powerful aspects of Drupal.

The module components and further the field and matched between taxonomy module provided by another fantastic Taxonomy Content will go directly into the core of Drupal 7.

It is direct evidence that informs us of the importance of developing this form of writing or portals.

It is a universal standard in programming, trying to identify the functionality of the variables, functions, applications, etc.

This identification implies an appointment seeking maximum simplicity and characterization of components.

The aim is to fight for a maintainable system that involves the least effort to learn the functionalities implemented.

Therefore, in addition to betting on a document management, we must also consider the appointment of components suitable as another important point to keep the architecture appropriately.

For example, one should view with only the name of it to know:

- What kind of view is, focusing on the guy format it.

- What content to display

- If the view are receiving and how many parameters would

- If the view are going to belong to a data type or is a general view

All this information should give it to us the name of the hearing.

Why is it important to complete coding systems?

Because our goal is to reuse the same view and to be able to diagnose the functionality we are valid or not without having to reach the moment of release.

Without doubt, this and many other architectural parameters are beginning to see its meaning when the number of views and number of sites increases dramatically.

There is nothing new, these techniques are contrasted and methodologies of systems, good programming practices in systematic approaches such as CMMI and ITIL today, are common features of any architecture.

Architectural Keys: The parameters of usability and safety applied to the chosen components are architecture

We talk about usability as a set of techniques that simplify the management of a website and the approach to the needs of users or customers.

The ability to encapsulate a product like Drupal on a set of abstractions that simplify the model approach and the result is the customer's business architecture.

By default, a user should never guess what the product is Drupal behind your site.

It is therefore important to properly manage the portal and assign roles visibility on account of the needs of each role.

We believe you need the following four roles:

- Administrator: Knower of Drupal.

Is allowed to do any action on the portal.

- Supervisor: Knowing the Business.

Must be able to perform any actions that manage the business. You do not need any knowledge of Drupal.

Authenticated user: Permission to modify, add and remove some facets of the business

Anonymous user: Any visitor to the portal

These roles may be increased because of the needs of the site.

The role of each role is a determining factor in the security of the site.

The administrator should verify all new patches of security that can be implemented in order to try to make the security measures are adequate.

The architect of the system must properly define the actions to be taken because of the role of each action, making sure to respect privacy of the business criteria.

Due to usability in Brqx Group, we have two design methodologies applicable:

Light Potals - light Portals

The objective of this methodology is to minimize the options available to the needed adjusting.

At the same time apply methodology Liquid Potals

Its basis is to have the maximum amount of information without the need for screen scrolling.

The philosophy is that all actions are within sight of the user, provide agility to move like a liquid.

These methodologies are available to an appropriate architecture that you want to bet on the simplicity and ease of management of a site.

At the same time an architect should attempt to develop a system so that normal ortho in all portals, operating procedures are similar.

How to get a set of portals? Do you really think that a portal to another there are so many differences?

The reality is that no, their similarities rarely below 90% of the common components used.

Therefore, the need to prepare a component architecture that allows an easy re use.

This architecture requires a comprehensive documentation system, to assist in identifying and more adequately diagnose the satisfaction of requirements.

These relationships should be made for functionality common.

Drupal enables us to work, as already proposed its own set of relationships between modules, but we must continue that same work organizing many other components that we create.

To provide a basis initial proposed subdivision indicate Drupal.

Is already specified a list of the most common features of most websites:

- Authentication

- Presentation of content

- Communities

- Managing Users

- Mail - Lists - Forums

- Advertisement - PopUps

- Location

- Search

- Syndication

The Drupal community structure and even modules in a complete set of features that add to the most common.

Below:

- Utilities

- Content Management

- Administration

- Content Types

- Development

- Community

- Media

- E-Commerce

- Filters - Input format

- Views

- Categories

- Mobility

- Javascript Utilities

- Navigation

- Management - Files

- Backup - Import - Export

- Paging

- Security

- Prevent Spam

- Evaluation - votes

- Localization - Languages

- Organic Groups

- Statistics

- Events & Workflow

- Performance

- Games

- RDF - Formats

- Management Paths

It is a base to organize a component structure consistent with a simple re use.

The first few times you come to Drupal, you do not consider its structure as an important location to manage multiple portals.

Drupal developers themselves even begin to orient the possibilities and importance of good architecture files.

Seeing it is a grave error to put everything in "modules."

The opportunity to qualify in "sites / all / modules' different approaches and different groupings of modules.

This ability to discern the common needs of specific options for one or other portal is architecture.

It is important to the proper approach of the websites we want to deploy and is important to understand the approach recommended by Drupal free and, where instead of seeking a single war is bidding for a sharing of knowledge and responsibilities in development.

What we have called Agile Collaborative Methodologies, where your success depends on the success of other companies and resounding in the complete success of the product.

Following this philosophy, the management of websites should not be a version control, for it's own product has its own version control.

Changes or improvements should be consistent and agree with the very perpetrators of these modules or themes.

It is this idea that Drupal gives us, and it is best to ensure the software quality criteria.

Therefore we can see ideal management structure of portals that have to be no version management.

In this structure we have a part directly related to the product such as folders:

-"includes" - "Includes"

-"scripts" - Scripts

-"profiles" - "Profiles"

-"modules" - "Modules"

-"misc" - "Misc"

-"themes" - 'Themes'

It could be a series of symbolic links "pointing to the latest stable version of the product.

Therefore partially delegate files and more generally in product customization sites.

Within files can raise a joint structure with customizations for documents such as icons, logos and images:

/files/ / Files /

This route can be configured to achieve a more optimal coupling of common components.

In the other line, we have the following sites in and structure provided by Drupal

/sites/all/ --> For all sites

/sites/default/ --> Default Settings

As I already said this structure increases the complexity of the site and does not allow us to make a simple approach.

In such a structure would, for example three sites:

sites/site1

sites/site2

sites/site2

sites/all

sites/default

As you can see everything is within the same sites.

We prefer to see the product more easily, where the entire structure is always similar whatever the site and where environmental changes are completely transparent to the internal structure:

In our vision we will:

sites/default --> Just setup

sites/all --> custom common components

This structure will be common to all sites.