On 26 Mar 2007, at 15:53, Larry Garfield wrote:
[ack! sent this from the wrong account so I suspect the original got held by the list software, apologies list admins]
Thanks for wading in here Larry,
It looks like in your argument code you're trying to pass in an argument for each related nid. That's wrong. :-)
Heh, that figures. *:)
Instead, just pass the current nid (which you are getting correctly) as the argument, and then use that single argument to filter the nodereference field. You don't need any SQL for it; Views will do the "WHERE field_related=$nid" part itself.
Okay, that makes more sense, but I think I'm getting confused with the views.module terminology and where exactly I'm supposed to be filtering the nodereference field. This is what I have now (with some inline comments as to my understanding):
# Block Provides Block View Type: List View Nodes per Block: 10 (usually there are only 3-5 referenced nodes, but I want to have some headroom for expansion)
# Fields Node: Title, as link (this is what I want the block to display right?)
# Arguments Node Reference: Related Articles, Display All Values (take the argument from the handling code and apply it to these values)
# Argument Handling Code if ($type == 'block' && arg(0) == 'node' && is_numeric(arg(1))) { $currentnode = arg(1); } return $currentnode;
# Filters Node: Distinct is distinct (in case there are less than 10 entries I only want one of each) Node: Type Is One Of 'Article' (not entirely sure I need this as shouldn't the argument handling code only return articles anyway?)
This view now returns 10 articles, but only 2 of them are actually referenced by the current article, which seems to be happening through luck rather than any determination on my part *:).
G.
-- ------------------------------------------------------------------------ Blog: http://polytechnic.co.uk Photos: http://flickr.com/photos/garrettc Music: http://last.fm/user/garrettc1
There are actually 3 related parts to a view to restrict what gets shown: Filters, Exposed Filters, and Arguments. All three end up as part of the WHERE clause, but originate from different places.
Filters are hard-coded in the view itself. Exposed filters are provided by the user via a form that submits a GET query. Arguments are variable parts of the Drupal path used to get to the view in the first place.
I think I misunderstood your original data model, though. Does a node have a reference to "this is a related article of X" or a multi-value nodereference field for "the following are related articles of this node"? I was talking about the former, but now that I think about it you may have been talking about the latter. Can you clarify?
--Larry Garfield
That's assuming your data model is that a node
On Mon, 26 Mar 2007 17:30:42 +0100, Garrett Coakley garrett@polytechnic.co.uk wrote:
On 26 Mar 2007, at 15:53, Larry Garfield wrote:
[ack! sent this from the wrong account so I suspect the original got held by the list software, apologies list admins]
Thanks for wading in here Larry,
It looks like in your argument code you're trying to pass in an argument for each related nid. That's wrong. :-)
Heh, that figures. *:)
Instead, just pass the current nid (which you are getting correctly) as the argument, and then use that single argument to filter the nodereference field. You don't need any SQL for it; Views will do the "WHERE field_related=$nid" part itself.
Okay, that makes more sense, but I think I'm getting confused with the views.module terminology and where exactly I'm supposed to be filtering the nodereference field. This is what I have now (with some inline comments as to my understanding):
# Block Provides Block View Type: List View Nodes per Block: 10 (usually there are only 3-5 referenced nodes, but I want to have some headroom for expansion)
# Fields Node: Title, as link (this is what I want the block to display right?)
# Arguments Node Reference: Related Articles, Display All Values (take the argument from the handling code and apply it to these values)
# Argument Handling Code if ($type == 'block' && arg(0) == 'node' && is_numeric(arg(1))) { $currentnode = arg(1); } return $currentnode;
# Filters Node: Distinct is distinct (in case there are less than 10 entries I only want one of each) Node: Type Is One Of 'Article' (not entirely sure I need this as shouldn't the argument handling code only return articles anyway?)
This view now returns 10 articles, but only 2 of them are actually referenced by the current article, which seems to be happening through luck rather than any determination on my part *:).
G.
--
Blog: http://polytechnic.co.uk Photos: http://flickr.com/photos/garrettc Music: http://last.fm/user/garrettc1
-- [ Drupal support list | http://lists.drupal.org/ ]
On 26 Mar 2007, at 19:10, Larry Garfield wrote:
I think I misunderstood your original data model, though. Does a node have a reference to "this is a related article of X" or a multi-value nodereference field for "the following are related articles of this node"? I was talking about the former, but now that I think about it you may have been talking about the latter. Can you clarify?
It's the latter, so authors can add related articles already in the system to the piece they're currently editing.
If it helps clarify, this is the content_* table that show the articles related to article nid 72:
mysql> select * from content_field_related_articles where nid = 72 order by delta; +-----+-------+-----+----------------------------+ | vid | delta | nid | field_related_articles_nid | +-----+-------+-----+----------------------------+ | 72 | 0 | 72 | 28 | | 72 | 1 | 72 | 67 | | 72 | 2 | 72 | 69 | | 72 | 3 | 72 | 44 | | 72 | 4 | 72 | 43 | | 72 | 5 | 72 | 26 | +-----+-------+-----+----------------------------+
G.
-- ------------------------------------------------------------------------ Blog: http://polytechnic.co.uk Photos: http://flickr.com/photos/garrettc Music: http://last.fm/user/garrettc1
-
Garrett Coakley -
Larry Garfield