Views 2 development tasks remaining

This wiki page summarizes the remaining Views 2 development tasks. This is a wiki so that interested developers can help implement some of these features. I can provide help implementing this stuff on IRC; find me in #drupal-views. (Note: Not a support channel. Development. I will quickly ban inappropriate support requesters).

People are reporting that they get a whitescreen when editing the wiki. I have therefore opened up comments to let people claim/unclaim tasks by adding a comment.

Todo:

Links to edit/export/clone view from view. Similar links from the edit view page. (unclaimed)

I want to use the rollover links that Panels uses. We're not going to rely on tabs any more.

Allow callbacks for access

views_handler_field::access() should use a system similar to the Drupal menu system, with 'access callback' and 'access arguments'. The reason for this is that access to a field isn't necessarily really related to the type of the field you're displaying, but most of the base handlers are geared to the type of data. This lets a handler easily specify its own access callback, making it independent from what handler is in use. This wouldn't change the overrideability of the ::access() method.

Create an 'overview' documentation page using doxygen.

This page should be an introduction to Views and describe overall architecture, and provide links to important areas.

Document more detail on each of the base handlers.

Each base handler should document precisely what items it can accept in the definition, so that this information is easy to reference. It should also document any special caveats and perhaps document some "core" examples of the use of the handler.

Create a view analyzer tool

Known needs: 1) display a full list of templates the view will use. 2) Give warnings if the view seems wrong. For example, check for the presence of the 'published' filter for 'node' views and compare to access control.

node.views_convert.inc

We need to convert old handlers to the new format; this has a big effect on options since the old system stored things very differently.

comment.views_convert.inc

profile.views_convert.inc

search.views_convert.inc

book.views_convert.inc

userviews_convert.inc

taxonomy.views_convert.inc

Finish statistics.views.inc (unclaimed)

statistics.views_convert.inc

upload.views_convert.inc

Roughly 30 @todo items in the code. Many are very easy.

Many include adding 2-3 UI settings, putting in a validation path, or the like. Most are 30-60 minute tasks.

convert.inc does not convert tables

Much of the data for the table style has moved from the fields into the table config itself; it needs to take this into account and populate this information appropriately.

Implement date API date popup on views_handler_filter_date fields if date api module is enabled.

This popup isn't too difficult to implement, but because it happens during an ajax point, making sure the javascript is preloaded is going to be necessary.

Completed:

Relationships (claimed by merlinofchaos)

Relationships are only partially implemented. They need to be fully implemented still.

Edit locking (unclaimed)

Because Views are stored in a temporary cache, it will be possible to examine this cache and determine if a given view is currently being edited and how long ago it was last touched. We can use this information to 'lock' a view. We can provide administrators the ability to 'break' a lock which will flush that view from the cache.

RSS, 'feed selector' argument (unclaimed)

This should be implemented in Views 2 as a display type; that way RSS feeds can have their own precise URL and can use the mechanism that the "attachment display type" uses to add info (meta, icon) to other displays.

Javascript: Prevent 'Save' button from being clicked if 'Update' button is visible (ezra-g)

This is an interrupt that is needed to prevent accidentally clicking the wrong button. I didn't have a problem with it when Update was on the right, but with it on the left I click Save too much; I'm sure this happens to other people.

'More' link on blocks (claimed by alpritt)

This should be very easy to implement, but requires digging into how plugins implement their UI.

Javascript: dependent.js (claimed by merlinofchaos)

get dmitrig01's dependent.js to work and implement it in several areas in the UI (notably 'access', 'menu' and a few other areas where the fields are conditional). This is a low priority feature as I consider it polish.

node.views.inc (claimed by merlinofchaos)

There's still a bunch of cleanup to do here.

user.views.inc (unclaimed)

taxonomy.views.inc (claimed by merlinofchaos and neclimdul)

This one is just hard (This was even harder than I thought it would be)

comment.views.inc (Claimed by alpritt (issue #223035))

profile.views.inc (claimed by neclimdul?)

search.views.inc (claimed by Doug Green?)

book.views.inc (claimed by John Morahan)

upload.views.inc (unclaimed)

Allow two displays on the same view to use the same path (claimed by John Morahan)

This requires retooling the menu interface to take a list of display IDs; it would then allow the first display to allow the user access to the display to control it. The system should thus implement something like $view->choose_display($id1, $id2, $id3) and set the first accessible display.

Implement the 'distinct' filter as an option on the display. (claimed by John Morahan)

DISTINCT isn't really a filter; it makes sense to just make it option. That way it doesn't need to be tied to a table, which is problematic in Views 2.

Implement random sort as an option on the display OR make a way for views data to not be tied to a table. (claimed by John Morahan)

While it is less obvious to do this than the distinct filter above, the random sort is not tied to a field or a table, and the views data has no easy way to make a sort that has absolutely no tie to the data.

Attachment display type

The attachment display type would attach itself to other displays. Essentially it would be a very simple way to effectively put two views onto a single page. The main use case is for the glossary view: The main view has the "node: title argument" set to 1 letter, set to display empty text or maybe a new setting to provide a default value if not given. The attachment, then, attaches itself to the top (or bottom) of the view but it discards the arguments, forcing it to always display the summary view.

Punted to 2.1:

Implement a pluggable caching mechanism, similar to the Panels one. (unclaimed)

The Panels caching mechanism lets each display select which cache mechanism to use. That mechanism then receives all the data required and has the option of returning data from cache prior to building the view. If not, the view is built and at the end, the data is offered up. It's important that all of the data necessary to actually completely build the cached output is made available as some caching mechanisms will cache at a later time (such as on cron).

Filter groups (unclaimed)

Filter groups are how I plan to get an OR into the system. I consider this a LOW priority because Views 1 didn't have it and filters more or less work without it. That said, it'd be handy; the underlying structure is there; mostly this just needs to be UI and to make sure that the existing filters respect their group settings properly.

Exposed sorts (unclaimed)

I'm not entirely sure how to do the UI for this; unlike exposed filters, sorts all end up in just one gadget, so there has to be something that glues it all together.

Please, if you claim something, commit to doing it. I want to go -beta by beginning of Apr; that gives us 2, maybe 3 weeks to complete the above list.