Posted by merlinofchaos on July 15, 2007 at 12:17am
Originally posted at my blog, these are my high level design goals for Views 2.
Views 2 will be the Drupal 6 port. Views 1 will not be ported to Drupal 6; this is so we can make wholesale changes to the API at the same time there are other changes, reducing the number of complex upgrades required.
- Spiffy new AJAXy UI
- Thanks to my work with Panels, I have some really good ideas and knowledge for the Views 2 UI. dmitrig01 has volunteered to help out with this, as well. The huge UI that you're used to now is going to disappear; instead, it should be a much smaller, easier to 'see' UI with a lot of the configuration coming in modal popup dialogs. Hopefully this will also degrade acceptably. Sorting will be javascripty; not sure if it'll be drag & drop or just clicky arrows. We'll see.
- 'node' not the only base table
- Yes, that one annoys people. Views 2 will allow base tables other than node. In addition, it will allow fields to specify that they're in alternate versions of the base table. For example, if you have a nodereference in the view, you will be able to specify that field comes from the referenced node, not the base node.
- Separate output type from the View
- Right now, Views has a page view and a block view and a sort of broken embedded view. These will be broken out into pluggable output types. They'll be added to the view similar to how other things are added. This means you can have multiples of them. Additionally, fields and arguments will be associated with this, so different output types can have their own sets of fields and arguments.
- Exposed upgrades
- Like filters, sorts will be exposable. The UI for this will be smarter, there will be more options for how to display the filters, and filters will be namable so your URLs aren't full of ?filter0=foo&filter1=bar. Also, exposed filters won't have the "only one of a kind works" limitation, making it easier to do ranges.
- OR groups in filters
- You'll be able to create groups of filters that are OR'd together. Hallellujah.
- Style plugins get options
- I hope this one speaks for itself. There hasn't been a greater need than for style plugins to be able to set options, especially as contrib authors have created more and more complex style plugins.
- Redo cache tables -- split cache by table
- There is a problem with Views' caching getting too big. We'll split that up and each table will be cached individually. This may have a performance impact. It may even be positive.
- Clean up the API
- The API is unclean; it is inconsistent and some data isn't always available. Because of this, it's hard for some handlers to communicate the way they need to. The $view will always be available; the $query will always be available if there is one. As much information will be attached to the $view as possible.
- filters, arguments, sort criteria and fields get more complex options
- Right now there's just a handler and an option field. We'll expand this to make it easier for these types to create complex gadgets. Because we can take advantage of AJAX we can do better range filtering.
- Tables
- We'll introduce our own table sorting mechanism that is a little more intelligent; fields will be able to specify which table column they are in.
- Caching hooks
- Views will create hooks to allow external modules to help cache a view, allowing smart performance increases. Views will also have a caching hook that lets modules keep Views' data unloaded until it is needed.
- Broken up even more
- Views will be broken up even more so that less of it is loaded except when necessary.
Comments
Separate the query from the view
Merlin,
Views is a hugely important module, so this is big news.
One of my thoughts: Views is that its really two things. First a query builder, then a display engine. Sometimes I want just the results of the query. Basically, anytime I've written my own them for a view, its because what I really wanted was the list of nodes.
So my suggestion is to consider really breaking it up, maybe even into two modules. One would be a slick query generator, which doesn't care how the results are used. The other can display the results of a query, without caring where the query came from. There have been times I knew I could generate a SQL query by hand, but couldn't quite get views to do it.
Or, is this what you mean by "Separate the output type from the View"?
-Dave
I agree, separating the
I agree, separating the query engine from the display-part would be a good thing.
--
best regards
Ray
If you need a drupal developer contact me!
--
best regards
Ray
If you need a drupal developer contact me!
The query engine is already
The query engine is already separated from the display part. On a programmatic level, you can use views_build_view and get just the query, or a whole lot more information.
From the documentation (yes this is even documented) on views_build_view:
<?php>
/*
* This builds the basic view.
* @param $type
* 'page' -- Produce output as a page, sent through theme.
* The only real difference between this and block is that
* a page uses drupal_set_title to change the page title.
* 'block' -- Produce output as a block, sent through theme.
* 'embed' -- Use this if you want to embed a view onto another page,
* and don't want any block or page specific things to happen to it.
* 'result' -- return an $info array. The array contains:
* query: The actual query ran.
* countquery: The count query that would be run if limiting was required.
* summary: True if an argument was missing and a summary was generated.
* level: What level the missing argument was at.
* result: Database object you can use db_fetch_object on.
* 'items' -- return info array as above, except instead of result,
* items: An array of objects containing the results of the query.
* 'queries' -- returns an array, summarizing the queries, but does not
* run them.
*/
?>
Everyone knows about 'page', 'block' and 'embed', but clearly fewer people realize that 'result', 'items' and 'queries' area available. I know that there are people who do use them, though.
In that sense, the display portion of the view is already separated. Now, in the actual storage of the view object, there are still a few areas that need further separation, and that is what I plan to do. I don't know that I'll make it multiple modules; but with Drupal 6's design that also won't be necessary, as it will be much easier to create load-on-demand include files.