I am going to intensively use the chapter 5 of the Anti Pattern book on the Golden Hammer because it is exactly what views is. Putting it in core would be in my opinion a big mistake. I will explain first what is the problems of this anti pattern, and why the "in core" wont magically solves all the code and management issues whereas the general solution should be: expand your horizons.
Background
The golden hammer is one of the most common AntiPatterns in the industry. Frequently, a vendor will advocate using its growing product suite as a solution to most of the needs of an organization. Given the initial expense of adopting a specific solution, such it also provides extensions to the technology that are proven to work well with its deployed products at greatly reduced prices.
General Form
A software development team has gained a high level of competence in a particular solution or vendor product (they written/bought books, and are possibly part of the committers), referred to here as the Golden Hammer. As a result, every new product or development effort is viewed as something that is best solved with it (see "Panels everywhere", "Views Form", "Views if empty", ...). In many cases, the Golden Hammer is a mismatch for the problem, but minimal effort is devoted to exploring alternative solutions.
This AntiPattern results in the misapplication of a favored tool or concept. Developers and managers are confortable with an existing approach and unwilling to learn and apply one that is better suited. This is typified by the common "our database is our architecture" mind-set. Golden Hammer advocates will argue that future extensions to the technology, which are designed to work with their existing products, will minimize risk and cost. But in practise, the maintenance of a panels-views driven website, is almost impossible, and leads to huge maintenance costs.
Symptoms and consequences
- Identical tools and products are used for wide array of conceptually diverse products.
- Solutions have inferior performance, scalability, and so on when compared to other solutions in the industry.
- System architecture is best described by a particular product, application suit, or vendor tool set.
- Developers debate system requirements with system analysts and end users, frequently advocating requirements that are easily accommodated by a particular tool and steering them away from areas where the adopted tool is insufficient.
- Developers become isolate from the industry. They demonstrate a lack of knowledge and experience with alternative approaches.
- Requirements are not fully met, in an attempt to leverage existing investment.
- Existing products dictate design and system architecture.
The views module have an open list of 700 known bugs. Even the views bug squad, composed of 18 hard working developers does not succeed to reduce the growing known bug base. Moving it and its dependencies (ctools) to core will add 700 known bug to the drupal core, without any real maintenance solution to manage the bug base.
Typical causes
- Several successes have used a particular approach.
- Large investment has been made in training and/or gaining experience in a product or technology.
- Group is isolated from industry, other companies.
Views is a formidable approach for RAD (Rapid Application Development), but it should remain as-it. Sites that widely uses views for everything often experience huge performance impact leading to maintenance costs overwhelming initial costs of using a well-known product where investment is minimal.
Refactored solution
This solution involves a philosophical aspect as well as a change in the development process. Philosophically, the views team needs to develop a commitment to an exploration of new technologies. Without such a commitment, the lurking danger of overreliance on the views tool set exists. This solution requires a two-pronged approach: A greater commitment by management in the professional development of their developers, along with a development strategy that requires explicit software boundaries to enable technology migration.
The roadmap plans to first port the module to "ensure nothing break" then work on a different architecture. My vision is that once it will be ported, no one will want to refactor the product because its "just work" and will involve too much resources (the length of the bug base speaks for itself).
Software systems need to be designed and developed with well-defined boundaries that facilitate the replaceability of individual software components. In addition, software developers need to be up to date on technology trends, both within the organization's domain and in the software industry at large. On the management side, another useful step is to adopt a commitment to open systems and architectures. Without it, developers often acquire the attitude that achieving short-term results by any means necessary is acceptable. Though this may be desirable in the short term, future results become problematic because rather than building upon a solid foundation of past successes, effort is expended reworking past software to conform to new challenges.
Flexible, reusable code requires an investment in its initial development, otherwise long-term benefits will not be achieved [Jacobson 97].
Another management-level way of eliminating or avoiding the Golden Hammer AntiPattern is to encourage the hiring of people from different areas and from different backgrounds. Teams benefit from having a broader experience base to draw upon in developing solutions. Hiring a database team whose members all have experience in using the same database product greatly limits the likely solution space, in comparison to a similar team whose experience encompasses a wide range of database technology solutions.
Finally, management must actively invest in the professional development of software developers, as well as reward developers who take initiative in improving their own work.
Variations
A common variation of Golden Hammer occurs when a developer uses a favorite software concept obsessively. For example, some developers learn one or two of the GoF patterns [Gamma 94] and apply them to all phases of software analysis, design, and implementation. Discussions about intent or purpose are insufficient to sway them from recognizing the applicability of the design pattern's structure and force-fitting its use throughout the entire development process. Education and mentoring is required to help people become aware of other available approaches to software system constructions.
I have seen some website containing more than 50 views, some pages loading up to 10 views at the same time, all related together, and conceived by a "pro drupal" company. The "small" changes asked by my client was almost impossible to implements. Either I had to refactor the whole solution (couldn't count the hours to do that) either I had to hack to add another layer of "quick fixes".
Views has becomed a Lava Flow over the course of several years and many projects. Typically, older sections based on earlier versions of the Golden Hammer are delegated to remote, seldom-used part of the overall application. Developers become reluctant to modify these sections, which build up over time and add to the overall size of the application while implementing functions that are seldom, if ever, used by the customer.
Project manager will recognize, you can add many resources as you want, if a project can't complete, reduce scope. Not reducing Views scope but porting it to core, then refactor, will not work. And I even wonder if someone one day will had the time to refactor or build with a bottom-up approach. That's why I am afraid of this initiative.
So what to do ?
Some developers said that rebuilding from scratch would be a big mistake. They are right. I set a discussion about the proposition of re-architecturing the View object http://groups.drupal.org/node/249958. Proceeding steps by steps with a defined plan is the path forward.
Comments
Applause!
Applause!
Julien Didelet
Founder
Weblaa.com
Truth & Accepted
Truth & Accepted
Dinesh Kumar B.E
My site
If you don't like views for
If you don't like views for everything, great, you can use it when appropriate or you can disable the module or whatever. But can you claim that views will be enabled on fewer sites than the aggregator or the block module? No, you can't claim that.
I find your post to be low quality, drama-bate and don't appreciate it. It doesn't look at pros/cons of specific ideas, it just complains about the misuse of Views and uses that as a basis for not including Views in core. You spent a lot of words but didn't build a complete argument.
knaddison blog | Morris Animal Foundation
When we started to build
When we started to build https://www.duedil.com, I first used Views as a formidable tool to have a working proof-of-concept. That's the pros.
When we started real development, it apperead that we had no/few control over SQL, and the workflow was incompatible with our git versioning system. It was really difficult to add a views under version control. When we experienced out that we were spending more time on trying to find a good workflow than developping the software itself, we finally dropped the use of the Views module. That's the cons.
But my experience was not a basis to complains about the misuse of Views. Its more profound than that and I explain that its more a political/management issue. If you find my post is low quality, its fine, I was just expressing myself about Views in Core. Are you yourself a maintainer ? Are you enjoying debugging Views ? I am not a big fan of spaggetti code.
Drupal is being refocused on build upon quality-standards with Symfony2 and re-architecturing concerns. In my opinion the whole movement does not need more chaos in the project but a completely new bottom-up approach. You can read more on the movement here: http://www.unleashedmind.com/en/blog/sun/drupal-8-the-path-forward.
The roadmap is not about re-think the design, it is about port to drupal first, then see what happen. This is the main motivation of my post.
http://angrydonuts.com/help-fund-views-in-core
This is the same team, which are already 18, and cannot manage to reduce the growing known bug base, not because of themselves, but because of the software itself. And that's a fact whether you like it or not. Giving it to the drupal core maintainer team will not save them either.
How can you find pros to an AntiPattern ? While I understand you are proud of the "Non invented here" principles, the core is trying to move to a newer concept which is "Proudly Found Elsewhere". I am quoting from http://groups.drupal.org/node/19097. There among others.
As you can see I am just getting real examples to match an AntiPattern that teams before us has encountered. That is wide recognized, and have solutions; that I presented. I am just warning that from these people experience, its a danger to accept Views in core even with PSR-0 standard: it need ground-up refactoring, and its not, as you pretend, personnal.
Hope this make more sense.
When we started real
So what you're saying is that Views is an "antipattern" because 1) you could not write your own SQL (which is what the module was designed to replace) and 2) you didn't know how to use Features/hook_views_default_views()?
With CMI, that's going to be even less of a "problem", because you can just version your config directory and be done with it.
--
Cameron Eagans
http://cweagans.net
No actually I converted 20
No actually I converted 20 gigs of financial and directorship data into a view understandable structure with hook_views_data: Almost 40 tables with foreign keys and co that I converted into a huge array for the sake of Views understand how to join my columns.
I remember having put this into a separate 3k+ loc file and spending two day of work. Not a good memory I have to admit :)
I'm not sure how that
I'm not sure how that addresses my comment. I have not been able to find any point at which your argument that Views is an antipattern is valid.
Views is used by almost every Drupal site that I build or work on. At this point, not using views is an antipattern and developers that go out and write their own SQL just for the sake of not using views are the bane of my existence.
--
Cameron Eagans
http://cweagans.net
I don't know how to enlighten
I don't know how to enlighten you, maybe:
Read the 2 first chapters of the views project page.
Adds to this a pinch of the echosystem of modules, and their attempt to solve everything.
Compare the time of a plain SQL with template files to a custom views with rows plugins to achieve the same amount of functionalities.
You'll have some ingredients to make a good antipattern candidate.
I am positively curious to look at what type of websites are best suited for Views, maybe you can show me some samples. Among a Nightclub website, a Restaurant website, and a Company review one (duedil), Views didn't fit for me. But has been a wonderful incubator. That's why it is good in contrib to design fast website, then on production and when the app is ready, removes it.
Compare the time of a plain
Performance does not necessarily imply that something is an antipattern though. Views works well because anybody that doesn't know SQL very well can still put a list of just about anything where they want on their Drupal site. If you have a reason for not using Views, then don't use Views. Otherwise, you should use Views.
The type of website does not matter. You should be looking at specific functionality instead. Generally, when I think "Man, I really want a list of stuff right here", Views is how it happens. If there's something that Views just can't quite do, hook_views_query_alter or EFQ is a great way to do it, but why would you complicate your life by writing custom, one-off bits of code when you have a huge library of contributed modules that all work reasonably well with views? That's just silly.
The bottom line is, whether you like it or not, Drupal is inextricably tied to Views already. Drupal 7 adoption didn't pick up until Views was ready. Same with Drupal 6. Since having a release of Views is so closely tied with the viability of a core release, we need to have it in core.
As with Field API, that is going to mean fairly significant changes to the code base, so if you have problems with it, now is the time to submit a patch: help with concrete problems, rather than simply claiming that views is somehow an antipattern when it's easily the most widely used contrib module in the Drupal community.
--
Cameron Eagans
http://cweagans.net
The type of website does not
So I start to wonder if you are trolling me because you just gave me the exact definition of the golden hammer pattern, in your own wordings.
Not sure what you mean. I say
Not sure what you mean. I say "I want a list of stuff so I'll use Views", and that means golden hammer? Sorry, but no. Views is designed to make lists of stuff. If there's a list of stuff that it can't make, either extend it or write EFQ.
While you're at it, why don't you pick on Field API? That's designed to store data, so obviously, storing data in Fields is using the golden hammer. Oh, and don't forget about Panels! Panels is designed to control layout and output in your Drupal site. Better not use it for that, or we'll be using the golden hammer.
Sorry, but your post just doesn't have any substance: you're criticizing the use of a module for things that it was intended to do. If you want to write everything yourself, then why are you using Drupal?
--
Cameron Eagans
http://cweagans.net
First you need some
First you need some background to understand my concerns: http://www.unleashedmind.com/en/blog/sun/the-drupal-crisis. In an attempt to resolve this conflict and to motivates drupal core committers, an unofficial issue has been made: http://drupal.org/node/1224666. This issue aims to well separate concerns and removes complexity.
Adding Views in core without a bottom-up approach is just counter productive to that initiative, that was demotivating core committers to keep the hard work. Do you understand the wording "without a bottom-up approach" ? Because its the key concept of our disagrement.
I will refer to the pounard post: http://groups.drupal.org/node/249068#comment-804368 which contains maybe more substancial materials that my posts which was already long enough to add more substance.
I'm aware of both of those
I'm aware of both of those posts. In fact, you might notice my multiple comments on 1224666, including #3. I also understand what "without a bottom-up approach" means, but I don't think you understand how core development works: when Field API happened, it was basically CCK, but pretty much re-architected and rewritten for core. The same will happen with Views. Given that, I'm not sure what the problem is.
And I think pounard is wrong, but I'll go reply to his comment separately at some point.
--
Cameron Eagans
http://cweagans.net
Field API is like hell too,
Field API is like hell too, but at least it has an API, which makes it quite clear to use. I honestly almost never use feature or the UI, I always create all my fields using it, it's so much clearer and powerfull.
Pierre.
I'd also like to note that
I'd also like to note that your philosophy of just writing your own code to take care of things encourages duplication of modules, which is a huge problem. For instance, you wrote oauth api (http://drupal.org/project/oauth_api) when there was already a comprehensive oauth api module available (http://drupal.org/project/oauth).
Why? Because "Some modules like Views, OAuth and so have so much code and dependencies to maintain that it takes time to port it to next Drupal platform." (from the project page).
I can't help thinking of http://xkcd.com/927/
--
Cameron Eagans
http://cweagans.net
Ok, you should again document
Ok, you should again document yourself before writing such thing in the drupal review application groups where there is an interesting discussion about module duplication: http://groups.drupal.org/node/149959 and more particularly this comment by jthorson: http://groups.drupal.org/node/149959#comment-497959.
Now that you attacking me personally, your behavior follows the pattern of a troll, and there's no benefit to engaging further discussion. So I won't.
I'm certainly not attacking
I'm certainly not attacking you personally. I'm simply saying that your mindset that including a module in core is wrong because you can just write your own code is flawed. You absolutely should use existing contributed modules when it makes sense, and when you need to put a list of stuff in a given location, Views usually makes sense. I don't know why you're arguing this.
Module duplication is okay sometimes (for instance, cck "duplicating" flexinode), but it's usually for the reason that the new module does things in a fundamentally different way that's better/faster/etc. Blatant duplication is not okay, as it increases the size of the pile of modules that new users have to dig through to find anything useful.
--
Cameron Eagans
http://cweagans.net
Writing your own code is
Writing your own code is straight and clear, especially when dealing with a specific business. Specific business ties very well with specific code. We all do this kind of things in the end. Writing 1,000 lines of code isn't what I call module duplication.
Pierre.
Using alter hook for business
Using alter hook for business code is the most dangerous thing to do. Each time I have to do maintainance over someone else's code, I often end up in removing everything and rewriting it. Debugging and maintaining a business feature including some Views is hell. When you reach plain business code using a clear API, you don't experience this problem because the entire algorithm is written from top to bottom, in one single file, in front of you. Even if you do OOP programming it's easier because reading code is enough to understand, while mixing Views and alter hooks ofuscate the whole thing and make me wanna stop doing IT and plant trees instead.
Pierre.
This right here
This really is one of the reasons I would opt more for Views in core. For a non-technical user starting a blog site with experience enough to install Drupal and enable some modules but with 0 SQL knowledge, having a GUI to cherry pick exactly what is displayed for on a path is exactly what will help bring Joe Public to Drupal and open it up to be more of an everyman CMS/framework.
My only criticism of Views in reference to this is the learning curve that the full Views admin page creates. That being said, simple View creation has made things a whole lot easier for non-technical users.
I feel there are modules that deserve to be in core far less than Drupal and would be better served in contrib. The poll module, for example, and with as near as dammit half a million sites reporting that they use Views, having it in core would make an amount of sense.
Read the 2 first chapters of
Just did. What's your point?
Yes, there are some contribs in Drupal's ecosystem that have a scope that's too large and could be split into several modules, but again, what's your point?
You're introducing all kinds of things to criticize and different kinds of "observations" and subjective "measures" - which don't mesh or line up with each other - into this discussion. And I don't think it's helping.
Yes, if you change the definition of "antipattern" to "any tool which misinformed people use improperly".
That's clearly described on the Views project page which you just told us to read.
How about a proposed framework for more balanced discussion...?
There are MANY benefits to Views. They might be worth reviewing. They are profound.
There are also many caveats to Views. They might also be worth reviewing.
Then some criteria for why a module should (or should not) go into core might be reviewed.
Greggles, is number/% of sites that use a module the sole criteria for putting a module in core?
What is other driving criteria for modules becoming candidates to be included in Drupal Core?
Hoping to turn this debate in to a more considered discussion...
Thank you!
Jeremy Donson
Database and Systems Engineer
New York City
On the pro side: Views would
On the pro side:
Views would receive the extra attention that core modules always get. Not sure how much that would really apply with Views though considering how popular it really is.
It is also one less thing for many new installs to download. A lot of time we forget that a vast majority of new Drupal sites are by first time or weekend builders. They don't have local development machines, so adding a module means going onto DO, downloading it, extracting it, uploading to their server and then activating it.
On the con side:
Increases the core size of Drupal. One way to alleviate this would be removing the Views UI and making that a separate, contributed module.
It slows down major releases as attention has to be given to more code. This also puts more of a work load on the maintainer of that release.
Related to the above point, Views development now slows down. New features are now on the same schedule as Drupal major releases. Think Views 3, which came out a year after Drupal 7 was released. If it were in core, we would most likely be waiting for Drupal 8 to be released. That means we wouldn't have all that awesomeness until next summer at the earliest.
Adding modules to core
More than just the number of installs is considered. The benefit to Drupal's core functionality is also considered. Take CCK/Fields as an example. This became a no-brainer as fields in the default Drupal entities could now use this. The same could be said for Views. Instead of having hard coded queries for the default node views, user tables, comment tables, etc., they could all be made into views.
Another consideration is what it will do to the development of that module. Refer to my point on Views 3 above for that. In Views case, if it was put in Drupal 7 (which there was a push for), there's a very good chance we wouldn't have Views 3 today, although if the UI was split out to contrib we could have all that awesomeness.
HollyIT - Grab the Netbeans Drupal Development Tool at GitHub.
Congratulations on noticing
Congratulations on noticing that Views is prone to be used as a "golden hammer" (just like Drupal itself, as well as PHP, Apache, MySQL, or any other tool...), but the following is just an awful hasty generalization:
Unless you meant the maintenance of a panels + views-driven website when both Panels and Views were a poor choice for the job. But that's a given.
I don't think the reasons behind the initiative for adding Views to core are "we are confortable with Views' approach and we're unwilling to learn and apply one that is better suited", but rather along the lines of "look at all these sites that are Views-based (in a non-Golden Hammery way) and successful and all these years of people asking (with valid reasons) for Views to be put in core".
So your whole golden hammer lesson/critique is just misplaced.
Also, It might sound simplistic, but at this point in Drupal's cosmos, my criteria for whether or not I'd like a "famous" widely used contrib (i.e. Views, Panels, CTools, etc) to be added to core is mainly:
The answers to those questions will pretty much define my decision.
But my criteria is incomplete, and maybe not intersubjectively useful, which makes me think that there should be a centralized "official" page with guidelines (just like we do with coding style, etc), maybe in the form of a checklist, for evaluating whether or not a module should be put into core.
Regardless, I think everyone should support the Views-Into-D8 initiative or whatever it's called, since the whole refactoring work will benefit Views' code even if it ends up not joining D8's core in the end.
look at all these sites that
Most of sites I built over the years started with Views and ended up without. Most of them were actually successful once Views has been removed, because of its poor performances, and the extra carefulness you need when you integrate it.
Now that it uses Ctools, it's even worse, CTools suffers from really old bugs which will cause *a lot (I mean, really a lot) of SQL or cache queries hanging around.
Pierre.
You're missing the point?
Views in core would be an optional piece - nobody would be forcing you to use it, nobody is going to get rid of the database querying system, so you'll always be free to build something yourself. This doesn't mean that Views should not be bundled into core, this just means that developers should learn more and identify for themselves what the correct tool is for the given situation.
Views works really well for the majority of Drupal sites but there are lots of situations where yes it is simpler and easier to write something yourself, honestly I've found that it and CCK are two of the main pieces that have driven Drupal's adoption as they make it so easy to build simple content lists that other CMSes have problems doing. Sure, there are situations where it may not be the best fit, that's up to the developers to decide based on the requirements.
You complain about using Panels+Views to build sites, that it's an "impossible" combination for maintenance costs, which I find odd. Many, myself included, have successfully used the both Views and Panels to build rather large, intricate sites with far more editorial capabilities than could be easily replicated without them (Panelizer, nuff said). Sure, if we'd built them by hand using our own code we'd have saved some % of memory or performance, but the trade-off has definitely been worth it. And yes, there are many situations where the query ends up being more complicated to do in Views, which is why we have a querying engine.
Ultimately, if a client changes their requirements to the point that the previously built views don't fit it isn't Views' fault, so stop bitching and deal with it.
We all know that if Views
We all know that if Views gets into a core, a lot of developers will start building the other's modules UI using it. If it gets in, it won't really be optional, for sure.
Pierre.
a) Will you be required to
a) Will you be required to use it? No.
b) Will any of the content list pages not be overridable? No.
The fact you pushed the
The fact you pushed the option b clearly states that you will do it. If another module requires it, and you need this module, then it's required. If it goes into core, some other core modules will rely on it.
Pierre.
I think the plan is to
I think the plan is to replace most listing pages with Views, but just as there are modules that already do the handwritten query -> views override, I'm sure that there will be modules that do the reverse in the future (for some strange masochistic reason).
--
Cameron Eagans
http://cweagans.net
Most people think that
Most people think that writing SQL is masochist, but when you know it, it's a pleasure.
Anyway, the View's problem is that you cannot just do a simple listing, you are forced to use a huge junk of useless stuff you don't need. Eveything is too highly coupled in Views to have the flexibility you need. It is really a golden hammer.
Pierre.
Drupal serves to abstract the
Drupal serves to abstract the user from having to write SQL queries and instead they write Drupal queries. Views abstracts this process to a UI where the non-technical user doesn't have to worry about joins, selects and protection against things like injection.
What is key to this point is that using Views would still remain optional and more technical users who prefer to write their own SQL would remain free to do so, whereas the less technical users who may never have heard of SQL (and believe me it's more common that you'd imagine) are free to 'show all items posted in the last week from users 1, 5, and 19's blogs'
If its just a module that you
If its just a module that you can disable then fine, but the integration seems more deep as the maintainers plans to refactor some of drupal code to match Views. See the point "Existing products dictate design and system architecture." and which has not proven to perform well. That's why I am concerned.
Quoting from the maintainer itself:
Also I am afraid of waiting the views module to be functionnal when upgrading to drupal 9 given the fact it has took 1 year for the d7 version to be operationnal.
Maybe I am missing something, tell me!
You keep quoting those two
You keep quoting those two comments, but they're completely irrelevant.
First one was most likely tongue-in-cheek.
Second one is not an example of the golden hammer antipattern in action. Specifically because of the "...wherever it makes sense" part, as opposed to "everywhere whether or not it makes sense" (which would be a valid example of golden hammer usage).
There's absolutely nothing wrong with refactoring code to use Views if it makes sense, just like there's nothing wrong with refactoring code to use the Field API now that it's part of core.
FYI the Field API was not
FYI the Field API was not just a copy of CCK put into core, it was rewritten as part of the effort (hence why its storage structure is very different).
Exactly.
Exactly.
In the nicest possible way
In the nicest possible way (excluding your above post regarding everything in core being a view, as that's out of my comfort zone), I couldn't really make much sense of your posts.
Most developers know what the "golden hammer" approach is and whilst you've explained what that is fairly well (although rather wordy for my liking), I find what you've written to be very ambiguous, vague and ultimately not all that helpful. Your post lacks real world examples related to views or any other Drupal module/methodology/standard and as such, doesn't actually go towards proving that views is problematic in this area, as you've stated.
Obviously there are thousands of tools out there that are used in this way, like someone else said earlier, this includes Drupal, PHP and more. The vague examples you've used to illustrate your own difficulties sound to me not like views issues, but issues with some developers and implementations. We've all dealt with badly built websites using numerous frameworks and CMS', so Drupal and its modules are not unique in this area.
Something else I take issue with is the fact that you seem to imply that because views is huge and took 18 maintainers a year to get ready for Drupal 7 qualifies as a reason not to include it in core. Is there a functionality/module complexity line that states that anything over a certain complexity/size disqualifies it from being in core on the basis that it takes a long time to produce? This may be something the community has to deal with, but I doubt it's a major issue for what is a massively used module.
(Related to the above point, I'm sure I'm not the only one that believes that as Drupal grows, is more widely adopted and becomes more complex, that releases will become less regular anyway, especially to suit enterprise.)
Personally, I use panels and views extensively and not once have I had issues that you point out, even in my high traffic websites. They may not be perfect, but their usefulness outweighs everything else in my opinion. Like Damien said above, CCK and views are probably two of the biggest reasons people adopt Drupal, so maybe more time should be dedicated in educating Drupal adopters on how to use the tools properly and less time wasted on posting heavily opinionated, ambiguous statements on the tools themselves.
TL;DR: I disagree entirely. Bad implementations, good tools.
Bad implementations, good
Everything has been said, d8 core is about to make a good framework (see #framework initiative), not tools.
TP;BR: Too much pride, but I read.
No offence, but I have no
No offence, but I have no idea what you're talking about.
looking at the usage
looking at the usage statistics of views, it seems that 485K websites did choose it, so to me it does make sense to integrate it to the core, as cck did before.
I mean if a contrib module is so widely use, the normal process is to make a core module from it. After if you don't like it, you can still disable it like any other module, but i'm really sorry, you can build custom blocks with custom sql queries beside having views enable anyway, so i don't know what you're on about.
Nice post
Thanks for this article. Views has a great UI, but suffers from too many historic design choices to be included in core.
Today with Symfony 2 being integrated in core we must turn the core towards the future, not the past, and Views is a huge piece of past we cant allow to get in core. Don't misinterpret me, I still think its maintainers are good developers, and they really work hard and I respect them for that.
What I say is that Views design suffers from PHP 4 and a single use case oriented original design. Deep inside it hides behind the word "View" at least 4 different tools: an iterable datasource API (view object mostly, query, ...), a datatype based display layer that I would call a set of formatters (theming abilities, displays, ...), custom view (as in MVC) response implementations (blocks, page, etc...) and a gigantic powerfull UI. Probably a lot of other hidden stuff are hanging around in there.
At least 3 of those tools could be independent and useful outside of Views, if they were reusable and had a clear interface/API: in real life all of the 4 of them form together a huge highly coupled historic piece of code that you can't dissociate and honestly can't use as an API when you are a developer. This is a mistake to think that going backwards and change that is do-able. I think it's not considering the actual code.
Views grew integrating a lot of good ideas, but today has a huge codebase we can't really refactor. The form in which it exists today starts to suffers from its own limits, and most of it should be rewritten from scratch, starting from the basis: a datasource API (that we could use for anything else than a "view"), until the end: a nice UI (for site builders), depending on a standalone formatters API (we could re-use for fields, forms, entities and whatever custom code we can imagine).
Pierre.
The UI is a pretty separate
The UI is a pretty separate component. You can just turn it off.
I think you have some good ideas about how to refactor the Views codebase in preparation for it going into core, but you say that it cannot be refactored. I think this is false. Views' code is pretty easy to understand, but it seems that you are of the same mind as Sylvain (you like to write your own code), so you don't have any interest in doing so.
--
Cameron Eagans
http://cweagans.net
I have good ideas how to
I have ideas how to avoid kill Views and do a collection of API's that could achieve the same thing being decoupled from each other.
Views as it exists must die, and could live as a pure UI, but everything under is today way too specific to survive, because it's not re-usable.
Pierre.
Can this happen once in core
Can this happen once in core ?
What I say is that Views
I endorse that, when I moved / updated a client's Drupal 6 site to use a Views D6 made 'crash buggy' by PHP 5.4.x, I rewrote Views to suite the new PHP 'structure'.
On doing a uploaded code patch for the D6 community, I was 'reminded by the Views Team that such a 'patch' was clearly against the well defined target of D6 Views to support PHP 4.x!.....(period). The subject was 'closed' by the Views Team.
However, the modified Views served my clients well under PHP 5.4.x and now PHP 5.5.dev.
A solid View API foundations and a re-write is the future needed for Views to smoothly bind into Drupal Core.
I am quite confident that Views will go onto Core, and it is acceptable to do so, along with the welcome new input of the larger Drupal community to manage the growing Views 'code base'.
--
Linux: Web Developer
Peter Bowey Computer Solutions
Australia: GMT+9:30
(¯`·..·[ Peter ]·..·´¯)
I was clearly speaking about
I was clearly speaking about software design, not raw compatibility. Views still suffers from the same internal design which have never been really changed. The view object is a huge and obscure object registry where almost everything is public, most of its method calls will trigger obscure iterations and may fall into the deepness of the call stack which sadly often lead to PHP fatal error (WSOD) while reaching the stack limit; It happens as soon as you have some rules or anything else that suffers from the same problem on top of it (in my case, it's almost daily). Views is very hard to debug in general, I'm using XDebug on a daily (hourly basis probably) and Views is the only piece of code I'm afraid to get into each time I have a bug related to it. The views exports are almost as obscure as the view class; Code path is never really clear and all software layers (query, result handling, result iteration, theming, frontend plugins) are mixed into the same view object. For example, view's cache plugin should not act as a view plugin, but as decorator or proxy instead. Theming layer should not know anything about the view object itself, and query should not be known to the centric view object, which should be aware of only a result set iterator/datasource. The whole design seems confused, highly coupled, unflexible, and not really usable as an API. It's hard as hell to extend, and when you do so, you experience so many weird PHP notices that you always end up by doing step debugging into internals and arrays, because those arrays are almost never defined by documentation.
EDIT: Pure typo.
Pierre.
For example, view's cache
Do you have ideas how to do this ? I havn't digged into plugins yet.
View would be the Controller (in a Model-View-Controller approach) or a Presenter in a Model-View-Presenter approach and theming layer the View.
Query would be the model / datasource, how would you map this model to the View layer ? I think MVP approach is a good deal, having the original View object as a presenter and datasource as a ListCollectionView, ArrayCollection interface.
It really depends on the approach seems the best for View: Presenter or Controller ?
Maybe you can help contribute on this topic: http://groups.drupal.org/node/249958.
I think that today, if we
I think that today, if we want to be able to use View's components without the central View object itself (which is something that I would want to be able to do) an MVC model where the View object is the controller sounds better.
The theming layer already exists in Drupal: I see field/entities formatters as standalone objects (reusable in various contextes outside of Views) and the glue which ties the formatter together as something closer to Drupal theming layer, but not tied to the View itself.
The View has an additional functionnality, which is quite important in the end, which is handling arguments, pager, and such. Pager is not a good example because if you implement the pager as decorator or proxy of the model iterator object, you don't need the View to use it, but for other various complex plugins (I'm always thinking argument) which retrieves data from various places (url, session, whatever else) you need the View object to act as a controller.
With such design, you can spawn easily model iterators, already filtered (for example node), on which you can apply proxies (pager), you then inject into a presentation layer (not the View, but upper) which then uses standalone formatters. Then, if you need to do UI driven or contextual stuff, you add the View in between, which will spawn your model iterator and injecting the filters depending on the request (the arguments and whatever else) and then delegates the filtered model iterator to the presentation layer which from there acts independently of the View just using the iterator.
Pierre.
As I've been called the "ultimate troll" elsewhere
I thought I would come here and just say - if we all stop for a moment, and listen to each other, we can find out what needs to happen next, and remember, its not personal.
Indeed, you are right.
Indeed, you are right.
Pierre.
Some kind of views has to be in core
If you take a look at how pagers are build know. Or thing about all the different implementations that collect some kind of data for us. They all do their job and give us some freedom. But they are not really open or pluggable.
With Views we get a real interface we can pluginto, alter and extend.
I feel this discussion is pointless because you say "Don't put Views in core!". It really should be "Please give us a system that is slim and extandable". And I don't think your intentions are to troll or build everything by yourself.
Please join the discussion about how and what of views we can get in core. The time it took you to write the first post and the followups could have been spend on reviews, coding and giving your opinion on how things should be done.
I read there that you have a good impression about how software is build. And that you are devoted to the project Drupal. Please help us grow and how we can make it better. Join the views crew and help them build a better views in core with your ideas. I bet a positve discussion will ease your mind and probably show that they are already going in that direction. :)
IRC #drupal-views is a good channel to ask questions and get some opinions.
--
comm-press |
I see that the debate and
I see that the debate and disagrements are more a developers and integrators confrontation.
Before sending me the jedi assassins I respect both integrators and developers, they are useful jobs and have different visions.
I am afraid that my vision will be not accepted in the Views group because it involves a deep refactoring and a bottom-up approach. Things that I have absolutely no authorithy to dictact.
I know we are a few to use drupal as a developer platform and not as an powerful integration platform but I believe the core initiatives are being focused on developer experience by providing a quality "drupal the framework" upon Symfony2 and that "drupal the CMS" will be more appealing to integrators.
Frankly, having working with the Views API as a developer was a really bad experience and I don't know if I will have the courage to fight integrators when they don't think in terms of good abstraction but more in terms of integrations and implementations. They are very good implementationists and that's a part of its growing success. Abstractionists versus implementationists are two distinct groups involved in software development. Sadly implementationists outnumber abstractionists approximately 4 to 1. Thus, unfortunately, abstractionists are often outvoted.
My vision of Views would be to have a high quality content selection API, making selection of content its core. But that's not something I have the authority to decide, its not the vision of the project who aims an integrator audience.
Sylvain
I'm sure you could offer to
I'm sure you could offer to help the views team, no?
fwiw
fwiw I view myself in both camps and while I resistent views at first, it leads to far more sustainable development practices when paired with features and the exportables that ctools provides. I also think there's a split in camps between those that are more in the vendor role and those more in the client. We won't accept work that doesn't utilize Views because we'll have to then support it for years going forward and while there are some issues in Views, nothing significant as cropped up for us for some time.
Anytime I've run into "issues" with views in terms of inflexibility I've just query_alter'ed it pre-render for more complex arguments. Cautious but happy to hear it's moving closer to core.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
I think what those who are
I think what those who are most vocal on this thread are missing is that the other point of view is completely valid. In some cases Views is the most appropriate tool for the job, in others it should not even be downloaded.
On one end of the spectrum are the sites that are built in less than two months (probably the majority of Drupal sites). For these Views is very appropriate.
On the other end of the scale is a team of people that work full time on a site that is using the principals of continuous integration. In these cases Views is rarely appropriate.
For each project you need to find a balance with your requirements (performance, maintainability, speed of development, extensibility, ...) and then find the tool that fits best. (For those of you that haven't seen it I highly recommend Larry Garfield's Drupalcon Denver talk on this topic).
Drupal's strength is that it can be a good fit for both ends of this spectrum. And we all benefit from the fact that there are so many people on 'the other side'.
Now assuming that we can all agree on the above, the reasons for (not) including Views in Core are completely different. Here's the main ones that I see:
Pros:
Greatly increase the usefulness of just 'Drupal Core' for someone who isn't a Drupal expert. I was involved in the Snowman project last year and the main thing that we discovered is that it is /impossible/ to build a site with just Drupal Core without needing to know either the fact that Views exists (and what it can do), or a good understanding of Entity Field Query / DBTNG. Without knowledge of one of these things Drupal Core is useless to someone who installs it for the first time.
Increase the overridability and customizability of Drupal Core. /node /admin/people /admin/content and others are so generic that they are useless. The Drupal guiding principal of making things easy to change has never been put into practice in these areas.
Cons:
Not a great separation of parts, not a great API. I think pounard covered this one well.
I've only dabbled in Core development over the years, but enough to know that it can be very slow going. The time investment required to make substantial improvement to the design of a subsystem is immense. Even the time required to make simple bug changes is exponentially more than for code in contrib.
My name doesn't enter anywhere near the list of top Core contributors, but I can totally understand the concerns about the size of Drupal Core, and our ability to manage it. Especially those parts that are less useful to Core developers (who are more likely to find themselves in the 'Views is not useful for my projects' camp).
With all that said my personal opinion is that the benefits of having Views in Core are substantial and that the issues can be overcome and/or mitigated. Nothing in Drupal Core is perfect and never will be (though some parts come close). But the strength is from the entire package and the entire surrounding community.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
Excellent post, they are
Excellent post, they are indeed pros and cons. My main concern is that by letting the Views team doing this job, we will end up with a unsustainable system that will desperatly try to grasp the glory of the past.
If Views needs to be refactored to be a clean and clear API, it needs to explode and disappear for the sake of a set of new independent pieces of API we can re-use: if we don't, we will have duplicated core all over Drupal (Views is almost the size of actual core).
Views must die, its UI is good, but if Views gets refactored, the UI will inevitably die with it because current UI is deeply tied to what Views has been created for: just a huge form.
Pierre.
clean and clear API for Views
Pierre,
I am only one small PHP Developer, with many code projects spread wide over several CMS methods and frameworks...
I have followed this entire Views debate, and note you have pushed the [future] ideal concept; "refactor Views, explode it, and create a new new independent API". This is a sound future for Drupal globally...
Historically, Views blocked several of my recent projects on Drupal 6 for it's insistent "Views team' glue to support nothing less than PHP 5.3.x. I set about (successfully) to rewrite the D6 Views for PHP 5.4.x (and PHP 5.5.x), and yes' Views really is a very large FORM (as code)! Current Views code is likely much more complex than the entire Drupal Core. The chances of duplicity to core is rather high!
--
Linux: Web Developer
Peter Bowey Computer Solutions
Australia: GMT+9:30
(¯`·..·[ Peter ]·..·´¯)
In fact I'm more about
In fact I'm more about creating three layers for this API, but as their simplest expression possible for easiest maintainance: iterators, formatters, and UI. I'm not saying views must be refactored, I'm saying it must be rewrote from scratch because it became way too complex to be efficient and sustainable for anyone. I think they never did rewrote it fully, it carries too much from the past.
Pierre.
Views in D8 Core
Hi Pierre,
From Dries' keynote that took place this morning in Munich: Views is now part of Core.
So I guess Views team is not anymore in charge for this big code - the whole community is.
Amicalement,
Alexandre
http://w3w.fr
Not quite. Views is not in
Not quite. Views is not in core yet (see for yourself: http://drupalcode.org/project/drupal.git/tree/refs/heads/8.x:/core/modules).
--
Cameron Eagans
http://cweagans.net
:-D I did not said it was
:-D
I did not said it was committed to git: I said it ws officially announced by Dries. This is gouvernance, not development.
But it means that the Drupal community is now in charge.
Alexandre
http://w3w.fr
Until it's committed to git,
Until it's committed to git, it's not in core. merlinofchaos still has full control over the project and could decide not to move it to core at any time (though I don't think that will happen).
--
Cameron Eagans
http://cweagans.net
For such big news there
For such big news there really hasn't been any talk of it. I noticed a little bit on Twitter yesterday, but nothing on Planet or by Dries on his blog yet.
HollyIT - Grab the Netbeans Drupal Development Tool at GitHub.
Encore un Nantais :) Are you
Encore un Nantais :)
Are you both planning to go to Paris this week-end ? There is a meeting from 26th to 28th and I think I will see what happen here and try to help if they need/want to.
After all, if Views get really in core, let's try to help. At least I would have tried...
(Sorry for answering
(Sorry for answering here...)
:-D
Former one: I believed my drupal.org profile was up to date (it was almost...) and that groups.D.O profile were synced from D.O profile => it is not!
So I just did, as I am now back in Ile de France - but today in Munich
Can you give a link to this meeting?
Alexandre
http://w3w.fr
Overeating leads to indigestion and obesity
Related ... overuse and misuse of pretty much anything has consequences and side effects.
Overuse/misuse of views is like overuse/misuse of modules e.g. Server indigestion: The Drupal Contributed modules "Open Buffet Binge" Syndrome.
Less code is better code, and making stuff optional goes along way ...
Drupal performance tuning, development, customization and consulting: 2bits.com, Inc..
Personal blog: Baheyeldin.com.
As always, Jeff Eaton has a
As always, Jeff Eaton has a well-articulated, thoughtful response: http://angrylittletree.com/2012/08/hammers-screws-and-views.html
--
Cameron Eagans
http://cweagans.net
Well, his answers sounds good
Well, his answers sounds good and is very truthful, but he's not seeing the whole point. He states himself that Views is a lot more than a SQL query helper, and he's right: that's today the whole problem. Views is so many tools at once that it makes no sense at all to speak about it as a whole. Trying to integrate Views in core is probably even harder than integrating Symfony's components because at least SF components are decoupled and easy to replace or remove.
Pierre.
Missing the point?
One of the difficulties with this conversation is that it's turned into a place for everyone who doesn't like something about Views' architecture to chime in and say, "Yes! I Agree!"
The result is a lot of mutually contradictory arguments against Views, each undercutting the others' points. One of the arguments is that Views is "essentially" an overgrown query builder, and that it is less efficient than writing one's own SQL queries. Another argument (the one I think you're primarily focused on) is that the individual tasks that Views performs should be split up from each other completely and treated like separate projects for inclusion in core. A third argument -- the one that has taken most of the energy in this thread, and that I was primarily interested in addressing in my blog post -- is that Views should not be included in core because it is misused by site builders.
The particular argument you're advancing -- that Views does too much and should be split into smaller functional components -- strikes me as a bit odd. You're arguing on the one hand that it isn't a coherent whole, then arguing that it is not modular enough. Views is more than a SQL builder because its mission is not "building SQL queries." Its mission is "building and displaying lists of content." I'm not sure what we would gain by tearing Views apart and separating each of the things it does in order to accomplish that goal.
If someone were to put forward a very concrete and detailed proposal for an alternative architecture and UI, we could evaluate it and weigh the risks of pursuing it instead of using the existing Views codebase. Until that happens, saying that we should "rewrite it from scratch" in a "more modular fashion" is hard to take seriously.
I started a deep
I started a deep investingating into the current architecture. I submitted a code audit with SONAR static analysis to measure the global quality, violations are often a good indicator.
Also I will put a detailed proposal based on UML to propose an architecture. I havn't found a decent tool to extract an UML model from PHP (tried pear/PHP_UML but the XMI model is not importable by ECore). So I am investigating manually and creates a model of the current snapshot of the 8.x branch, it takes time but I am sure it will help to communicates better.
Sylvain
Isn't this an indication Views has deep problems?
Despite the inconsistency of the arguments, shouldn't this be a sign that there is widespread frustration with Views and that maybe it's time to rethink it?
I've had several clients (including a large-scale project for a major US government agency) who were excited about Drupal but wary of Views. If Views is a reason to not choose Drupal, that seems like a problem.
Despite the inconsistency of
To be honest, this thread is one of the first places that I've ever heard anyone say anything bad about Views. Sure, I've heard people complain about how people misuse it, and that's totally valid, but it's not the fault of Views that people misuse/overuse it.
I've shown Views to a couple of wordpress and joomla devs that I know (shhh...don't tell anybody I talk to joomla devs =P ), and their reaction was something like, "ZOMG YOU KNOW HOW LONG THAT WOULD TAKE ME TO DO BY HAND!???1?1?"
--
Cameron Eagans
http://cweagans.net
Also, it strikes me as odd
Also, it strikes me as odd that clients get to dictate what modules you use to build their site, especially if they want a fixed budget and timeline. They're hiring you for your expertise, so you should be allowed to make decisions like that.
Plus, if there was any doubt about the viability of Views for their site, you can just point to the front page of whitehouse.gov. I found two views in about 30 seconds.
--
Cameron Eagans
http://cweagans.net
If you're evaluating
If you're evaluating platforms, you'll also be evaluating common tools to solve certain problems. In this case, the competition wasn't Wordpress or Joomla (where you're absolutely right) but Django and Rails, which have robust and well-designed query building APIs.
I'll note that in the end, the client went with Drupal, and we used Views very sparingly and never for the fundamental functionality of the site. But because of Drupal's lack of a data API up to the standards of other tools, we actually factored the database into its own web service built on the Perl-based Catalyst framework. I'll also note that your Whitehouse example is was one of the ways I ultimately sold them on Drupal.
Well, you know, I have a
Well, you know, I have a client who has established a list of modules that can be used. If I want to use a new one which is not on their "security" list I have to submit to the security team before it is get to the project. Views is in the list however!
Also, this same client have a clear requirement about the tag weight within the generated HTML.
The text/tag ratio have to be superior to 20%, this is a hard requirement that can be problematic when using out-of-the-box Views for instance.
Another requirement is to have a server generation response time <1s.
It may seems you odd, but that's clients needs, they are understandable, and its not really an option to discuss their needs ;)
As a side note, I found no Views in energy.gov. @see http://treehouseagency.com/blog/neil-hastings/2011/09/06/building-energy...
Should Views be rethought?
The concerns and criticisms being voiced in this thread shouldn't be dismissed, but the fact that they exist isn't in and of itself a cause for worry. Any project that's in use on more than three quarters of the Drupal sites in the world will have detractors: that's a statistical certainty. The specific concerns should be considered on their merits.
This sort of wariness is natural, and I've faced those questions from clients about the use of CCK, FieldAPI, HTML5 video, jQuery, and Drupal itself. As architects and developers, it's our job to evaluate the pros and cons of any given approach, and explain them to our clients.
We also need to remember that the CCK/FieldAPI/Views approach to site building is (in my opinion) responsible for Drupal's explosive growth over the past half-a-decade. That "only code if you have to, build with tools whenever possible" approach may cause some programmers to flinch, but the vast majority of Drupal's site-building users prefer it. It's a successful approach to the point that the Joomla! and WordPress ecosystems are hard at work producing clones of CCK and Views to avoid falling behind.
If there are concerns about the architecture underlying Views, and how it accomplishes its goals, we should talk about them. But if the disagreement is with what Views tries to do -- give site builders a code-less, GUI-based tool for creating a wide variety of content listings -- it's basically dissatisfaction with the nature of Drupal since version 5 or so. That's not bad, per se: frameworks like Symfony exists for a reason, and writing code on top of those lighter APIs instead of Drupal is a much better fit for many bespoke developers.
I don't think all those
I don't think all those arguments are mutually contradictory, they all have valid points. Views is so big it's not surprising to see that much arguments against.
Pierre.
Writing custom SQL
I dont get the argument for writing your own SQL. Just because you can doesnt mean you should. Just because you can write something in assembly doesnt mean you should. Are these people suggesting that writing a query is quicker/simpler/more efficient then point and click? let alone outputting as a page or block
Comparing SQL and assembly is
Comparing SQL and assembly is a bit exagerated. SQL is a very human readable language, not a computer language.
Furthermore I don't think people are saying we should always write SQL but that we should separate the data access layer completely from the view layer, which is usually a good practice. Views today behave like a complete MVC layer with no separation of concerns at all, which makes the code absolutely offuscated and complex.
Pierre.
There's a different scenario
There's a different scenario for everything. If I only need one page/block with a custom query, then do I want to write a few dozen lines of code or add Views and CTools into the site? When you think performance, going custom is much better.
There are also times that Views generates queries that are horrible on performance, so you end up doing a query rewrite or just go custom.
One client's site I run has a bunch of custom stuff and doesn't use Views. Why? Well when something needs changed, I can quickly code it out, push it to git and pull the update on their server. It's a lot easier to manage than going the views route. Other client's I use Views heavily. It all depends upon what you are doing.
HollyIT - Grab the Netbeans Drupal Development Tool at GitHub.
You missed the boat
Four years or so ago, I have created the handbook page Why use Views? Why not write your own queries and back then I was against Views. Those days are gone. I consider Views 3.x a great, versatile tool and as any versatile tool it can and is overused. That is no reason not to include it in core.
Chx, I tried to change my
Chx, I try to change my mind as well, but when I see a commit like this, I feel like a fish out of water.
I am not saying that Views is not a great asset, I am saying that effort is expended reworking past software to conform to new challenges [ref, ref] rather than building upon a solid foundation of past successes while the [meta] make core maintainable focuses on loosen the coupling between components. And that is problematic to me.
Edit: I bet that when Views will be in core, there will be a [meta] make Views maintainable in the following months.
What about that patch makes
What about that patch makes you feel like a fish out of water?
--
Cameron Eagans
http://cweagans.net
Its not personnal but if you
Its not personnal but if you are asking this question you may not have the keys to understand what conventions are, we can discuss this point in private if you want to.
Here is a follow-up aiming to refactor the View class: http://groups.drupal.org/node/249958.
Actually, I was just trying
Actually, I was just trying to get you to substantiate your argument instead of pointing to something and say "This is bad". I want a "because...".
What don't you like about it? The size of the patch?
--
Cameron Eagans
http://cweagans.net
Very interesting analysis:
Very interesting analysis: the real conversation eventually starts now :-)
This should help get rid of the troll part of the thread.
Alexandre
http://w3w.fr
And after posted the
And after posted the conversation actually droped :p
Maybe people are not interested into design problems, seems there is more energy spent into defending the babel tower than re-archtecture it to make it solid like the rock and flexible like the water.
This is sad, but I do agree
This is sad, but I do agree about this, and for something that is that huge, it's a problem, because once included into core, redesign won't be possible anymore, or very hard to do.
Pierre.
how about
If you have an awesome tool that hammers nails, every application of that tool looks like the Golden Hammer problem.
Also, Drupal is a Golden
Also, Drupal is a Golden Hammer. Let's not ship with it.
http://developmentseed.org/bl
http://developmentseed.org/blog/2012/07/27/build-cms-free-websites/ ? ;D
+1
+1
Pierre.
build-cms-free-websites
+1
This is where I often find code grows real skill.
Otherwise, I am nearly always patching CMS Cores, and other windy 'add-ons'... bugs and all.
--
Linux: Web Developer
Peter Bowey Computer Solutions
Australia: GMT+9:30
(¯`·..·[ Peter ]·..·´¯)
Is there a kittens-killers
Is there a kittens-killers official conference around here?
:-D
Alexandre
http://w3w.fr
As you pinpointed many times
As you pinpointed many times with your articles about useless/bloated caches, Drupal tend to gain complexity over time, out of any control.
We'll soon reach, if it's not already the case, the point we won't clearly understand the how and why something as been implemented…
Building cathedrals over dominos…
AMHO Drupal still has an interest for making business as any big web product, but you know the drill… eggs… basket…
And because of all that, including Views in Core is just digging one more step to our own Hell…
Another "cons" against this idea: just read the Views 3 documentation… Enjoy…
comparing views with a hammer
does not realy hit the nail on the head.
It rather is a swissknife. Who does not like to have allways something like a swissnife on hand?
Sure, it is a little complex, like a swissknife.
You can abuse it for things, where other tools are much better, like a swissknife.
After I allways install it, when I install Drupal, for me it would make sense to come with core.
+1
+1
Are we sure?
Views in core seems to make sense because everyone uses it right?
I find it a very powerful tool for display, listing and bulk ops. It could easily replace all the basic drupal screens if I wanted it to. Who cares if it can't do perfect, custom SQL. It works as designed!
Code management....
That's another story. The bigger the machine the more complicated it is. I would argue that if views is going to be in core then it needs to ge its 7.x issue count below 50. Currently it's ~650 open issues.
Hmm.. 50 issues a week means 10 a day and so 5 devs taking on 2 per day? So in 8 weeks with 5 devs the issue list could be killed?
Web Dev, Consulting and Design
DynamicDan.com
Hmm.. 50 issues a week means
At first I thought you were really serious about this, but then I saw "Intelligently powered by WordPress" in your personal website, I understood you were joking around this thread.
Personal abuse
Sylvain, not for the first time in this discussion you've resorted to personal attacks or abuse. It's completely out of order in my opinion; just because you don't like what someone has to say doesn't mean you can insult them.
It's obvious you've taken it a little personally that not everyone agrees with you, but that's still no excuse to act like a child.
Yes you are right, sorry
Yes you are right, sorry dynamicdan for being irrespectful...
To answer your question, in short, this would be possible in an ideal world where issues wern't correlated together, that is coupled. In this ideal case, working separately on decoupled problems in decoupled components would have no impact on the existing. Sadly, for reasons that dalin explained above [ref], when issues are correlated, plus the fact that every piece of code is highly coupled, the time for fixing an issue is exponential and not linear. That's why, you can add as many resources you want, it wont help.
My apologies if I offended you.
No probs
I like a good laugh but be careful. If I was in a bad mood I could have easily taken offense.
In the end, everyone is trying to end up with a better product/drupal. If there was one right way to do it then we'd only have 1 CMS online. I think it's good you voiced your opinion which needs to be heard and acknowledged. I don't really care what the outcome is however so long as life goes on and it's a bit better than yesterday.
Views in or out of core doesn't bother me. Views (or various other solutions) not being worked on would.
Web Dev, Consulting and Design
DynamicDan.com
Dynamicdan there is something
Dynamicdan there is something else… Views team does not accept css issues (https://drupal.org/node/571990), even with the core themes and the views base CSS !
I hope it's a lack in my configuration, but currently, as I see it, the admin ui is totally broken (a div that isn't "relative" positionned) and there is a hidden deps to jQuery UI that I have to figure myself; and by broken, I mean unusable without installing jQuery UI and patching CSS and JS from Views Admin !
How are we supposed to understand this ?
Views team does not accept
Sorry, but that is total bull. On the very page you linked it says:
People complain about the "bloat" of views. Think of how much code would be added to accommodate every different scenario possible.
I noticed your issue here:
http://drupal.org/node/1677654
Funny, out of all the D7 sites with Views 3 I have done, I've never had that problem. Also never needed to install jQuery update.
As matter of fact, if you consider the fact that there are over 300,000 D7 sites with Views 3.x and you are the only one who reported this issue, then it appears that it's something in your setup.
And it the jQuery Update dependency was an actual problem, why did you mark your issue as closed(fixed)? Why didn't you bother to open a new issue of this "invisible dependency"?
HollyIT - Grab the Netbeans Drupal Development Tool at GitHub.
Views is just one tool among 19302
Views is not a golden hammer, it is just one extremely useful tool among 19302.
Which, by the way, weights
Which, by the way, weights the same as the 19301 other ones reunited.
Pierre.
Sylvain IS right
Views is a golden hammer, and everything does look like a nail. And, I keep smashing my fingers trying to nail in these screws.
I think anyone who has built a Drupal site of any serious complexity, with rigid requirements, knows this is true.
Then, of course, Views and CCK are responsible for Drupal's popularity.
Why? Well, you can do amazing things with Views in minutes. Things that would take days to code from scratch, or even using a framework.
But, you can also spend days trying to do simple things using Views. Things that would take a fraction of the time without Views. In fact, in aggregate, I would contend that average (moderately complex) site-building productivity using Views has only gone up slightly. Far too much time is wasted finding hacks.
Here is a post about how to do conditional fields in Views: http://drupal.org/node/1935092. That, IS, disgusting. And I do this disgusting crap daily.
And, going further, EFQ is great, but then try actually rendering your output. All the fields are geared towards being rendered in Views, so you end up spending forever trying to hack really nasty array code. Try printing out a formatted Commerce module price without Views!
I sure would like it if the next version of Drupal makes it more elegant to do the edge case stuff. I'll bet it does!
Try printing out a formatted Commerce module price without Views
Umm...
commerce_currency_format($amount, $currency_code, $object = NULL, $convert = TRUE)This function is documented really well in commerce.module.
Is your issue with Views or with the field API?
I'm aware of the
I'm aware of the commerce_currency_format() function. Thanks for taking the time to mention it! The community is one of the things that makes Drupal really enjoyable.
The problem I have is that I can easily define a full rendered price field in Views, in minutes. To do this in code requires you to get the value from the product object (properly, with language settings, currency, etc); feed this to the commerce function; in my case, I need to also strip off decimal places (there's a module for this in views/display suite), and then rebuild the markup for display. That's a lot of work... for one field. But, when you are forced out of Views, this is what you must do. This, and many other things (see my conditional example above), would normally be a LOT easier, but I think Views is emphasized and often to the detriment of the general coding experience.
Just commenting on Views (and yes, the Field API) and agreeing with Sylvain's observation.
I chimed in to agree with something that is accurate. It's important to be critical and for Drupal to improve/move toward a more friendly coding experience. I'm hoping Symfony helps with this.
view modes
Why don't you just render your entities using a custom view mode, and use something as display suite to control what field appears where? This is how we're doing it and it makes your code pretty clean and separates it well form the display/theming.
We've tried this too, and it
We've tried this too, and it works well. But, again, you end up needing to do something custom, you end up hacking at DS hooks.
For example, here is the code necessary to print out a commerce price, without decimals.
$pproduct = entity_metadata_wrapper('commerce_product', $product);
$resprice = $pproduct->commerce_price->value();
$conprice = $pproduct->field_contract_price->value();
$settings = array("calculation" => "0", "currencies" => array("USD" => array("decimals" => "0", "force" => 0, "zero" => 0)));
$return = commerce_price_decimals_formatter_currency_format($resprice['amount'], 'USD', $settings, $product, $convert = TRUE) . "/";
$return .= commerce_price_decimals_formatter_currency_format($conprice['amount'], 'USD', $settings, $product, $convert = TRUE);
It seems ok, except that in order to find HOW to do this you must first debug the module providing the decimal formatter, so you can deduce how the $settings array should be constructed, which means you need to first setup a View and configure the field settings, so that you can debug to find what the array should look like.
If this price formatter module was only an API, there would be documentation, but instead, this module is primarily built for the UI, so no docs. The UI can't do everything, so you end up spending several hours doing what should take minutes.
Ok, so it's just a gripe, but it's a real one, and I think this could/should be improved. The render arrays patchwork is a magic string nightmare.
But... back to your point. I just asked a question along your lines last night on StackExchange: http://drupal.stackexchange.com/questions/68242/displaysuite-but-for-fields. Maybe a DS, but just for fields, would help with this? Call it FieldSuite?
Is it the Custom Formatter
Is it the Custom Formatter module you are looking for?
You don't have to use DS for
You don't have to use DS for this, it just makes it easier, you can use http://api.drupal.org/api/drupal/modules%21field%21field.api.php/functio... to define a custom formatter for any field, or you could use hook_ds_fields_info (see http://drupalcode.org/project/ds.git/blob/refs/heads/7.x-2.x:/ds.api.php) to accomplish so;ething similar
With hook_field_formatter_info you can render a single field, with the ds hooks, you have to render the entity.
I think commerce should add helper functions to make it easier to do such things, commerce is nice, but - as you said - is lacking documentation in some places. We had some similar requirements and we ended up writing custom formatters so we could re use them in other projects.
I have a sandbox with some custom ds things inside, but it isn't up to date anymore (http://drupal.org/sandbox/attiks/1591346), maybe we can start a project to bundle all custom ds formatters people need.