[development] How could everyone win and get Views in Drupal 8?

Jamie Holly hovercrafter at earthlink.net
Wed Aug 12 17:16:09 UTC 2009


Sorry - I should have expanded more on what I meant. What I think would 
work out good is having the actual storage and execution of views 
handled by the core. Then the GUI to edit/create views could be offered 
as a contrib module. Storing things like "blog" as just a view would be 
a great step forward in flexibility IMHO. If someone doesn't like how 
the "blog" displays, then they could download the contrib "views-gui" 
and alter that view.

My thinking is more or less in future upgrades. For example - D8 has 
this built in, then D9 comes out. People would still be able to use the 
views they built through the D8 views-gui, even if that contrib module 
isn't released by the time D9 comes out. There are countless sites that 
rely on views, but how often to they actually edit and/or create views? 
I know a few that I maintain views has been there, but once the view was 
created that was pretty much it. I have had no need to go back and edit 
that view.

I'm just spinning this off the top of my head and not entirley sure if 
its doable or not, but if it is I can see it having the benefit of a) 
having core able to process and utilize views while maintaining a more 
conservative code base and b) make maintaining views-contrib more easily 
maintained by having to focus mainly on the GUI.

Jamie Holly
http://www.intoxination.net 
http://www.hollyit.net



Earl Miles wrote:
> Jamie Holly wrote:
> > Yeah I agree we really need to keep Drupal lean. I wouldn't want to see 
> > the entire Views package integrated as-is. I wouldn't mind some of the 
> > functionality included 
>
> This one drives me crazy. There really isn't a 'some'. There is no Views 
> lite. Stripping out functionality does not make Views lighter, it just 
> makes it less useful, and that is ultimately harmful. The reason Views 
> is useful is because it is flexible.
>
> The reason it seems like it is 'heavy' is because it's defining handlers 
> to deal with a couple dozen core tables, hundreds of core fields, half a 
> dozen different styles (table, unformatted, node view, rss, etc). It is 
> replacing a LOT of core functionality. When it goes into core, a lot of 
> core code just gets thrown away.
>
> Anyway, people who have this attitude are really saying they don't want 
> Views in core. That's fine, but what that really means is that core 
> doesn't get the benefit of Views functionality. It degrades the overall 
> user experience and it creates a lot of dead code in core that mostly is 
> never used because 90% (or more) of the people using Drupal install 
> Views anyway. (Right now, statistically, views is on 60% of all 
> reporting Drupal sites).
>
> Also, one day I may not be able to maintain Views. I don't want to sound 
> like an asshole...but I am an asshole. Every one who doesn't want Views 
> in core had better consider the day that I move on from my current 
> position, and am no longer able to maintain Views more or less full time 
> on someone else's dime. If it's not in core, it could just become 
> another unmaintained contrib module. Core is maintained by a large 
> community. Views is maintained 95% by me and 5% by a handfull of other 
> people who've gotten into it enough to understand it.
>
> But also, and this is the real reason: Core would be *better* with Views 
> in it. Views in core is actually part of the #smallcore ideal, IMO, 
> because it lets us do a better job of reducing core to APIs and building 
> the Application on top of it, rather than core being half framework and 
> half application, like it is now.
>
>
>   


More information about the development mailing list