I believe the evil credentials of views and CCK are well established. I wanted to unveil a new module that combines the two into an unbelievably devilish system: viewfield.
Viewfield allows content type administrators to add view reference fields into CCK content types. When a user creates one of these nodes, he/she can select from a list of views to embed into the node. When the node is viewed, the view runs and is output as one of the node fields. (Of course this can be themed).
(If you're reading this post in a group other than Drupal for Evil, you're probably wondering why all the references to evil stuff. I suggest you join the group and find out how evil Drupal can be.)
The original design of this module was to replace the default views pages (eg. http://example.com/views/myview). I've always been frustrated by them because there is no "edit" tab. If I want to edit the text before or after the view data, I have to navigate elsewhere, change the text, and then resume what I'm doing. With viewfield, I can create a simple content type (call it "dynamic page") with a pre-view text area, a view, and a post-view text area. Voila - instant replacement for the views pages, with an edit tab!
Of course, this opens up views to an entire world of node operations. Also, the power of embedding a view in a node can be very powerful - other widgets/modules could use the view to do all kinds of interesting things. The sky's the limit.
So, fellow evil-doers, give it a try. Take the next step towards total world domination, courtesy Views, CCK, and Viewfield.
Comments
Does this have support for
Does this have support for automatic arguments?
1) Sending the current node ID as an argument
2) Sending the ID of a linked nodereference field
3) sending the UID of a linked userreference field
4) (2 and 3, actually) sending some linked field an an arbitrary argument, in fact.
5) Sending the author of the node as an argument
There are several interesting possibilities there.
Glad you're interested
There is some "run-time" argument handling in the form of %token replacement.
1) Sending the current node ID as an argument
Yes. %nid in the args list
2) Sending the ID of a linked nodereference field
Not yet. Perhaps %nodereference_fieldname? This would take either the linked node or the first node of a list of nodes.
3) sending the UID of a linked userreference field
Not yet. Same implementation probably...
4) (2 and 3, actually) sending some linked field an an arbitrary argument, in fact.
Sure. Any #value from a field could be substituted using the %field_fieldname syntax.
5) Sending the author of the node as an argument
Yes. %author
There is also a %viewer token for the user looking at the node.
While arguments were the easy place to start, I'd actually like to move towards reusing the exposed filters as the primary method of modifying views at run-time. I wouldn't remove arguments, but using exposed filters allows us a "domain" (e.g. it's a lot easier to pick "My Custom Content Type" from a list of content types, than it is to remember that content-my_custom_content_type should be the nth positional argument. :-)
I think it would be easier to implement some of the field based arguments by altering the exposed views (eg. on a nid filter, we could grab the nodereference fields and put them in as options in a pull down list. cool huh?)
There would be a checkbox to "re-expose" the exposed filter to users viewing the viewfield. This way, exposed filters could be used exclusively by node creators to add additional filters, while still giving view creators a lot of power in limiting what could possibly appear in a view.
I'd still keep arguments, but I'd like them to be less needed.
-M
exposed filters
nice idea to reuse exposed filters during node creation.
clever
very cool. from the "why didn't i think of that" department.
earl's questions about args are spot on. would be helpful. see how views get embedded into panels for some inspiration.
Further progress?
Hi, this module looks to do exactly what I need (I think)... I'm looking to insert a view of nodes (of a custom content type) into a book page, based on what term is selected in the taxonomy of that parent book page. I assume I need to wait for support for taxonomy terms in this module in order to accomplish this? In which case, what is the current progress? I've seen the time line post, but it's a couple of months old now.
By the way, I'm doing something very evil indeed with this, if it's motivational, or of any consolation?
Web Development in Nottingham, UK by Kineta Systems / Follow me on Twitter! @NikLP
I should have a release
I should have a release ready soon that uses the token module to create the replacements, including taxonomy terms. I need to iron a couple of hiccups first, but it's nearly ready to go.
Great...
.... if you could just have it done by nine, that would save me having to tell my client "I can't do it! (yet)" :)
Web Development in Nottingham, UK by Kineta Systems / Follow me on Twitter! @NikLP
What about include support for Token Module?
Hi mfredrickson !
I've already tested Viewfield and I love that functionality. Then i noticed the available tokens: %nid, %author, %viewer, there is a module named Token, this baby allows you to include dozens of tokens including the 3 existing in Viewfield. An example module that includes support for Token Module in CCK is Link
Blessings!
--
Fernando @DevElCuy