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: #293841: Allow different back-ends for Views

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: #510284: Header/footer/empty text and more areas pluggable
Notes: We need an small rellol of this patch because settings of plugins are stored differently after #503452: Retool exports to drill down properly, also dww is interested in this pach because he want to use it for some functionality of Drupal issue queue. See: #366542: Replace hook_help() hacks with a cleaner solution for the dynamic headers on issue views

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: #357529: Implement translation of customized 'translatable' views properties
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: #468824: Add caching system to Views
Notes: This patch is in views since 2.6 version, there is some issues related to the cache plugin
#550962: Caching query results but not rendered output breaks pager
#570558: Split up views_default_views cache to improve memory usage

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: #586668: Pluggable pagers
Notes: This patch is very complex, and the implementation of this feature will help to solve:
#382394: Apply ajax pager effects
#268023: Limiting total number of items....

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
Issue:#228510: Exposed Sorts

Notes: I'm waiting to get this commited #635966: Allow exposed form plugins to alter the exposed form to 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.

Status: Completed.
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.
#563052: Replace views/form.inc with ctools/form.inc
#563020: Replace views_object_cache with ctools_object_cache
Tabs: Is not started.

Other features

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: #118672: Adding sql ORing capability with filters

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: #644008: Passing dynamic arguments to access plugins

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:#338584: Allow displays to be re-ordered
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.


Component:Miscellaneous» User interface
Category:task» feature

I've just come back to views 2.x after using 1.x a lot up until a year ago (new job different technology). I've gone from being able to do pretty much whatever I want to struggling with the UI, and I thought I should get in the loop for the view 3 UI if it's not too late to give some feedback. Not so much for me, just maybe to make Drupal a little easier to use for the less skilled of us. I wasn't sure where to post this feedback so feel free to move this comment if there's a better place for it.

Component:User interface» Miscellaneous
Category:feature» task

I think its better if you add another issue, let's say Views 3: User Interface Discussions as title.

So, here is a small update of the changes:

Re-order displays in UI was commited, but probably there is a hidden bug in a very very special condition, testing is needed. #338584: Allow displays to be re-ordered

dereine and me are doing a importart effort to get a alpha 2 of views 3 as soon as possible. For this reason we have tagged different issues that should be fixed to get a new alpha.

This issues are categorized with the term alpha-2 blocker here you can see that several issues are RTBC, I recommend test this issues instead of marked as Needs review, because probably there is something to enhace before they get commited.

There is a bug that I cannot solve #646236: Some options for views_plugin_argument_validate_user cannot be saved after "Retool exports to drill down properly" If somebody can take care about this I will very appreciate.

The good news are:
Exposed Sorts RTBC #228510: Exposed Sorts

Pluggable Paggers are in! But there is a critical bug that doens't allow to save their settings: #652712: Pager settings are not stored

Now that pluggable pagers are in, #324092: Expose: Items per page and Offset, and #268023: Limiting total number of items.... are ready for testing.

#510284: Header/footer/empty text and more areas pluggable is RTBC, but I would like if something else than dereine and me confirm that it is ready.

Nothing more for now.


Status:Active» Closed (fixed)

created in general discussion here


Status:Closed (fixed)» Active

Why close this issue, views 3 roadmap was the original issue...

Status:Active» Needs work

Dagmar, you could update the page :) There was quite some stuff changed:

  • Pluggable pagers was commited
  • Better support for view as form: You could link views_ff
  • Exposed sorts/Exposed forms update: Was commited
  • OR Support: It can be tested i think
  • Reorder displayed: Commited/li>

- Views OR is commited

Status:Needs work» Active

Here is a new updated to this issue. As dereine said, there is a lot good news, here is the complete list:

  • Exposed sorts. Committed.
  • Exposed items per page, and offset. Committed.
  • SQL or support for views. Committed. This means: Views OR module is not needed anymore for views 3.
  • Displays can be reordered
  • Name for displays can be changed. Yes, you now can change page_1, block_1, etc for you own machine names.
  • Pluggable Areas: now, a view may have multiple headers, footers and empty text, See screenshot
  • Related to #7. Dereine and I have started a new project to allow views to be used as forms. You can see the project Here Views Form Fields but there isn't a official release yet.

There is only 3 issues left to complete all the alpha-2 blocker tagged issues list. This issue have to be fixed before release a new version of Views 3. So, you can review they :)

For alpha-3 probably Internationalization Plugin will be included #357529: Implement translation of customized 'translatable' views properties and maybe some major changes like #470258: Groupwise maximum ('representative') relationships if we get a working version for views 3.

