A very conceptual question - based on the observation that within Drupal there are several ways of achieving the same (similar) results.
I have built a couple of simple Drupal sites and have a very strong attachment to Drupal due to the power of the taxonomy concept. I am now building a more 'complex' site - probably pretty standard actually... I want to have :
Content Type 1 = universities - these are pretty standard nodes with CCK fields
Content Type 2 = studyhistory - these allow users to log their study history over time at several universities - again custom nodes with CCK
other Content Types, (Images, embedded videos, stories)
The CT1-universitys will be pre-populated by admin before the site opens, ones that are not in the original list may be added by users later...
STRUCTURE 1
Use the CT1-university as a NodeReference, each of the 'child' CTs can be associated with the individual university: then use views and panels to build composite nodes that override the node/% for each university, pulling in the associated Basic Data, plus the list of studyhistories, image galleries, stories etc... Then set up a Faceted Search based on CCK content - to allow users to rapidly find the Universities of interest. (Love Facted search :-)
STRUCTURE 2
Create a vocabulary of all University names, then tag all nodes (CT1 included) with the correct term. Indeed, all the CCK Content cound be Taxonomy terms rather than predfined lists.... Then build the composite node overrides as above using Views and Panels - but having the TermID as the connector (rather than the NodeID as above). Again, user Facted Search on Taxonomy and CCK Content and/or Taxonomy Clouds etc for accessing data...
As far as I can see both solutions would work - and I was/am surprised to find the STRUCTUE 1 option appears to work fine without any use of taxonomy.
One intermediate solution would be to use NAT to have parallel Node Reference and Taxonomy options: however, as far as I can see (please correct me...) NAT has two limitations
(1) If I create the CT1 nodes manually as admin - the NAT creates the Taxonomy term, but doesn't tag the new Node with that term... which could be limiting later
(2) I actually intend to import the nodes from a spreadsheet - this would be much more delicate if there is a taxonomy term that has to be imported also (now importing across multiple tables) - I haven't yet experimented with Node Import, so this may be a non-issue...
For the Child nodes - which will be the User-Generated Content, I don't want to use NodeRef and Taxonomy, as this would be tedious for the user to 'tag' the new content twice (once as NR once as taxonomy).
If you have read this far - kudos :-), now the question:
does anyone have an opinion on whether either of these approaches is better/has limitations I have not forseen/won't work...????
I am leaning towards the first solution, as it is reasonable straightforward to setup in Views and Panels (although I am still learning my way through arguments, contexts and relationshps :-) ....
Comments
bump: Taxonomy vs. NodeReference and faceted search
anyone?
funny how you would be
funny how you would be asking this, as I've been in the irc channel asking the exact same thing. and the answer I got was... well the same one you've got... NONE :(
I will say that I had a 5.x site set up that was constructed using nodereference, and I used a program like addnode so that a user could add a reference if it didn't already exist. I don't know if that is possible with the taxonomy term method. I know the user can make the term if it doesn't exist, but a straight forward method of adding a new node if the node/term combo don't work. I upgraded to 6.x and lost my panels and many of my nodereferences because they were made with an addnode widget which is not available for 6.x This had me rethinking my setup. However...
However after reading your description (which is what I was just about to write in the forums myself to get some opinions... lol) I came to this conclusion:
Nodereference is TWO Items, one connection
Taxonomy is 4 Items, 3 Connections
Example:
Nodereference method:
Node1 -> References Node2 (Straight Connection)
Taxonomy Method:
Node 1 -> References Term Of Node 1 (2 entries in the DB as well I believe)
Node 2 -> References Term Of Node 2 (2 more entries in the DB)
Node 2 -> References Term Of Node 1 (This provides the Connection)
They are then listed by their common term.
Just looking above, the choice might be clear.
Taxonomy method is ALOT more information being stored and connected, however being able to click a term and have everything connected listed is VERY nice.
I personally think a good use of both would be best.
Example:
Node Connections done with nodereference
futher specifics with taxonomy.
Type: Actor Type: Movie
Movies Reference Actors.
Both Share Movie Genre Taxonomy: Action, Adventure, etc...
Sorry about the brainstorm, but I think I've made my decision hopefully that helps you as well.
Appreciate the thoughtful
Appreciate the thoughtful comments - and glad to hear that I was not alone in puzzling over this! I would agree that the 'best' solution is probably an inteligent combination of both.
In your example, if there is no need for a node for the "action" genre, then taxonomy is good... actually thinking all these choices through probably also helps in organizing ones 'vision' of the site itself.
One nice thing about this is that if, later, you want to create a 'page' for the Action genre, you could do so with either system - etiher via the taxonomy/term/x route or by using the node (if you had gone this route originally), combined with views...
A couple more observations.
Using NAT module allows you to create a new Taxonomy Term when you create a new Node - however, a practical limitation of this (when I last looked) was that the Node is not tagged with the term that has just been generated - which seems odd to me, as this is exactly the functionality I would want...
If you use Taxonomy as CCK Taxonomy - you have to watch the settings, as you can :
1) create content in your node, based on selection from the 'list' coing from your vocab terms - this does not 'tag' the node with the term, but just adds it as content - so taxonomy/term/x would not show the node in question.
2) the same, but with the content being also the taxonomy term.
If you use core taxonomy this 'choice' is not possible, and all terms are used as tags - as you would expect.
I have a similar predicament
I have a similar predicament and perhaps you could help shed some light on this for me as well. I have content types called "Companies" that I have added "Cases" to via nodereference and to those "Cases" I have added different related content types, such as "News" Judgment" etc that link to "Cases" via nodereference as well.
My problem is that I want to be able to display the "Company" and each of its "Cases" including the related "News" or "Judgments" all on the same page. I tried Views but do to the multiple layers of Nodereference it only got me a list of the cases associated with the company. Since the "News" and "Judgement" data reference the "Case" I could figure out how to complete the hierarchy in the views 2 page.
so in effect I might have:
Company-- 1 case---news
---judgement
-- 2 case---news
-- 3 case---judgement
Company 2---
etc.. So will this require some custom sql? is there an easier way to accomplish this? **note, each content type is using taxonomy and cck. these are fairly complicated content types.
I originally tried this using all taxonomy and I created the hierarchy of companies, cases, and docs, as I explained above using the built in node and taxonomy functions since each was in effect a taxonomy term. It was easy to do but limiting in the scope of what I need the page to accomplish.
So, I switched to nodereference and content types in place of taxonomy, but now I don't know how to write the PHP to display the data since there doesn't seem to be any built in functions to manipulate the nodereference fields.
Any help or guidance is appreciated.
you might want to take a
you might want to take a look at the http://drupal.org/project/panels module-- it will let you slice, dice, and place content all over the page.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
+1
agree with WorldFallz - Panels is the way to go (although the D6 port is not 100% there yet...)
the problem with panels is
the problem with panels is that the content is nested so the panel can't create the foreach "Case" loop that I need. I need a panel that lists the case and all it's sub-stories that are linked via nodereference. The issue is that each "Company" has multiple "Cases" and each "Case" has multiple "News" or whatever else.
So i need a foreach to get all the "Cases" assigned to a "Company" and inside each case a foreach that gets all the articles related to the "Case". Panels can't do this for me unless I am missing something?
Unless I'm misunderstanding
Unless I'm misunderstanding what you're trying to do, you should be able to created the nodereference lists with views, then place the views into the page with panels. Another option might be to place the views with http://drupal.org/project/viewfield fields in the node itself instead of using panels.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
http://drupal.org/project/vie
http://drupal.org/project/viewfield seems like a viable option although it is still in dev for 6. I have a question thought and the best way I can explain it is like this:
I have a tree of information that starts with the "Company" then 3 "Cases" per Company then 3 "Articles" per Case and then 2 "sub-articles" per article, on the company_overview page there should be each "case" name and contained within each case name are the "articles" relating to that case name and the "sub-articles" relating to the articles (this will be done 3 times, one for each case that exists under the company).
In order to make this work I will need the viewfield added to the "Article", the "Case" and the "Company" and each will appear nested in the company_overview page. Are there any foreseeable problems with the nested viewfields in the example I described? And do you think this is the best way to tackle this?
Are you just trying to make
Are you just trying to make it a drop down? So you click company, and see the cases, then click the case and see articles? That sounds like menu functionality, or something that can be set up with taxonomy.
With nodereference, that's going to be a little more difficult, as it does not create nested paths like you are mentioning. (A Tree, by the sounds of it)
company/case/articles/sub-article.
If you had taxonomy and NAT as mentioned in the first one, then you can make each company, and it will automatically create a taxonomy of the same kind, you can then on your add case page, choose from the available "Company" terms, and NAT will create a term for your Case.
Then when you make an article, link it to the 'Case Term'.
These can be automatically created in the vocabulary of your choice, so you will want to set them up to create themselves. You should be able to use views then, to create relationships between the terms and make the proper output.
As for on Panels. (different option)
I would create an override of company. On this have a panel pane view of all cases referencing the company. When they choose the case, it will take them to the node case page, where it will have a panel pane view of each article referencing the case.
The second method is the one I use, as nested tree structures can become very long.
What will you do if your output has has 5 companies, each with 5 cases and 10 articles under each?
A Fully expanded drop down would be 250 rows long without sub-articles.
I want a list of all the
I want a list of all the companies, and in one click of the company name you go to the company_overview page which has the company details broken out by cases and the cases related content. Each case could be formatted in a fieldset so they could collapse the cases and the content they contain(the content is merely links to each article). the point would be to give them all of the info for that company in a comprehensive overview with just one click.
Is that more clear?
All company articles on one page...
It sounds like the case nodes need to have an embedded view that lists all the articles associated with the case. This way, when you create the company_overview page, you can display a view that lists the cases for that company profile. The embedded view on the case nodes will provide you all the articles for the company, grouped by case.
Notice that this part doesn't require panels. But you can use panels to enhance the company_overview page by inserting other details about the company into other panes, such as contact info in the sidebar. Panels makes it easy to display content from specific fields or from nodes that have a node reference. Check out this tutorial for some interesting possibilities, particularly the section entitled, "Automatic pane template file override", which shows you have to create custom tpl files for a pane (this lets you display portions of a node in a way that is unique to that pane).
This definitely sounds like
This definitely sounds like a viable solution, though a bit less flexible than panels. For some info on using a nodereference for a views argument see http://drupal.org/node/230867. As for performance, i've never used more than one viewfield on a page-- your best bet is to try it out and see.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
how would you propose that I
how would you propose that I make this scenario work using panels?
if it were me, i would try
if it were me, i would try making a node override for the company content type and slice and dice the fields (including the viewfields) into the various panels regions. it's basically the same process as sticking the viewfields in the node, it just gives you a little more flexibility with the layout. If you're happy with the layout of the node, then don't bother. You can always tweak the node presentation with some theming.
That's the thing about drupal-- there's usually many roads to the destination and they're all 'correct'.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
but how do i create multiple
but how do i create multiple instances of that view i.e a foreach of the cases?. I see how panel can format the information but how do I get it to format in a loop type fashion for each of cases assigned to a company?
example: if there are 3 cases - foreach case get all nodereference articles---foreach nodereferenced article get sub-articles. display case 1 as title and articles organized by type underneath with sub-articles under each nodereferenced article.
that would be the view I wanted but the concept of [foreach -- then do this] does not exist in panels does it?
I easily accomplished this
I easily accomplished this in D5 using taxonomy and custom PHP with the existing functions in Drupal. But I don't know how to accomplish this using nodereference and D6. Is there a function that allows you to retrieve all of the nodes referenced by nodereference? If so, I could probably just write some custom PHP to create the view I need. I DON'T want to get into writing SQL queries if I can avoid it.
Is there a function that
That i'm not sure about-- it might be worth asking in the cck queue or browsing the code (i've found a lot of useful functions browsing module code).
I was thinking of this with views-- you'd need 1 view with a nodereference argument for each level of your tree. And you'll probably have to use some argument handling code to get them to cascade properly. In the viewfield settings you can specify what the argument to the view is with code-- instead of taking the top level 'company' nid (which is what you'll use for the 'cases' level), you'll need to pass the nid of the nodereference from the previous field. And so on down the tree. You'd end up with:
Company: top level, node with viewfields
Cases: view/viewfield, nid of the current company node for the argument
Articles: view/viewfield, nid of the cases nodereference field for the argument
Sub-Articles: view/viewfield, nid of the articles nodereference field for the argument
As type that list, another option comes to mind-- perhaps one of node relationship modules (node2node or node_hierarchy) might make this easier. I've always used nodereference/nodereferrer fields for this, but I've not gone beyond 3 levels deep yet.
===
"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime." - Lao Tzu
"God helps those who help themselves." - Ben Franklin
"Search is your best friend." - Worldfallz
I tried the nodehierarchy
I tried the nodehierarchy module and that was great for keeping the flow correct and for creating new parent or child nodes on the fly. However there doesn't appear to be any way to produce the view. The module claims to have views integration but perhaps that it only for D5.
I guess I will look into the nodereference module to see if there are some functions or an API that I could potentially take advantage of.
How did you make out? What
How did you make out?
What module(s) / procedure did you end up using to accomplish this nested node loading?
What type of load time "tax" did you run into doing this many nodes for one page view, if any?
Have you integrated any actions (such as mark this case as complete, or flag this news as read)?
Thanks,
niles
What was the outcome?
What method did you end up following? I'm in the same boat and curious as to what your experiences were.