The "Views in Core" page in the new Community Initiatives sector on drupal.org states that
it seems like the best thing to do is get "all or nothing" of Views in core.
I am interested in how the intregation of the current (Drupal 6) Views and core will happen. I'm rather sure the core committers will not just move the views folder from contrib into the the core cvs repository, even though that would probably be the least time consuming. Therefore a few questions arise:
-
What about the UI? In comparison to Views 1 it's great. In comparison to all other Drupal core UI, it's not, well, Drupal-ly. What's the plan? Is there thought about "inventing" a completely new UI or will the current one be reduced/altered?
-
What about things like admin/content/node or admin/content/comment? Those are Views. Well, they aren't produced by the Views module, but they could be. So, will they? If I am not simply too high on the mere thought of Views in core it would reduce the need for a lot of custom-core-interface-code and could establish a real consistency in these core forms (and be used for contrib interfaces as well!).
EDIT: NOTE THAT THE PAGE LINKED ABOVE HAS BEEN UNPUBLISHED (probably because no one was actively working on this issue). THEREFORE YOU WILL GET A "Access denied" PAGE WHEN CLICKING THE LINK ABOVE.
Comments
Once Views is ready for
Once Views is ready for core, you can bet that lots of core will be refactored to use it wherever it makes sense.
If the UI is redesigned again, I probably won't be the one doing it. =)
If Views were brought into
If Views were brought into core for D7, the D7 version would have to be ready to ship right as D7 itself is. But I imagine the code will require a boatload of refactoring in order to be compatible with DB:TNG. Am I wrong?
If Views is going to be brought into core, we should find that out sooner rather than later, so that job can get started…
The Boise Drupal Guy!
The views in core page has a
The views in core page has a nice list of places where people can help. We need people who are not me to work on the porting. webchick specificly does not want me to be the only person who understands this code when it goes into core.
???Roadmap???
So guessing from your comments: the (meta-meta-meta-)task list would be:
Make Drupal core "ready" for Views (Form improvements, etc. see the Community Initiatives page)
Port Views API to Drupal 7 (DBTNG, ...) [Probably the biggest part]
Implement the ported Views API in core, with a few examples (e.g. admin/node/content)
Think about and subsequently implement a (/the) Views UI
Make everything in Drupal core a View =).
Or not?!?!?!?
Make everything in Drupal
Ehhhhhhh… This will only work if Views is made a non-optional core module. I'm not saying that's a bad idea, but it is a major step which I think deserves a lot of debate before it's gone ahead with. Occasionally there are still sites I make for which I do not use Views either because it's unnecessary or because I need the speed and/or flexibility (from a programmer's standpoint) of custom-written queries.
The Boise Drupal Guy!
Views UI
Personally, I like the Views 2 UI a lot. I think it's very elegant and, once you get the hang of it, highly intuitive. I've recently used the display specific options a lot and for building views plug-ins it's a dream come true. Merlin did a great job as always.
That said, I guess I can see tstoeckler's point that it is sort of a different paradigm compared to most of core (probably because it does something unlike anything else in core). What if we integrated some kind of 'Views Light' interface in addition to the Views 2 UI so that beginners could get started without totally figuring out the views 2 UI? The SimpleViews plugin that Eaton put together looks a bit more like other things in core and is easier for beginners to groc (albeit a bit less powerful). Maybe we could use that as a jumping off point?
Thoughts?
Yes and no
If you read the Community Initiatives page on Views in Core SimpleViews is mentioned as an option, but several drawbacks are pointed out, that are quite valid, in my opinion.
The most important to my mind is, that due to the limitations of the customization options in SimpleViews, SimpleViews uses the regular Views UI as a fallback. This would not be possible with SimpleViews in Core, so I'm not sure how you could do that.
The point you make, though, is quite right I think: The Views UI looks like nothing else, because it does something, nothing else does.
I personally think the Views UI would "fit" in core, if it was simplified a little: not in functionality, but in, I guess, developer-orientedness. For instance, the query information at the bottom, could be cut out, and the clear separation of settings and preview could somehow be integrated in one another to prevent from the continuous scrolling. Just some random thoughts, though...
I would like to integrate
I would like to integrate more of the Views UI concepts into the Drupal administration system so that it's considered normal.
Also note that a good UI for
Also note that a good UI for D7 fields, be it in core or in contrib, will require some of the UI tools we know from Views 2.
This was true in D6, and will be even more with D7 fields, that have more settings (field settings, instance settings, widget settings, and the long-awaited formatter settings).
The most needed part is the degradable AHAH subforms, saving to a temporary object that only gets actually created or updated at the end of the process. Which, if I'm not mistaken, has been / is being abstracted out in the ctools module ?.
More or less, though it
More or less, though it probably needs to be reconciled with ahah.js
That said, there's a form patch waiting to go in (http://drupal.org/node/322344) (right now it's just waiting on a documentation reroll), I have a couple more I need to work on that follow that form patch, and then we really want to see:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/ctools/incl...
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/ctools/js/a...
And probably this:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/ctools/incl...
And definitely this:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/ctools/incl...
'simple' and 'advanced' tabs?
Can we say something like 'all of the above'? Integrating Views UI concepts into D7 throughout core is undoubtedly a good idea. IMHO the AJAX/AHAH stuff in the latest panels and views 2 UI are very slick and similar things could mean real advancements for usability in Drupal core. Also, making Drupal more Views-y solves the problem of Views UI not being Drupal-y enough.
Why can't we have something like SimpleViews AND something like Views UI? Maybe a 'simple' and 'advanced' tab?
The downside, as pointed out in Community Initiatives page on Views in Core, is the bloat. Views is big and would make Drupal much bigger on a percentage basis. The thing is, though, virtually every website using Drupal installs cck + views. We want to make this available but also want to make Drupal core easily accessible to new users and less developer centric. I think a 'simple' and 'advanced' tab interface is a way to get the best of both worlds. SimpleViews itself is relatively small, we just need a way to integrate them.
While your simple and
While your simple and advanced tabs might be a good idea in general, it would mean reworking both interfaces (Views / SimpleViews) to actually simple and advanced resemblances of each other.
With the developing Form Builder by quicksketch heading for core, maybe something similar could be a views concept: You simply drag the display elements (aka fields) to where you want. How that would allow the advanced configuration of the current Views UI, I don't know. But it would be killer for new users. We have to keep in mind users for whom Drupal 7 will be the first Drupal or even the first CMS ever. They don't know what a "Relationship" or an "Argument" or a "View" is...
I agree that we'd want
I agree that we'd want simple and advanced versions to be somewhat similar and we would want to make both as friendly to non-developer/newbie types but it's not like you can just make up a new word for "relationship" or "argument" and it'll be instantly intuitive. The drag-and-drop fields idea is a cool idea, but I'm not sure drag-and-drop solves the problem you raised earlier. How do you make arguments easier to understand through drag-and-drop?
I think we need to either find a better way of providing contextual help (further extending advanced help, maybe add something like beauty tips, etc) or we need to just embrace that the Advanced tab is for advanced users. You will always need some specific vocabulary to perform advanced functions.
Have integrated video tutorials ever been suggested? They wouldn't, of course, come packaged with the Drupal core but perhaps loaded from D.O. Live help if you will (and optionally downloadable). Maybe if you could click a video help button and then click an interface element and to called up quick thickbox tutorials that explain and show what an argument is and how to use it in 30 seconds. Kind of like Apple's video tutorials for iLife.
You could add a switch to disable them during install for advanced users. Definitely half baked but is it worth considering?
Help, help, help
Yes, the contextual help needs to be improved definitely, there's no way around that with something like Views in Core. Buth then, I'm quite positive it will be.
This issue for example adds something like advanced help in core, which is pretty cool.
Proper Views Integration
If we are going to have views integrated properly with Drupal 7 then I think that you should look at integrating or streamlining the process modules designers go through in order to integrate views with the new data contained in the modules.
At the moment, a module designer who creates a new database table creates an .install file which contains code which describes the new data similar to the following extract from the node_example demonstration module on http://api.drupal.org :
<?php/**
* Implementation of hook_schema().
*/
function node_example_schema() {
$schema['node_example'] = array(
'fields' => array(
'vid' => array('type' => 'int',
'unsigned' => TRUE,
'not null' => TRUE,
'default' => 0),
'nid' => array('type' => 'int',
'unsigned' => TRUE,
'not null' => TRUE,
'default' => 0),
'color' => array('type' => 'varchar',
'length' => 255,
'not null' => TRUE,
'default' => ''),
'quantity' => array('type' => 'int',
'unsigned' => TRUE,
'not null' => TRUE,
'default' => 0),
),
'primary key' => array('vid', 'nid'),
);
return $schema;
}
?>
After completing the working module in Drupal, they then need to create a .views.inc file to describe the same fields to Views. For the above last two fields (color and quantity) the following extract shows its description to Views in the node_example.views.inc file:
<?php// Color
$data['node_example']['color'] = array(
'title' => t('Color'),
'help' => t('Color of item.'),
'field' => array(
'handler' => 'views_handler_field',
'click sortable' => TRUE,),
'filter' => array(
'handler' => 'views_handler_filter_string',),
'argument' => array(
'handler' => 'views_handler_argument_string',),
'sort' => array(
'handler' => 'views_handler_sort', ),
);
// quantity
$data['node_example']['quantity'] = array(
'title' => t('Quantity'),
'help' => t('Quantity of items.'),
'field' => array(
'handler' => 'views_handler_field_numeric',
'click sortable' => TRUE,),
'filter' => array(
'handler' => 'views_handler_filter_numeric',),
'sort' => array(
'handler' => 'views_handler_sort',),
);
?>
Following this the module designer needs to add an extra function to their .module file which looks like the following:
<?php/**
* Implementation of hook_views_api().
* This function tells views that a mymodule_views.inc file exists
* with data/program for the views module
*/
function node_example_views_api() {
return array('api' => 2.0);
}
?>
There appears to be some overlap in the fact that two different files describe the data. Are the following integration changes possible, likely or sensible?
A) Hook_schema() to be replaced by Hook_views_data() (or vice versa) so that we only have to describe the data once and both schema and views knows about it.
B) Get rid of .views.inc and place all this information in the .install file so that we are describing data to Drupal in one place.
C) Get rid of the node_example_views_api() function requirement.
Along with any other streamlining that can make this integration easier. With views being part of Drupal than users should be able to assume that they can use views on all data including that created by contributed modules.
If views is integrated as part of Drupal 7 then the Drupal 6 to Drupal 7 upgrade instructions for module designers is going to have to include full instructions for integrating module data with views.
Hope this is helpful
Ken
http://AusValue.com
All of the above...
I guess if we put Views in Core, we get all of that for free. Currently, as you said, you have to output your data to Views and Core, but if Views is Core, then the two fall into one simply as a matter of principle. Now of course, that will take quite some changes (maybe those you suggest) to implement, but there is no way around that really if we put Views in Core.
Probably obvious, but it
Probably obvious, but it seems to me the way to do it would be to drop hook views data and drop hook_views_api and integrate some kind of flag in the install schema. There is some data you wouldn't want in views and additional things you need to specify for any that are. Maybe something like this:
<?php/**
* Implementation of hook_schema().
*/
function node_example_schema() {
$schema['node_example'] = array(
'fields' => array(
'vid' => array(
'type' => 'int',
'unsigned' => TRUE,
'not null' => TRUE,
'default' => 0,
),
'nid' => array(
'type' => 'int',
'unsigned' => TRUE,
'not null' => TRUE,
'default' => 0
),
'color' => array(
'type' => 'varchar',
'length' => 255,
'not null' => TRUE,
'default' => ''
'views' => array(
'title' => t('Color'),
'help' => t('Color of item.'),
'field' => array(
'handler' => 'views_handler_field',
'click sortable' => TRUE,
),
'filter' => array(
'handler' => 'views_handler_filter_string',),
'argument' => array(
'handler' => 'views_handler_argument_string',),
'sort' => array(
'handler' => 'views_handler_sort',
),
),
),
'quantity' => array(
'type' => 'int',
'unsigned' => TRUE,
'not null' => TRUE,
'default' => 0,
'views' => array(
'title' => t('Quantity'),
'help' => t('Quantity of items.'),
'field' => array(
'handler' => 'views_handler_field_numeric',
'click sortable' => TRUE,),
'filter' => array(
'handler' => 'views_handler_filter_numeric',),
'sort' => array(
'handler' => 'views_handler_sort',),
)
),
),
'primary key' => array('vid', 'nid'),
);
return $schema;
}
?>
We could probably slim it further by having inteligent defaults. In this case the schema already knows we're adding a varchar for color and an int for quantity so it could reasonably default to the string handlers and numeric handlers for each datatype. That would make a lot of the code below optional and, in this case, unnecessary.
Please note that there is a
Please note that there is a risk here: mysql can only send so much data in a single packet, so anything we cache can only be so large. When you put all the data about the database together like this, we run the risk of blowing out that limit. Views 1 already has problems with this, though Views 2 is a lot better.
Schema API will also need to support aliasing in order for this to work.
While I am no developer,
While I am no developer, what about something like this:
The idea is what "Views" is going to replace. In order for "views" to even be able to make it into "core" we need to remove old functionality that can be duplicated via "views". Otherwise we are just adding more code without stripping "core" of it's redundant code.
The UI is where I am not sure what to do. Since I use Views in practically all my sites, adding the UI makes sense, but that may not work for everyone. I do like the idea of creating a "basic" and "advanced" option.
No Views UI in core
In my opinion, we should only implement Views core (API) in drupal core (7.x or 8.x) and leave views UI as an optional module.
this should enable the usage of (pre-created) views by (core)modules, while still keeping the codebase as minimum as reqiured.
This will never happen. I
This will never happen. I will not maintain the UI separately from core. Anyone who thinks that it's a remotely good idea is on crack. And I'm getting more and more upset at people telling me what to do with my code as if they have authority over it.
But frankly given the attitudes I'm seeing lately, the chances of Views in core are pretty close to zero.
Could you elaborate?
Why would having the UI outside of core be such a crazy idea? So many modules depend on views (or should depend on Views) that it makes sense to have the functionality be part of Drupal core. It also makes a lot of sense for parts of Drupal core to become views themselves. However, the Views UI is such a departure from the rest of Drupal that I don't see it going into core.
Please don't this response as flame-bait. Ultimately Views is your module and others can't tell you where it should do. If you've explained this stance elsewhere please post a link.
1) The UI and the system are
1) The UI and the system are actually intertwined. Let's take a look at exposed filters, for example. They are part of the UI, but you aren't necessarily using them in the UI.
2) Each handler contains its own UI. Separating this out means that now you have the handler in core, the UI for that handler not in core, and a very tenuous link between the two. This ends up being harder on the developer, who now has to create the UI for a handler separately from the handler. And exposed filters? Hm.
3) Bugs in the 'UI' are often actually bugs in the core. Or at the very least, it can be very ambiguous to a user where these bugs are. What issue queue do they file them in. In particular, users won't even see most of these bugs without the UI. The Views issue queue is already a nightmare. This has the potential to make it much worse.
4) This is the real killer: I won't have 60% of the code taken away from me. "Controlling" a UI that works for code I no longer control is not interesting. But, and with absolutely no apparent thought given to the maintainer of the project, if the UI is separate from core, someone still has to maintain it. It's assumed that someone will be me. That assumption is wrong. It will not. Under no circumstances will I maintain a UI separate from Views. I work on projects because I want to or because my employer pays me to do them, and no other reason. Neither of those things will be true about a separate Views UI.
One additional thought: If
One additional thought:
If it comes down to it and this ends up being the sticking point, i.e, "No Views UI in core, period," I'm ok with "No Views in core." I'm not the force behind this, and while I think Views in core is overall a good idea, it's a monumental amount of work and I don't see anyone stepping up to bat to do the job.
And honestly, writing for Drupal core is not a pleasant experience if there is any kind of disagreement involved, and Views-in-core has been nothing but a series of disagreements from the day Views was released. The nature of them has changed but the fact remains, good work is easily spoiled by community debate.
Thanks for the reply.
Thank you for the honest response. Your reasoning is sound and I understand where you are coming from. Ultimately I do still hope that part (all?) of Views or something similar makes into core. Even if it lives in contrib, Views is core to the majority of Drupal users and any release without it is essentially dead on arrival. This shouldn't be just your responsibility (you actually don't "have" to do anything) and is an unfair expectation of a single developer.
Thanks, also
I, too, want to thank you for you elaboration.
I would have completely supported the arguments that were made in this thread about seperating API and UI, because the arguments that were brought simply made sense. I had no clue and actually never thought about the things you said in that way, and now that you did, I completely understand your position and it seems inevitably clear now.
I'm sure this post will clear things up for a lot of other people like me, that don't get these things that are probably obvious to anyone working more extensively with Views, and hence, make this discussion less a discussion and more a place to bundle efforts around this topic (?!).
Again, thanks.
I suppose I need to take a
I suppose I need to take a deep breath on this one and remember that some things -- particularly the side effects that will affect me directly -- aren't obvious to a lot of the people debating this issue.
I can see where the argument about the UI needing to be separate makes some sense, when you eliminate the "who maintains it" aspect of the argument. I counter that some of the UI elements introduced for Views 2 are really useful and I would like to see the Drupal administration paradigm embrace them. In particular:
1) Cache objects while they're being modified so that we can have previews and locks.
2) Use degradable AJAX to make forms more bite-sized and provide the ability to get a big picture overview and drill down easily to get greater details.
Now, there are a few other ways we can approach some of these things, and the vertical tabs aren't the only way. However, if you've seen the vertical tabs module that reworks the node page to eliminate the collapsible fieldsets and instead separates the form via vertical tabs, it's a fantastic improvement and suddenly brings us closer to the Views 2 UI paradigm.
After working with this for several months now, I have grown to really like it. We still need to figure out better ways to ease users into it, but I have large amounts of feedback to suggest that once a user breaks through a certain level of understanding, the UI becomes very, very good, because it does a good job of staying out of your way while accomplishing tasks.
Ah yes...
Ah yes, now I remember the wonders of egos coming out to play on ALL SIDES. Are we having fun yet?
Yes, that's right. Being
Yes, that's right. Being forced to do something I do not want to do and being loud about it is 'ego'.
The way I see it, the whole
The way I see it, the whole point of Views in Core is to make Drupal easier to customize and to try and simplify the job of presenting core information from Drupal in different ways. As a secondary benefit to me as a website developer, it would also cut down on a lot of duplication of code which exists between different core modules which all have to go through the steps of querying the database, analyzing the information they've retrieved and presenting the information in a usable format for the end user. Using Views here I'm sure would greatly simplify this task.
That being said, the UI is crucial to being able to easily make modifications to these views. As a simple example, the admin/content/node page and the admin/user/user page both suffer from a bug which makes them unusable on sites where either nodes or users are imported in batches. The default sort order is by timestamp, which isn't necessarily unique. Add the Views UI and a developer can fix this problem easily by adding an ORDER BY to the query.
I'm with merlinofchaos on this one 100%, the two modules go together like ham and cheese or peanut butter and honey.
Dave
The other trade off people
The other trade off people need to remember, is that if views goes into core in D7 that means it is frozen solid for the 1-2 years it takes for Drupal 8 to come out.
Access denied page ...
Can't access the page referred to as "Views in Core" page and Community Initiatives page on Views in Core - both lead to "Access denied" page. Does anyone know why? Maybe it's for a specific group of people?
Unpublished
They are both unpublished. I believe it's because they were out of date and misleading.
Michelle
See my Drupal articles and tutorials or come check out the Coulee Region
I edited the original post
I edited the original post to warn people.
We need to fix this!
We need to fix this!
Update on Views in Core
Actually, I'm looking for any current info on getting Views in core but it seems as if the question of "some", "all" or "nothing" (of the current views module) is far from near resolution. Any news (even from the grapevine) of a basic views module from a different source than the current one? Thanks in advance for any pointers.
Brief update from merlinofchaos
I just pinged Earl in IRC, and this thread seems to be the most recent updates since he hasn't had time to write up a more formal roadmap yet.
I did get a chance to interview him at DC for Drupal Voices, and he had some new things to add to what needs to happen. His answer is at about 7:30 at:
http://www.lullabot.com/drupal-voices/drupal-voices-29-earl-miles-panels...