Webchick asked me to together a quick timeline of what how I plan to develop viewfield. I can't say no to a request like that, so here it is:
1. Viewfield 4.7 is probably not going to be getting a lot of features. I'll fix bugs as they appear. I consider the lack views formatters to be a bug, so this will be in 4.7.
2. Considering #1, my first priority is bug fixes and getting some basic formatters so the viewfields will appear in other views. If your mind has broken already from having views in nodes, consider having views in nodes in views! ;-)
3.The next step is cleaning up the UI. I'd like to move viewfield to use a UI a little closer to that of views it self (wrt. filters). Pick a view from a drop down, click (add) and the page refreshes with with a new sub-form for that specific view. If it's easy, I'll probably steal a page from the upload playbook and do this over AJAX if possible.
4. #3 will pave the way for using exposed filters to control how the view behaves at view time. Arguments are hard, exposed filters are easy. 'Nuff said. I'm working on a views based node selector form element right now, and I think I can probably port alot of that work over to this project. I may even rebuild part of viewfield as a form element for choosing views and their behavior. Wicked.
5. "Locked Views" - a new form widget to choose the view when the content type is created, so that node authors don't have a choice in the matter. An example: say you are creating a "music album" node type. You want it to always have a view that uses "get the tracks for this album" view. This widget will lock those choices down when you create the node, so that when you create an album you don't have to worry about setting the view. Token replacement (eg. %nid => this node's id) will be very helpful here.
6. Paging: I need to investigate paging in viewfields. There's a high probability that it breaks if there is more than 1 view on a page. I need to look at the pager system and see how it works.
7. Ability to choose output format -- sometimes you might want teaser mode, sometimes you might want calendar mode. Why create two different views if the basic underlying query is the same? Why not just choose the output mode at node creation time (or in the case of locked views, at content creation time).
Ok. I think that's it. I'll post updates to this ticket as I nail these. Feel free to ask comments and/or make suggestions.
-Mark
Comments
Comment #1
mfredrickson commentedformatters added: closed http://drupal.org/node/94122
Comment #2
mlncn commentedThis is fantastic. But as it was posted in the Drupal for Evil group, let me throw a curveball...
* Views dependent on the taxonomy term assigned to the node.
We need a newsletter node type that will "simply" take a given taxonomy term (for the newsletter edition) and serve up several views (articles from various sections assigned with taxonomy that are also tagged with that given taxonomy term for the newsletter edition).
If viewfield had the excellent planned "locked viewfield" functionality, then I'd probably try to figure out how to pass the taxonomy assigned to the CCK node into the viewfield.
Or if it's trivial to use a taxonomy term assigned to a CCK node as an argument in the viewfield, then maybe we'd live without locked viewfields for a while, or I'd try to contribute that patch.
Maybe with the taxonomy_content module - http://drupal.org/node/62451 - it would be easy to use taxonomy terms as arguments to a viewfield view?
I'm about to start a new module, and I'm begging for someone to stop me!
Comment #3
mfredrickson commentedHi Benjamin,
Take a look at
http://groups.drupal.org/node/1826#comment-4696
You'll see that viewfield does support some token replacement (e.g. %author gets turned into the user id of the author of the node.) I think this idea could be generically expanded to include other fields in nodes, including taxonomy.
I don't know how this functionality fits into my timeline, but if it's easy, I'll see what I can do to get it out sooner, rather than later.
-m
Comment #4
mki commentedWhat do you think about relationship beetwen Viewfield and Subform features?
I'm asking becouse these modules was created in similar time and I'm worry about some features could be duplicated. Both module can display related nodes so can be useful in achieving the same objective. Maybe you and MrTaco work on the same problems.
The main difference between Viewfield and Subform in defining relationships between nodes is that Subform can freely select child nodes, and Viewfield can do that only using some view parameters.
What is your opinion? Thank you, I am asking becouse I need some "relatated nodes system" and I don't know what should I choose.
Comment #5
mki commentedWhen I imagine ideal "relatated nodes system", this will be Viewfield-like list of child nodes, but with Subform-like possibility to edit/select/add this child nodes.
Selecting in Subform is more effective, becouse it is based on view parameters, but moreover we can use checkbox to select all or only individual nodes from view-like list.
Comment #6
mfredrickson commentedHi mki,
Thanks for your interest in viewfield, and I see what you are saying - a viewfield is like a subform with everything selected.
At the same time, I would argue that this functionality is actually out of the scope of viewfield. Viewfield puts a view into a node (a list of nodes which could potentially change over time). Subform/other views based node selection tools select discrete nodes (a list of nodes that do not change over time).
On the subject, I am working with MrTaco on this idea, though our implementations differ. But don't look for the results in viewfield, as it's really a separate idea.
Cheers,
-M
Comment #7
mki commentedThanks for your explanation, sometimes I felt adrift in the labyrinth of modules :). You are right, Viewfield is separate idea, I wish you good luck in the development of this module.
Comment #8
inforeto commentedsubscribing
Comment #9
Christoph C. Cemper commentedWow - just found this - subscribing!
Comment #10
alex_b commented+1 for paging ;)
Comment #11
alex_b commentedI put up a patch for paging on the 5.0 issue queue: http://drupal.org/node/101377#comment-191034
Comment #12
mfredrickson commentedStatus update:
Viewfield is now at version 5 (eaton, webchick, alex_b, yched, and stefano73). New features will probably only go into the 5 branch, though bugfixes will probably go into both if possible.
Paging has been integrated (thanks to stefano73 and alex_b)!
UI is the next big item on the hit list. I'm thinking the best avenue is to create a form element to choose views, arguments, exposed filters, etc. This can be reused by other modules who need to select views (e.g. custom pager).
Comment #13
joachim commentedSubscribing.
What Benjamin requests in comment #2 sounds exactly like what I'm after: the view shown in the viewfield is filtered based on the taxonomy term of the node.
Viewfield is ace. Keep up the good work :)
Comment #14
niklp commentedAnother one for taxonomy (as previously requested by me at http://groups.drupal.org/node/1826)...
Is there a rough date for the release of the token support? This will be so cool...!
Comment #15
mabhobs commentedFirst of all, I think this module is a very good idea and I really like the timeline/roadmap.
I was wondering if it would help to integrate views fast search ( http://drupal.org/project/views_fastsearch & http://www.lullabot.com/articles/custom_search_forms_views_and_fastsearch ) to accomplish point 3 and 4 on the timeline? What do you think? (Just a suggestions though. I hope it is helpful. :-) )
Thanks and I look forward to future releases.
Comment #16
niklp commentedFor the love of god please add token support already...
Comment #17
summit commentedSubscribing, greetings, Martijn
Comment #18
doc2@drupalfr.org commentedsuscribing
Comment #19
darren ohOut of date.