Posted by Merlin on Sat Jul 14, 2007 2:59 pm.
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.
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
This makes explaining views features easy
I've been telling people who ask me questions about views (or panels) that version 2 will do (or does) that. Whatever they ask. ;-)
Wow.
As someone who (apparently) when given the earth, sun, moon, stars and solar system, immediately asks about the universe... I'm wondering about exposing CiviCRM to Views...
But if I may just go back to the Panels 2 alpha and the proposed Views 2 and reiterate:
Wow.
Filters as a seperate entity
One thing that bugs me in the use of views module in other modules (specifically node reference) - is that there is an option to choose a view for a choice of nodes.
Clearly what is needed there is an option to choose a filer - only filter is not an entity that exists on it's own only as part of a view.
It seems like views 2 advance the breaking of this complex entity view to several other entities:
Output, nameable Filters. And a view is a combination of those elements.
Will it be exposed to other modules as well?
Will there be an option in different modules to show filters dropdown and recieve the resulting list of the nodes from the selected filter?
hed
Hi Earl, Any time estimate
Hi Earl,
Any time estimate on this new goodies?
Cheers,
Amitai
Not really. I have hopes but
Not really. I have hopes but I don't know that I can meet them. =)
Upgrade path
So what will this mean for drupal 5.1 sites running views 1.x? Will views have to be recreated from scratch?
I should hope not! I suspect
I should hope not! I suspect the upgrade path will require tweaks to make sure everything continues to work right, but it should be able to upgrade as part of the Drupal 5 --> Drupal 6 process.
Two suggestions for Views 2
Your to-do list sounds daunting and impressive, indeed, and I look forward to the results. :-) I have some suggestions:
1. Views is two things: a query builder and a query-results display engine. Perhaps it should be split up into two modules: Queries and Views. Views could then display lists from anywhere. Mostly this should just be function renaming (I think :-).
2. No matter how good the query builder gets, sometimes you just want to write your own query. In these cases, I find myself repeating the pattern:
<?php
function my_query_menu($may_cache) {
$items = array();
if ($may_cache) {
$items[] = array(
'path' => 'my_query',
'title' => t('My page'),
'access' => TRUE,
'type' => MENU_CALLBACK,
'callback' => 'my_query_page');
}
return $items;
}
function my_query_page() {
$res = pager_query('SELECT ... my query ...', 10);
return theme('my_query_page', $res);
}
function theme_my_query_page($res) {
$items = array();
while ($r = db_fetch_array($res)) {
$items[] = ...;
}
$out .= theme('item_list', $items);
return $out;
}
?>
Instead, the Queries module could let me just enter the SQL query directly, and then I could create a View for that Query that could give me a block, page, RSS, whatever. All the above code would go away.
2. Use table-joining information from the schema structure instead of hook_views_tables() so modules only have to declare their schema once. Additional views info can also be stored in the schema structure without harm. I'm guessing you are planning to do this anyway.
It would be kind of nice to
It would be kind of nice to be able to plug Queries into Views' presentation layer. So long as they return the right information, I can see where that ought to work.
When I looked through schema, it looked like it was containing table definitions, but it really doesn't contain data the way Views needs to think about it. Views' joining is a path algorithm, not a generic relationship model. It wants to be able to find the path from the table you're referencing to the base table. I didn't see where schema was really providing that kind of information.
And as it turns out, Views could care less about the field definitions. It wants to know things like how to display the field data, whether or not it's sortable and how to attach filters to the data.
I'm often being told that the schema definition stuff is good for Views; but I haven't seen it yet.
views2?? :)
http://drupal.org/project/dataview
Post new comment