One more thing. There is a big issue with the Internationalization plugin. We need a function similar to unpack_options to translate all strings defined as 'translatable' => TRUE in option_definition() when a view is saved. More info: http://drupal.org/node/357529#comment-2395884




Further suggestion: rearrange query building so changes to the query from exposed filters and sorts are added last, and make it so the query up till that point is easily available to handlers that have participated so far.
This opens up all sorts of possibilities. Example: an exposed taxonomy term filter that only shows the terms in the view's basic result set.


btw, shouldn't there be a 'What's new in 3.x' in the project's page for the new features? I mean since there is a 6.x-3.0-alpha available and all.

Perhaps also a 'What's coming in Views 3.x' for any features in the roadmap but not implemented just yet.

I am thinking + a guide for developers to help them move their modules to supporting it as well?

You can go through the release notes for the alphas, for now; most of them have a "What's new this release", but they don't end to include historical information. Historical information will be included in the beta and official releases notes, though.


regarding views 3 GROUP BY support...
from my initial testing / playing around with views 3, it appears that this feature provides row aggregation but not column aggregation that the views_calc module provided... am I missing a setting somewhere?

I am able to create a "similar" setup by creating a page view and an attachment. The attachment uses the views 3 GROUP BY features. This results in 2 stacked tables which through css can have the columns aligned. I was looking for how to get the aggregation results in the footer of the page views table.

Do you really think this is the right place to ask such a question?

I suggest you to open a new issue.

I did not want to clog up the issue queue with a simple yes or no question about the new features. Besides that, it's a great feature. thanks.

views calc will continue to provide the column aggregation, I think.



suggestion: full row style control like we have in Semantic Views

it allows setting the element and style per column, among other things.

that would be a great addition

There is already an issue about integration semantic views functionality into views.

i think we need a LIMIT for the paged/non-paged views.
from what i understand (might be wrong), Views doesn't actually LIMIT the number of rows fetched from the DB.

not talking of number of results per page, that is already in...
but MAXIMUM/TOTAL number of results for the VIEW (which would also limit the pager and the page count).

to explain this further i'll give in an example:
let's say we have a Story node type, with some content published and rated with fivestar.
we need to output a teaser of this content as a sidebar, but only with the rated content.

so we create a Block view, that filters Published:Yes, Node type: Story, add a fivestar rating > 0, and sort them by rating.
whether we output Rows as Nodes or Fields, and Style as Slideshow, Unformatted list or other, is irrelevant for the example.
we then set the Pager as Mini or Full and turn AJAX on.
and limit the Pager to for example, 2 or 3 items per Page.
then we add the block to the frontpage and voila, we have a listing of most rated stories, sorted by rating.

well that is fine if we have for example 20 stories.
but what if we have 2000 stories?

sure we could limit by >= 4 stars.
and then if we stil have 1000 stories with 4 or 5 stars?

ofc we can limit further, but it gets to a point where we don't want to limit with filters, only the number of results.
we can also use caching, but there is a limit to how it helps.
i think i can anticipate a performance issue....

this is true for other examples:
* Most Sold products in Ubercart
* Most Recent content - if we have a high rate of content creation
* Most flagged content
* and so on...

and ofc, this is more problematic for blocks shown in frontpage.
blocks in frontpage...? "wait?!?! hell no!" i can imagine some people saying.
that feature is good for marketing. but if the results are too many, it will crawl...

also, for the sake of keeping it simple for users - if there is a pager with 5 or 10 pages, users will read and search, but not be afraid to read more on the pages, because they won't be overwhelmed with 100 page number.
and also, if they don't read through all of that, there will be less traffic and less bandwidth costs.

so to sum it up...
if there is an additional option to limit the actual number of records fetched from the DB, that would solve many problems explained above.

that could IMO, be achieved with the LIMIT query.

Pagers in Views 3 can already do that.

oh i see #268023: Limiting total number of items....
that is sweet :)

sorry for bugging














Status:Active» Fixed

At this point, we're pretty much feature complete, and getting close to an RC. Per a check with merlinofchaos, I'm closing this issue.

Does that mean that #1052312: Pluggable Breadcrumbs and #731662: Hybrid Exposed Filters won't be making it in?

Maybe and probably not, in that order.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

@merlinofchaos - if I could make funds available to get Views 3 to a production release, would this be helpful for you?

Pitty for Hybrid Exposed Filters... A golden feature.