Drupal Module Development

Assignable Mission Details (Ignore for open missions)

Category: 

task

Priority: 

critical

Assigned: 

Agent0x45

We need a module that lets us create a field that can create ajaxable actions.

Supported actions

• High priority
  • cloning the current node, with modifications
  • changing certain properties of the current node
• Medium priority
  • Getting specific forms, with custom modifications
    • Hide fields
    • Set values to fields
  • Creating new nodes that are not based on the current node
    • For now, we can use some pre-defined templates when in doubt
    • Cloning other node, based on the properties of the current node
• Low priority
  
  • Table and list view compatability
    • Needs to be able to determine whether the node is fully loaded (When in a table or list view, only the needed properties are loaded.
    • Needs to be able to load nodes on demand
    • Needs to avoid using forms whenever possible. Nested forms aren't standards compliant, and some of our modules can make table and list views forms.
  • Loading indicator while fetching new stuff
  • AHAH-like forms... possably using the ahah module.
  • Submissions should not be done with a submit control... It should be an xmlhttprequest that manually includes the required data.

Configuration

• It should be exposed as a field type.
• The config is done on a per field-instance bases. When the field is added to a type, the wigit and general field settings are available after the user selects the wigit to use. It should have separate form elements to enter the various needed settings.
• One wigit should be created. It should never render anything because the actions should not be available when rendering the edit page. They should simply be missing.
• There should be one formatter at first. Additional formatters could be used to create 'profiles' so that a single action can be presented in several ways.
• The information that the user will need to provide when adding the action to a type:
  • A code snipit to render the element.
    • It will be enclosed in an anchor tag that is enclosed in a div.
    • The ajax setup, etc are handled elsewhere. This should just be
  • Any custom classes that should be added to the enclosing anchor tag
  • Any css classes that need to be added to the enclosing div tag
  • A code snipit to execute when the element is clicked
    • This code needs to be able to specify how to respond... client side redirects should be possible.
    • For now, php should be used.
      
      • While php is less safe and typos may render the content type un viewable until they are fixed
      • it is easy to impliment, and should allow just about anything to be done.
  • An object that will be saved on the client side and passed back when viewing the result of the action.
    • Additional information will also be sent... the recieving php callback needs to be able to locate the field, node, etc.

 

 

Assignable Mission Details (Ignore for open missions)

Category: 

task

Priority: 

critical

Assigned: 

Agent0x45

Now, make it themable.

Use nice menus in the default theme.

 

Its time for some serious configuration. An example config file will be added as a comment.

 

Some explanation:

Views are organized into groups. While the groups can be arranged arbitrarily, the intention is for them to be grouped based on the types of nodes they are displaying, and what types of arguments the views take. 

Each group is broken into profiles. Each profile should have enough information to render the view. Profiles can use the same views, or different views. 4 default profiles are defined, but any profile name should be accepted, provided that it isn't a reserved key. The group can define settings, but the settings for the profile superseed the settings for the group. That way there is no need to repeat settings that are used in most of the profiles.

 

Menus can also over-ride view settings, including the default profile. 

 

The order or precidence for settings is:

1. Arguments passed in the url

2. Values defined in the menu

3. Values defined in the view profile

4. Values defined in the view group

5. The defaults for that view (taken from view_get_view)

 

Note that cascading the properties isn't as simple as it sounds because switching some properties will affect how others are interpreted. For example, setting the viewid in the menu will over-ride the viewid in the profile or view group. Which profile is going to be used depends can be changed by the url or by the menu.

Assignable Mission Details (Ignore for open missions)

Category: 

task

Priority: 

critical

Assigned: 

Agent0x45

Create a drupal module that

1. Allows a logical grouping of related views
2. Can customize views
3. can load views dynamically or as full page loads
4. Can draw themable menus that ajax load the views.
5. Exposes the full range of flexability offered by the views api.
6. Use a cascading configuration.

 

More specific missions will be created for each step.

Assignable Mission Details (Ignore for open missions)

Category: 

task

Priority: 

critical

Assigned: 

Agent0x45

List: 

Current Goals

Drupal Dev List

This version has only a few requirements.

• A function that edits  a single field. 
  • Arguments:
    
    1. The node id, or a loaded node object.
    2. The name of the field to edit (the field_prefix is optionsl)
    3. The value(s) to store
    4. A boolean value (true by default) stating whether the node should be saved
  • Return Value:
    1. True if the value was successfully changed.
    2. Errors are reported with drupal_set_message()
  • Caveats
    1. If a loaded node is passed as the first argument, then it is modified in place.
    2. You don't have to save values each time you call this function. You can obtain your own node reference,and the function and use it several times. Just remember to save it when you are done.
    3. The format of the value argument can be a little trickey, depending on the type of the node. This function will attempt to make as much sense out of what you give it as it can.
       • The way that it is stored in the node object is a numerically indexed array of keyed arrays. The outer array contains one inner array for each item. If it isn't a multi-value field (as in you can select several nodes) then there is allways one inner array. The contents of the inner array is a set of key value pairs, keyed by the internal column names that the field uses. Most fileds have a single column, and many of them simply call it 'value'.
       • This function makes things a bit easier. It will allways accept the normal type of array, and you can leave out unnecessary information. What is unnecessary?
         1. The column name when there is only one column. This function figures it out for you.
         2. The outer array when you are setting a single item. 
         3. In multiple-column fields, you can include extra fields(to annotate the data). They are silently ignored.
         4. The field_ at the beginning of the field name is options.
         5. In the very common case where there is only one column and only one row, then the value can be passed without being enclosed in any arrays.
       • Some things can't be left out.
         
         1. All the columns that the field uses must be included in each of the inner arrays. If there is more than one column, then they must be specified by name.
         2. When passing an array of arrays for a field that only has one column,  the inner arrays have to be keyed correctly, or the first value is used. (the one that can be indexed with 0)
    4. No validation is performed. Noramlly when a node is edited, submitted, and saved, the module that defines the node gets a chance to make sure everything is working correctly. It isn't given the changce. Most hooks involved with editing a node are still evoked. Specifically the hooks for loading and saving nodes. Only forms-api and some cck-api based hooks are not evoked. 
• A function that inserts an item into a field
  • Arguments are the same as above, but with one addition
    1. There is a 5th argument, which is also optional, that specifies whether to prevent duplicating an existing item.
    2. This function only accepts single item (rows), so the outer array is not required or allowed. The value must be either a simple value, or an array keyed by column name.
  • Return
    • The same as above, true on success, false if nothing happened or there was an error. drupal_set_message is used to return any error message.
  • Caveats
    • Only sets a single item. Make multiple calls to set multiple items.
    • This function is very similar to the one above.

• An ajax interface for both functions
  • Can accept arguments on the url or in a header variable.
  • Can accept arguments from both url and header at the same time. The ones passed in the url have higher precidence.
  • URL arguments aren't unescaped before processing. They are separated with slashes, and must be in the correct order.

• A function that displays node contents
  • One argument, the node id, which must be specified in the url if evoked from the client side
  • The result is the contents of the php variable representing the fully loaded node, in a human readable format.
  • After the dump of the node contents, the cck fields are displayed again for emphasis and easy finding.
  • This will often be the easiest way to get column names.

Assignable Mission Details (Ignore for open missions)

Category: 

task

Priority: 

critical

Assigned: 

Agent0x45

List: 

Current Goals

Drupal Dev List

We are going to be doing a lot of monkeying with cck fields, and not allways using the forms that the cck creates for you. We have already seen that minor rearrangements of the structure of the node type (such as putting a field in a group) breakes any prepopulate code that altered the values in the form. We need to be able to alter values, save them, in a safe, easy, and consistant manner.

 

This mission will have several steps, which will be associated with version numbers. Each version will add features.

I am presently working on a module that will provide the functionality that we want for user profiles. It will be usefull in lots of other places. Probably will expose itself as a ccd field type and/or a pannel plugin. As is, it can be used anywhere php is used.

My first project is called icons module and it embeds 16 pixel CSS icons into specified link paths both in Drupal menus and through Drupal content input filtering which can be turned on and off and supressed using the "noicon" class.