Voting starts in March for the Drupal Association Board election.
I have take this text from http://www.angrydonuts.com/views-3-x-roadmap, I will use it to comment which is the actual status of this road map:
I've spent a lot of my 'between' time thinking about what I want to see for the next major revisions of Views, and I've finally decided to sit down and actually create a road map. Views 3 isn't like Views 2 in the sense that there will be a rewrite. On the contrary, I'm really happy with the foundation of Views 2 and I believe that we have a solid system for building on. What I'm unhappy with are features that got left out, or that I didn't even know we would need. The enhanced flexibility of Views 2 opened the door for a wide array of features and the best part is that Views is now so widely used that I'm not the only person doing work on this. In fact, Views 3 has the potential to be primarily community work rather than just me doin' my thing. This is quite a transition for me, as I'm used to being the developer, plugging away and working on my own schedule.
Here is the short list of things that I want for Views 3. This is not exhaustive, but these are the major points. Many of them are already being worked on. However, there's over a hundred patches in the Views queue that I need to review, and I'm not including a whole lot of those in this list. But I know that many of them are worthy and will get in, possibly in both the 2 and 3 branches.
Make as much functionality pluggable as possible
- Query backend pluggable
- Right now Views only knows how to do SQL. But several very dedicated contributors have worked to move aside the query object so that it can be a plugin. What does this mean? Integration directly with Solr, FlickrAPI. Heck, any Restful API can be used. In theory this could mean integration with RDF (though my personal feelings on RDF are not in keeping with the greater sentiment these days). I've actually committed this to the 3.x branch already.
Status: Complete, Issue:
Header/footer/empty text pluggable Right now the header and footer just go through ordinary filters. Sure you can put PHP there, but one thing I've learned is that if you're using Views as part of your module and you want to distribute it, having PHP embedded in the view is bad. In fact, embedding PHP anywhere has turned out to not be a great long term solution. Therefore these desperately need to be pluggable so that we can do more things with the header and footer area. Especially if they can get some knowledge of the arguments so we can do more things there.
Status: In Progress, Ready for testing, Issue:
Notes: We need an small rellol of this patch because settings of plugins are stored differently after , also dww is interested in this pach because he want to use it for some functionality of Drupal issue queue. See:
Translation plugin Nedjo Rogers started work on a plugin to help i18n better integrate with Views a few months ago. This work seems to have been picked up again and there is a patch here: http://drupal.org/node/357529. Anyone interested in properly integrating Views with i18n should participate, because I think this is important and it's an area where I don't 100% understand all of the parameters. From what I can tell, the patch is actually very close, and it just needs some people to really work on it.
Status: In Progress, Need work, Not ready for testing. Issue:
Notes: Actually Jose Reyero is reviewing this patch, there is some important issues we need some help here.
Views result caching Jeff Eaton took some code I wrote for Panels and wrote what appears to be a fantastic caching plugin for Views: http://drupal.org/node/468824. It can cache either the results of the query or the output of the view and the mechanism for figuring out when the cache needs to be expired is completely pluggable. This one will probably get checked into the 2.x branch because it's that good.
Status: Complete, Issue:
Notes: This patch is in views since 2.6 version, there is some issues related to the cache plugin
Pager pluggable When I was nearly done with Views and I was playing with the AJAX stuff, I wanted a smaller pager to put into blocks, because the standard pager doesn't fit. And having AJAX in a block is really handy, so I added the mini pager. I should have simply made it a plugin, but not just on the output side, on the input side too. So that we can do more stuff with pagers. See my blog post on how we can fix the pager system. That can be applied to Views. Sure, it may not necessarily match the built in pager system, but if a site is mostly Views powered, then it may not matter too much, and the power and flexibility it provides could be really nice.
Status: In Progress, Need "a lot" of work, Not ready for testing. Issue:
Notes: This patch is very complex, and the implementation of this feature will help to solve:
Better support for view as form I would like to see Views be able to do mass editing, bulk operations, etc as plugins rather than as styles, to be able to more fully integrate the form right into the view. Right now this is possible through styles but is not as clean as I would like it to be. It would require fields to become form aware, and forms to be able to know what to do with fields. It's an interesting project.
Status: Not started.
Exposed form updates
Exposed forms need a lot of love. They required a lot of hacking to get to work right, and there are still many problems with them, and many, many feature requests. I want to see a lot of them go in, finally.
Exposed sorts Filters are not the only thing that should be exposed. Sorts. Work is under way on this: http://drupal.org/node/228510
Status: In Progress, this patch is ready for testing but probably can be implemented in a more elegant way using Exposed forms
Notes: I'm waiting to get this commitedto rerroll the patch.
Own section in UI To start with, the exposed forms have enough possible settings that they need their own section in the UI so that we can give them their settings. We can intelligently unset this if nothing is using the exposed form or maybe we can require it to be turned on before the 'expose' button shows up on anything. Control of text on 'button' Paired with a proper translation plugin, this would be a nice little touch. Exposed form styles? I don't know for sure if this makes sense, but in theory this could go a long way toward helping control how an exposed form looks. Right now it's hard pushed into one look and that's not always what people want.
Status: Completed. A new kind of plugin (Exposed Forms) was created an provide this feature.
Form builder integration Maybe this would be in place of form styles, but integrating it with quicksketch's form builder in order to have greater control over the exposed form would be nice.
Status: Not started.
Ability to have view not run when no value selected People constantly ask for this feature, wherein the view will be empty until something has been selected in the exposed filters.
Notes: This can be done by using "Require Input" Exposed form plugin.
Retool to rely on CTools
CTools was built in part from work I did on Views. It's time to throw away old code and move to relying on CTools. This would make Views itself slightly smaller, and put CTools out there for everyone to use. CTools would effectively become a Drupal API extension, and I think that's a good thing.
- All of Views' form.inc file can be removed and rely pretty much direclty on CTools version instead.
- CTools AJAX tools are actually superior to Views' versions. Views would need to be cleaned up a little but a lot of the .js code in Views could be stripped down and made a lot better by using the CTools AJAX tools.
- The one thing CTools didn't get from Views is the tabs. Those are using a wrapper around jquery UI. Of course, there is now a jquery UI module, so we need to figure out if the tabs should go into CTools or if we should require JQuery UI module.
Status: Need work. There is three different issues for this, but only one is ready for testing.
Tabs: Is not started.
This is a list of everything else. Not that these are less important, just that there aren't many individual pieces to them.
- Group by support
- There are the views calc and views groupby modules. We can make them more or less obsolete by putting proper group by support directly into Views, supporting aggregate functions for all or at least most fields, and fixing all of the handlers to understand how to deal with GROUP BY queries. Issue: http://drupal.org/node/396380
Status: Completed. This need a lot of testing.
Notes: This also require a documentation update.
OR support This requires two things. One, there needs to be a way to group filters (and the exposed sorts could use this same functionality) together in the UI. Once this is done, we then need to go through all of the existing arguments and filters and make the WHERE GROUP aware. There are some filters in Views that are known to fail with the views_or module. These can be fixed and need to be.
Status: In progress. There is nothing to test yet. There is a preliminary UI to see if this is what we want. Issue:
Better visibility of arguments for access plugins It turns out to be very difficult to write access plugins that deny access based upon an argument. This is a lot easier with a context system. Well, if we rely on CTools, we can leverage context for this.
Status: Not started. Issue:
Argument validator reverse transform for summary links The argument validator has features that allow it to transform arguments. For example, it can take an taxonomy name or synonym and translate it into a term ID. But what it can't do is translate that *back* to the proper argument when using the summary view. This just requires an expansion to validation, and some smarts in the summary view. Attach feed to arbitrary URL Right now feeds can only attach to other displays on the same view. But a comment RSS feed would really like to be able to attach to a node with the right argument. This needs to be able to watch URLs and attach Views to them. It needs to do this in a way that doesn't kill performance, however, so needs a good design to do it right. Revision logging It would be nice to be able to log when Views are changed. Because Views properties are all declared, we should be able to expand on this and record not only who made changes but record exactly what was changed.
None of this issues were started.
Re-order displays in UI This could probably go into 2.x, really. We just need to leverage tablesorts and allow displays to be re-ordered. Their order does matter for some things and the fact that you cannot re-order them is a bit of a pain.
Status: In Progress, ready for testing: Issue:
Note: Earl Miles found an error while he was testing this patch. However he can't replicate it. I have tried this patch too and cannot replicate neither. So we need more testing on this feature to see if it is really ready.
I will update this post when the status of these issues change.