views

I'm working on a D5 site (yes, unfortunately!) where we use taxonomy to create a "poor-man's-epublish" - basically a view of newsletter issues and articles under them. We have a vocabulary for "Newsletter issue" and just tag article nodes with the term of the issue, like "Fall 2008." Since there are other vocabularies on those nodes we're using the primary_term module to make the newletter issue the primary term.

It's all working great except for sorting: primary_term.module only implements views sorting by term id - it ignores the term weight:

Hi

I have a primary key that is multiple columns, e.g. Last and First Name.

Within hook_views_data() can I declare that I have such a sortable relation and thereby within a view sort by multiple columns?

Thanks

Jeff in Seattle

Hi

I have read the link http://drupal.org/node/357079, but my custom sort handler is not getting called.

Implemented is the following empty sort handler. However, when I select the activated table-style column to sort, this sort handler is ignored.
<?php
class region_views_handler_sort extends views_handler_sort {
function query() {
parent::query();
drupal_set_message('region_id custom query()');
}

function options_form(&$form, &$form_state) {
parent::options_form($form, $form_state);

Note: My proposal has evolved to include a detailed schedule, glossary, and long brief about the reasons why my methodology is at least different, if not better than the existing ones. I have moved the content from this single page to the Package Management project page. The project home page links to the SoC Proposal with the schedule.

Old Titles for this project ordered by earliest (from these you can see 3 major aspects of the project):
Automated Drupal Software Appliance Builder

Overview: Views have only used minimal amount of the power of taxonomy. Some of the rich feature of taxonomy were never explored. This is a project to implement some codes to make views do more with taxonomy.

Description:
Currently, the only thing we can query about taxonomy in views are.

• Is one of a set of terms
• Is non of a set of terms
• Is all of a set of terms

There is no support of term relations at all.
If a node N is associated with term A and B, where B is a child of A, then the user might only tag the node with B. With the current views, a user specifies to select nodes associated with A, N will not show up. Thus is one of all children/ direct children comes in handy.

With this idea in mind, I believe here are some features might be awesome for views to have

• (Is one of/Is non of/Is all of) + A term + (all parents /direct parents /all children /direct children /related)
• (Is one of/Is non of/Is all of) + few terms + (Union/Intersection of)+(all parents /direct parents /all children /direct children /related)
• When those are not enough, more complex taxonomy queries can be made in views. Only a query language based on term/term will be implemented. (i ('triangle' 'ellipse') (! (p 'circle'))) means return terms 'triangle', 'ellipse' that is not a parent of 'circle'. The returned terms can then be used to find nodes, perhaps though tql, which is a query language based on term/node relation.

The all parents and direct parents functions can be replace by a nth level parents function, gives it more functionality.

Here is a description of the query system and what will be achieved.

The query system can take the full power of the taxonomy system and return all the terms(not nodes, but could be extended to nodes) meet the specific requirement.  The syntax is lisp like, but different keywords.

There will be 3 stages in the query system. One must be completed in order to work on the other. User can chose which stage to activate in module administration.

STAGE 1. Relational select.

This stage only supports queries based on taxonomy relations. The result of a query is a list of term(s).

During stage 1,There are only 2 types of manipulate-able data. list(of terms), terms(or negative terms).

Here are some functions.

Basic structure

• 'term name' returns 1 or a list of terms with "term name" as it's name
• ('foo' 'bar') is a list, list a can contain terms or more lists. Each element is separated by space
• 1 this is a integer, in stage 1, it is the same as return a term with id 1.

Selection functions

These functions are kept to be minimal in size, because these are the ones most likely to be used.

• term return the term.
• (c term) returns all direct level children.
• (c list) (c term term term) is the same as ((c term) (c term) (c term))
• (p term) returns all direct level parents.
• (p list) (p term term term) is the same as ((p term) (p term) (p term))
• (r term) returns all related terms.
• (r list) (r term term term) is the same as ((r term) (r term) (r term))
• (| list) (u list) union lists of terms, also works as 'or' in conditions
• (& list) (i list) find the intersection of lists of terms. , also works as 'and' in conditions
• (! list) (n list) turn every term in the list to it's negative counter part. For a term, it return negative term. For a non-zero integer, it returns integer * -1. For 0, it returns 1. so it can be used as not in conditionals.
• (lca list) Lowest common ancestor of all terms in the list. This is a example of higher level functions in stage 1, more will be implemented, for efficiency reasons.

This set of functions is enough to select any possible set of terms though term relations. Efficiency is the main concentration.

For any function in stage 1, it's ok to have multiple list as inputs, it will flatten and join all the lists. u( p('foo' 'bar') 'bar2') is the same as u( (p('foo' 'bar') 'bar2'))

Stage 2. Conditionals and loops

Stage 1 should be good enough for most people, considering entering stage 2 will make the query language enough to do programs.

Conditionals and loops

• (> int int) first integer larger than 2nd integer, return 1, else 0
• (< int int) first integer smaller than 2nd integer, return 1, else 0
• (<= int int) first integer smaller than or equal to 2nd integer, return 1, else 0
• (>= int int) first integer larger than or equal to 2nd integer, return 1, else 0
• (/= int int) (!= int int) first integer doesn't equal 2nd integer, return 1, else 0
• (if int list list) if 1st integer > 0, do the 1nd list, else do the 2nd list.
• for and while loops.

Stage 2 functions

• (is_child list list) return 1 if every term in list 1 is the child of every term in list 2, else return 0.
• (is_parent list list) (is_parent a b) is same as is_child(b a)
• (is_related list) return 1 only if each term is related to all other terms in the list.
• (is_sibling list) (is_sibling a) is the same as (if (> (size (i (p a))) 0) 1 0)

• (size list) return a list of number in the list.
• (rsize list) return the total number of terms in the list, it runs recursively.
• (+ list) (- list) (* list) (/ list) (% list) basic arithmetic functions.

A possible example of return all terms under "triangle" with more than 3 children.

It's possible all the condition and loops be replaced by a sugarcoat of SQL WHERE.

If it's the latter, everything in the conditionals and loops list will be replaced by (w string), where here string can be a SQL WHERE statement.

Stage 2 allow a new type, integer. There is no distinction between term and integer in representation.

STAGE 3

During stage 2, it will support more than queries involve on calculations of taxonomy relations. It will work on other taxonomy data, like name and description. It can also some useful function will be made into the system. Include a new type string, and possible uses for it. For example, return terms starts with letter "c" and is a child of "animals" will be possible. It could be merged with stage 2 if SQL WHERE statements are more efficient.

Why is the query language useful?
The query language is not useful for small, tree-based, not-well-structured taxonomy. But when there is any taxonomy having terms with multiple parents, the query language can show it's power.
If a person want a wine that is both "Loire" and "White Wine", he can select the children of the common children of "Loire" and "White Wine". In this case, it returns any node tagged with "White Loire". Suppose a user enjoys "White Loire" and "Semillon". He want to find any other wine to drink. It's reasonable to say there could be some common property of those 2 wines made the user like them. So the user can use the lowest common ancestor(LCA) function. LCA finds the nearest common parents for both terms, which can be considered as the common property of both terms. LCA of those 2 terms will return "White Wine", and the user then can browse other terms in "White Wine" and might find something he likes. The query can become complex. Users who don't like "Loire" but enjoy "White Wine" can return only terms that are children of "White Wine" but not "Loire", unless it's both "White Wine" and "Loire". That query can be written intuitively as (u (i (! (c 'Loire')) (c 'White Wine')) (i (c 'Loire' 'White Wine'))).

Rough timeline

Starting from the coding day:

1st week of coding: Complete all taxonomy query operations for views described in the proposal. This does not include the query language.

2nd week: start implementing stage 1 of the query language

1 week before mid-term: complete stage 1 and make sure stage 1 system works correctly.

just before mid-term: make the decision on how to implement stage 2 and 3.

after mid-term: implement stage 2 and 3.

1 week before August 10th: integrate the query language with views + work on documentation

August 10th to 17th: fix bugs, do some tests and set up a demo site.
Mentors:

• randommentor0 - Anyone interested to be my mentor?
• randommentor1 - backup mentor, will help with coding standards, etc.
• ALocalMentor - I will be in US only till middle of July, and I will be in China for the rest of the summer.

Difficulty: medium

Hello everyone. I am the author of the Facebook-style Statuses module, and I have recently completed writing the reorganized 2.x branch (now in CVS/dev). The API should be clearer now and there are a few cool new features. In the next week or so I'm going to add/update two of the three remaining features: Advanced Forum integration and AHAH-driven status submission.

However, the one thing that I don't have any idea how to do is Views 2 integration. I've gone through the documentation and tried working through it before without success. So I would really appreciate it if someone who was knowledgeable in this area could guide me along with my foray into Views--whether that means reviewing integration that I write that doesn't work or actually writing the integration for the module yourself. I consider this an essential feature of the 2.x branch since it means not just integration with Views but also with FriendList and Flag Friend, so I will do it completely by myself at some point if no one steps up to help, but it would save me untold time and pain if someone could offer a little guidance in this area. And of course you'd have my perpetual gratitude.

In my system I have a series of nodes that are created every hour, each one with a set of environmental paramaters. the date is stored as a cck datetime with the time ignored and the time is stored as an integer in a cck feild and is from 0-23. Lastly is a field called station which contains a code for a particular station. Now at run time during creation of the nodes, which is handled by feedapi, a series of physics equations which has been converted into php functions and are activated by a set of trigger rules and rule sets.

Official proposal at GSoC.

Introduction

I'd like to seed a discussion on Contextual overrides for views 2 module, a possible extension to the Interests module (Which i originally developed while working at Agileware and still partly maintain). I would also like to point out contextual based modules already exist, but they are not what this module has in mind.

To give some background on the idea...

I want to create a portfolio page, which is basically a view with all portfolio nodes. I never want to display portfolio nodes on an own page. I came up with a concept for this, hope someone could confirm this would work and if its a good idea from an SEO point of view (for example). I also posted this question on the drupal forums, but i think this is a better place.

Anyway, this is the idea:

1. I create a view to display all portfolio nodes.
2. I create a panel page to override portfolio nodes.
3. I put the view into the panel.