Last updated by merlinofchaos on Sun, 2008-03-16 01:59
In order to get a birds eye view of the current state of the Views 2 user interface, the needs of the UI and the decisions made so far are summed up below.
(Please refer to http://groups.drupal.org/node/8429 for ongoing discussions. This is a wiki so please feel free to help keep this up-to-date with the latest progress, or fill in any details that have been missed so far. Please only post solid information here; conversation should go in the sister thread. Thanks.)
The beginnings of the favourite idea so far:
Response by couzinhub
New in Views 2
Things that the new UI must account for:
- We are no longer limited to just one page and one block; there are now 'displays', and you can have 1 or more of them. Displays might be called output types or something by the end. I don't know.
- A view has a 'base table' (we're calling this the view type, now). This is the table you're doing queries on, essentially. It can be things like node, user, taxonomy, comment, etc. It is set during creation and cannot be changed thereafter.
- joachim: careful though: 'view type' in Views 1 meant list/table/teasers/other, so reusing that term with a new meaning will confuse people
- Each display can have its own fields. It's possible that each display can also have its own arguments, sort criteria and filters as well, but this hasn't been fully decided.
- Each display has a style plugin. That style plugin may have an additional row plugin, if the style plugin supports it. Each of these items can have its own settings form that is unique to that plugin. This is one of the most challenging pieces of the UI because you have several dependencies to get to unique forms.
- In Views 2 the view name can't be changed once set.
- moshe: seems a bit lame. fundamental objects in core like content type allow name change, and provide a hook so that modules can react and avoid breakage.
- There will be a new thing called relationships, which is the kind of thing that will let you view fields from related nodes. Example: I am looking at a view of albums. THe album has a nodereference to artist. This node reference defines a relationship; by activating that relationship, I can then view fields from the album OR the artist.
Hierarchy in Views 2 -- http://www.yoroy.com/elders/drupal/Views-sitemap.png
var_export of views object -- http://groups.drupal.org/node/6288#comment-25590
Display plugin (the actual name of this is flexible. "Output type" can work too. I'm not married to a term here, at least in the UI. In code it is 'display', though): This tells you where it will be displayed.
The display has more to do with where the output goes than what the output is. Think of it as the portal: The 'page' display type means that it has a URL and menu possibilities. Whereas a block doesn't have any of that, but it has an interface to the block mechanism.
This tells you how the overall list will be styled. By default we have 'default' (need a better name. Unstyled, maybe?), 'list' and 'table'.
- moshe: Unstyled sounds good
- catch: note that 'list' is now decoupled from the specific list format, whether that means an unordered list, teasers, or something else will now be handled by the row plugin.
This tells how each item in the list will be styled. Not applicable to each style plugin; and may be dependent up on the base table (view type). Available options: Fields, node view (can be teasers/full), profile view, etc. Not all tables will have any options other than fields.
Views in a sentence
What do you want to display? Where do you want it displayed? How do you want the list formatted? How do you want each item styled?
What, Where and How.
What = basetable: node, users, taxonomy
Where = as a page, a block or something defined by another module
How = Unformatted or List or Table. Then narrow it down to item level: teaser, full post or handpicked set of fields.
As of 02/17/08: http://views2.logrus.com/views-ui4.png -- vertical tabs work. Most of the basic pieces on a view can be edited; the default display/override for this display stuff works. fields/sorts/filters/arguments can be added and have their settings edited. Still can't arrange, and arguments need some extra work on settings since they have style plugins. Still have a few more settings to do, such as path for page and pager settings.