drupal

Grokking Drupal

Submitted by infojunkie on Sat, 2007-05-05 14:55.
in

I credit the Riff Blog for this great title.

Drupal distinguishes itself by its structure for organizing and structuring information. The combined concepts of content type and multi-dimensional taxonomies provide a great framework for modelling information in many diverse application domains. To this end it would be nice to extract the UML model of its core system (The Riff Blog entry currently only has an image of it) and use it as a base for application-specific models, that can then be transformed into code of any language via model-driven development (MDA, MDD, MDXX).

Drupal as Wiki container

Submitted by infojunkie on Sat, 2007-05-05 14:54.
in

To migrate from a Wiki to Drupal, we need to preserve two things: the content represented as HTML pages containing Wiki syntax, and the structure built by Wiki terms referring to content that contains other Wiki terms. We'll discuss the structure first.

In Drupal, the Wiki structure can be represented by a vocabulary with the following properties: flat (hierarchy disabled), multiple select and required. Each Wiki term will be translated to a Drupal vocabulary term. Each node will correspond to one Wiki page. A node will be tagged primarily with the Wiki term that refers to it. In addition, it will also be tagged with Wiki terms referring to nodes that link themselves to the original Wiki term. And so on recursively (until a cycle occurs).

Drupal as portlet container

Submitted by infojunkie on Sat, 2007-05-05 14:54.
in

The title is pretty self-explanatory. The idea is that PHP is great for layouting and templating while Java is really needed for business and data tiers. Implement JSR-168 and WSRP. Augment the Portlet context to include a Drupal context. This would need some sort of PHP-Java bridge.

Drupal as project management information system

Submitted by infojunkie on Sat, 2007-05-05 14:52.
in

Many types of information are used to deliver a software project. These types include: 

  * Requirements
  * Risks
  * Tests
  * Release notes
  * Instructions (manual, how-to, FAQ)
Traditionally these informations have been stored in text documents as bullet points. The problem with this approach is that each point is highly dynamic, quickly leading to outdated documents as the project evolves. The approach suggested here is to use Drupal's ability to define new content types and taxonomies, to efficiently stored those informations in a way that allows easy retrieval and update.

Drupal-based filesystems

Submitted by infojunkie on Sat, 2007-05-05 14:51.
in

The idea is to replace the single hierarchy of current filesystems with hierarchies and tags in more dimensions. For example, does the proposal document belong to the "software process" hierarchy under the "proposals" branch or under the "clients" hierarchy under the customer's name? It can be both.

A Drupal module would expose the new content type "filenode". This can represent a single file or a folder which is a collection of other filenodes. Drupal taxonomies can then be used on physical files and folders. The module is mounted on a physical filesystem path and can be navigated from there.

More accurate node view statistics

Submitted by infojunkie on Wed, 2007-02-21 00:19.
in

I noticed that the Drupal content view statistics increments the view count even when the author of the node is the one viewing the page. That's not very useful is it? I decided to change that:

In statistics.module, function statistics_exit(), add an extra if statement before updating the totalcount on {node_counter}:


if ((arg(0) == 'node') && is_numeric(arg(1)) && arg(2) == '') {
// Discard count if current user is the same as node author.
$author_uid = db_result(db_query('SELECT uid FROM {node} WHERE nid = %d', arg(1)));

Idea: Drupalizing applications

Submitted by infojunkie on Wed, 2006-11-15 14:32.
in

The problem is this: on one hand you've got a PHP application that does one thing only, but does it great, and on the other hand you've got Drupal, the Lego of computing which lets you do anything, but from scratch. And the applications that you are required to build are never fulfilled by just one existing PHP system, so using Drupal is tempting as a universal container.

For example: phpBB is a mature, full-featured bulletin-board system that's been around since 2000 and has a huge community. In constrast, the Drupal forum module is rather immature, clunky, and buggy. But it's integrated with all other nifty features of Drupal. What to do?

Idea: Node actions

Submitted by infojunkie on Thu, 2006-10-19 13:56.
in

The current actions module does not seem to show a per-node actions list. Instead, these actions are API-callable or event-based, which is useful for some applications but not others. Specifically, the knowledge worker wants to manipulate nodes by performing standard actions on them, invoked manually from the UI.

Design:
Add an "actions" tab for the node, in addition to the existing "view" and "edit" tabs. Or, add a new section in the "edit" tab, like "Menu settings", "Authoring information", etc.

Group actions:
Select a number of nodes (using the nodelist module for example), and then act on those nodes collectively using an action (using the action module).

Idea: Node containers

Submitted by infojunkie on Thu, 2006-10-19 13:54.
in

The idea is to recreate classical data structures (list, stack, tree, graph, etc.), but applied to Drupal nodes. This way we get structured information, and we can then apply standard computational actions (sorting, searching, etc.) to nodes directly. This is approaching a vision of programming information explicitly.

From a usability perspective, a new class of drupal objects would be created: node containers which have their own user interface. Of course, they are also nodes for recursive access.

Idea: Node query language (NQL)

Submitted by infojunkie on Thu, 2006-10-19 13:54.
in

The idea is to create a SQL-like query language to return node lists based on specified criteria.

« first‹ previous123next ›last »
Syndicate content