oheric.com

Wish I had seen this in August after OSCON, but it really strikes a chord. I’ve been a Drupal dev for a long time, and have recently been focusing on the newer “agile frameworks” in Python and Ruby, and I’ve found the same shortcoming: there is no component architecture, at least not on the level of Drupal with its myriad callback hooks and “monkey patching” facilities. I’ve been ruminating on the idea of following the Drupal architecture to build a similar framework on top of WSGI.

I ♥ Panels (it does the simple layout on this blog, but it’s capable of much more advanced usage).

• API Documentation for Drupal core

• Contrib module project pages. Issue tracking, CVS browser, releases, documentation.
• Drupal Lists
• #drupal-support on freenode
  

In the interest of greater openness (sharing my inner life with the world and such), here is a bit of python I just wrote to find perfect numbers. After a few minutes of optimization, it is now quite fast and no longer brings OSX to its knees with memory-hungryness:

from math import *
def is_perfect(a):
	sum = 1 
	for i in xrange(2, floor(sqrt(a))):
		if a%i == 0:
			sum = sum + i + a/i
	if sqrt(a)%1 == 0: sum += sqrt(a)
	return sum == a

def find_perfect(limit):
	results = []
	for i in xrange(1, limit):
		j=2**i*(2**(i+1)-1)
		if is_perfect(j):
			results.append(j)

cck, groups, categories hybrid

Categories represent areas of influence. They don’t correspond directly to location, rather locations are constructed by intersecting vocabularies and providing a means of display for the resulting nodes.

Groups can be associated with categories, as a single node. This node is also a cck node.
Some categories are also groups.

• Workflow / Actions
• na_arbitrator

This last is a work by Earl providing an API for node access modules to interoperate.

Currently, access modules directly insert records into the node_access table. If any module has inserted a “yes” record, access is granted.

na_arbitrator provides. Currently, there exists in the package a module workflow_access which ties node access to workflow state by role.

Relationships

• Node {has a} Workflow State
• Node {aggregates to} multiple categories
• Groups {have many}
  • Managers
  • Members

For each category/group, there are 3 local “roles”:

• Not a member
• Member
• Manager

A content item lives in the intersection of the union of each set of categories which share a container

For example:

?? (FAQs) AND (History OR Math) AND (“History: Early 20th” OR “Math: Trigonomery”) ??

Here, the first category is the content type. Each content type has fields, workflow, and behavior. Type determines workflow. This makes workflow and behavior global in the sense that it is the same in all departments. This is true at least in our first prototype.

It would be possible to add more “roles” to a group type using CCK user ref fields. Behaviors could then be associated with these local roles using a na_arbitrator node access module.

Here are some incomplete and probably incorrect notes about PHP caching options.

Page-level caching works well for page views that don’t change very often. For example, a front page which rotates the featured articles every hour could be page-cached, then invalidated each hour.

Region-level caching can be used to pull some parts of an otherwise dynamic page from a cache.

Object-level caching can store structured PHP data objects, so that they don’t have to be built with each run.

These levels of cache are ordered by increasing “ickiness”.

PHP-Level

My immediate use-case is taxonomy browsing, but it would be very useful for all kinds of views.

It is very useful for a CMS to allow site creators to define new content types. This functionality is nicely implemented in Drupal with CCK, also known as content.module. CCK actually allows new types to be defined TTW (Through The Web).

For the 4.7 series, CCK has been developed parallel to core as a set of contrib modules. As the CCK feature set stabilizes, changes are made in core to ease the merge.

More after the fold.

RDF Metadata in Drupal

Doesn't DO much, but allows the specification of relationships between nodes. The problem is that Dublin Core (the metadata specification which RDF uses) overlaps with many existing data structures in Drupal core. Examples:

/base/(head)|(stable)

• Core system + select essential contribs

• Drupal sites dir for each site.
  • settings.php
  • database.mysql (prod snap)
  • themes
  • modules
• ACLs prevent snooping.

Ok, we're discussing repos structure here. The question is, given Drupal's builtin per-site config dirs, are per-site SVN branches useful? It is possible, for instance, to put site-specific mods in the sites dir. Whether dev versions of mods which already exist in the global mods dir will consistently override the global copy, I don't know. Let's check… [opens editor] ^v^v^ Yes! (includes/bootstrap.inc function drupal_get_filename). So there would seem to be no reason to mainain seperate branches for each site. Awesome! The other thing is access control on the sites dirs. So we have two (or three) branches: prod, test, dev. In each branch we have implemented some acls so that you only get the site dir if you pass muster. That sounds hard. So maybe we store the sites in another repos path. Then you need to explicitly check out the site. And each site is ACLed. Frito pie!

So alot has been happening behind the scenes since my last blog update. I have a beefy new Ubuntu virtual server, which I have been industriously whittling into a kick ass Drupal hosting and development environment. The component which ties the whole system together is the Subversion repository. Whenever a new site branch is created in subversion, a hook is fired which automagically configures Apache and mysql. Sweet! Anyway, I'm working hard on launching some new services, in particular a business homepage with project management, documentation, etc. Cheers