Drupal 6 Attachment Views 35
Trevor James writes "Green's book is without a doubt the definitive practical guide to using the Views 2.x module in Drupal 6, and to creating complex and dynamic page, block, and attachment-based views for your Drupal site. One big plus to this book's structure is that Green uses a real "live" production website project as a guide (he states early on that he was working on the site build for the client while writing the book and that the client approved of using the site build as the book's main example) — all of the chapters and subsequent tutorials are focused on building a site for a company that specializes in hiring out contractors and subcontractors. It's nice to see real-world examples being used in a computer tutorial book, especially one focused on Drupal and Drupal Views. The data Green is accessing is real data and this helps to engage the reader and show the multitude of real situations that a developer will get involved with when developing Drupal Views." Read on for the rest of Trevor's review.
Green introduces us to Drupal 6.x Views in Chapter 1 by creating a page View. Green points out how a Views panel relates directly to the SQL statements being run on the backend by Drupal, something I have not seen done in any online tutorial or book — he maps out the panel View and shows, for example, that the Sort Criteria in your Views interface matches your SQL "ORDER BY" statements. A nice touch.| Drupal 6 Attachment Views | |
| author | J. Ayen Green |
| pages | 300 |
| publisher | Packt |
| rating | 9/10 |
| reviewer | Trevor james |
| ISBN | 1849510806 |
| summary | If you are a Drupal developer of any level and you are waiting to explore Attachment Views, then this book is for you. |
Green also shows us how to Analyze the views we create to test their configuration before previewing the View. This is another trick I was not aware of (and I use Views heavily in the work I do) so I'll emphasize here that the book covers the Views interface exhaustively. Every detail of the interface and building page and attachment Views is covered. Green tackles building Views using Arguments in both Chapters 1-2 and does it in a method that demystifies Arguments and makes them much easier to understand.
The book shows methods of leveraging the Views interface to preview your View data and content without having to leave the Views screen — in chapter 2 Green shows us how to test our attachment View by previewing the Arguments we've added directly in the Views live preview area.
Another nice surprise in this title is that the author covers many other Drupal components besides Views. In chapter 2 Green dives right into Drupal theming showing us how to create template files for our Views and add PHP and CSS to tweak and manipulate our Views display output. So right here you're not just getting a book on using Views but also some basic instruction on how to build theme template files and add code to the tpl files.
In Chapter 3 Green moves into a detailed tutorial on creating a module. First he shows us the core Drupal Contact form (Contact module) and we build a simple contact form. Next he explains that we can extend this simple contact form by building a custom module to add custom fields to our form — for example adding fields to collect address information and also tweaking the labels for the core Contact form. Green explains in detail how to build a module and how to use Drupal's form_alter hook to "alter" our Contact form. It's the best description and explanation of the form_alter hook I've read. Again Green gives us much more here than simple Views building — he shows us how to build a module in Drupal. Finally bringing Views back into the discussion we learn how to glue all of the parts we have — the contact form, custom contact fields from our module, a CAPTCHA field, and an embedded Gmap using the embed_gmap module — into a View and then display this view on our site to show multiple Drupal components on one page. We end up building a dynamic Contact Us Web page that contains a map, contact information and a Contact form. Amazing stuff.
For the first 3 chapters alone I recommend this book to anyone just starting to use the Drupal Views module, any Drupal developer who is interested in theming Views, and any Drupal user who is just starting to build their own custom modules. The book covers so much terrain in the first 3 chapters it's a definite must have on anyone's Drupal bookshelf.
Chapters 4-8 of Green's Drupal 6 Attachment Views contains the brunt of discussion and tutorials on building Views to support various content output. These chapters will give developers a good amount of practice building Views since Green emphasized rebuilding a View for the practice vs. simply exporting and importing your View code. I agree with this method. It might be easier to export and import your code but you'll start to understand the inner workings of View arguments and relationships if you build them from scratch each time you need to configure one.
In chapter 4 Green shows us how to override View settings so your attachment View does not conflict with your page or block View. Green also points out here that we can configure Views for multiple audiences and target the View to specific roles such as anonymous users or logged in site admins. In this chapter we create a management role-based View for our admin users to access.
In chapter 5 Green shows us how to create complex Views using attachments to display Bio content of our company's employees. He returns to a discussion of theming showing us how to theme the output of our View, this time focusing on theming content to surround and display next to an image. View relationships are introduced in this chapter so that we can filter specific jobs to specific project managers who are in charge of the job — this is based on using a node reference field in our content type. Again a nice description and tutorial on how to use CCK fields in our View output.
I'll stress here that the entire book (but mostly in these Views intensive chapters) contains a nice balance of screenshots and descriptive text. The screens are important as it's always nice to have the visual aid to accompany the tutorial bullet points and instructional material. In chapter 6 we create another complex 3-view composite display similar to the one built in chapter 5. Again Green stresses practice makes perfect when it comes to using and building Views in Drupal.
Chapter 7 contains a interesting take on how to enhance and theme a simple "About Us" Web page. I liked the use of Views in this chapter to make a basic Drupal page more dynamic and interactive. Green's expertise is apparent in this chapter as he takes something so basic and static and turns it on its head (and takes it completely out of the box) to show you how you can engage static content better by building it using the Views module. This chapter is a gem in the book and one that clients should read — it will give clients ideas about how to take static content and make it vital content on their site. About Us pages do not need to be boring.
Chapter 8 focuses on building simple administrative control panel using Views. Again Green challenges us as Drupal developers to step out of the box and build useful and custom management tools for our clients.
Chapter 9 shows us how to build role specific menus outside of Views using the Drupal menu and block system. Green diversifies here and begins the excellent discussion in these last two chapters of Drupal's administrative functionality outside of the Views module which has up to this point been the focus of the book. Green gives a tutorial on how to create a "peek-a-boo" login block. What's that you ask? Read this chapter to get the full rundown — it's functionality that will impress your client — using Javascript and an API. Good stuff here. Finally a discussion of adding a new theme region to your Drupal theme (always good to know how to do) and a final look at the Views module, creating a current Jobs/News block.
Chapter 10 wraps this excellent title up by showing us some of Drupal's core functionality that always ends up on the "punch list" in our projects — stuff like:
* Setting the admin theme
* Enabling clean URLs
* Error reporting
* File system
* Input formats
* Logging
* Performance
* ... and more
Read Chapter 10 for sure and then show it to your lead admin/project manager on the client side since it's a great cheat sheet for administering Drupal.
Green had published an opus here on Drupal Views and Drupal 6.x in general. I'll enjoy working through this book in more detail and practicing his Views attachment problems in my own work.
You can purchase Drupal 6 Attachment Views from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
more books (Score:4, Informative)
Re: (Score:3, Funny)
Re:more books (Score:4, Insightful)
It's unfair to call it "charging for documentation." Views is quite well-documented. I figured out how to use it with no documentation whatsoever--it's pretty intuitive all on its own.
I see nothing wrong with writing a popular open source program, then trying to make a little money writing books on how to use it effectively. There's nothing stopping others from writing up tutorials and giving those away for free. And, since the code is available, the author can't possibly keep any secret tricks to himself, to exploit only in the pages of a for-profit book.
This might be a fair criticism for proprietary software, but it doesn't hold much water when it comes to open source, and especially not Drupal modules, which tend to be intuitive if not always well-documented.
Re: (Score:1)
Re: (Score:2)
It is well known that PHP attracts the best programmers. As a result, Drupal has uniformly excellent code quality, especially in contributed modules. It follows that the documentation would also be among the best in the open source world.
It isn't. Many modules are undocumented to the point of being uncommented. And I'm talking about important modules like Voting API. Some of the documentation is great. Some of the documentation is complete shit, and some of it is missing entirely. Some modules seem to be documented only as video tutorials. There's a lot of great things about Drupal, but completeness of documentation isn't one of them.
Re: (Score:2)
There's a lot of great things about Drupal, but completeness of documentation isn't one of them.
It's still the most documented open source cms with this level of functionnality. Anyone who ever read the documentation for ezpublish would agree.
Re: (Score:2)
Your mileage may vary, but I've used a lot of CMS software, and I've Drupal to be the best balance of power and ease-of-use. It's ridiculous how extensible it is, yet I don't find maintaining it daunting or confusing. It all makes a reasonable amount of sense.
Re: (Score:3, Insightful)
>I'm somewhat against people writing open source software and then charging for the documentation.
I could agree with your statement IF the following condition were TRUE: ... that third parties were prohibited from creating or sharing documentation.
This isn't true, so I strongly feel your point of view is misplaced and not correct.
It IS fair to say that Views is difficult for users who are not well familiar with databases. Views is a simple concept - get access to the raw data fields that make up content
What's the URL of the example site for the book? (Score:2)
There is mention above of a client site being used as the example for the book, but no mention of what site it is. I'd like to see that site to help me decide whether I'm interested in the book or not - anyone know what it is?
Re: (Score:2, Funny)
Re: (Score:2, Interesting)
What are attachment views for? (Score:3, Interesting)
It's too bad your review didn't give us any idea of what an attachment view is [logrus.com], or even how it differs from a regular Drupal view [agileapproach.com].
yet another book on a specific aspect of drupal! (Score:1)
Having invest 300hrs+ in drupal 6 and having a bookshelf of some 15 books on specific aspects I remain disappointed by the sprawling architecture and lack of cohesion of this product.
I look forward to a book that can bring order to the chaos that i perceive drupal currently to be with its multitude of modules however this evidently is not that book.
On a secondary note with drupal 7 currently in its fifth alpha iteration i suspect this book is designed with obsolescence in mind.
Maybe somehow i failed to drin
Re: (Score:2, Insightful)
"disappointed by the sprawling architecture and lack of cohesion of this product."
Its written in PHP. What the hell do you expect? :o)
Anyway , if you don't like it why do you use it?
Re: (Score:1)
That its written in PHP doesnt make it inherently good or bad after all a dictionary contains the words making up both the most expressive poetry and the simple tabloid headlines.
A Conversation relies upon a vocabulary in common and in my experience(defined above) Drupal fails to clearly define that vocabulary and explain it readily.
It seemed appropiate to the task but I would probably not choose to develop in it subsequently
Re: (Score:2)
I 100% agree. Looks like some web "developers" modded you down though.
Re: (Score:2, Informative)
Using Drupal did a good job of bringing a lot of it together for me.
I only have limited experience with it and joomla (we'll say about your 300 hrs in each), but my feeling with Drupal is the opposite of yours.
I feel that everything is connected ion a way that makes things awesome, where Joomla it was all over the place.
I love how in Drupal everything is simply a node, so I can create products to sell, and using views make some decent categories, create a side-bar with top sellers, create an news feed of ne
Re: (Score:2)
I love how in Drupal everything is simply a node, so I can create products to sell, and using views make some decent categories, create a side-bar with top sellers, create an news feed of new products, etc.
Except that in basic drupal, not everything is a node. For example, taxonomy elements are not node objects unless you install the category module [drupal.org], which is beta code. Users are not node objects, and the user node module seems to be gone these days. Themes and modules are not node objects, though they richly deserve to be. If you want everything to be a node, you need to try The Everything Engine [everything2.com]. And then you need to suffer with mod_perl.
When i used a store module, I am creating products, not content.
Is that why the default menu options created for adding content are in
Re: (Score:1)
Is that why the default menu options created for adding content are in a menu called "Create Content"?
That was a complaint about joomla, in Drupal it is all content (though i guess not users, themes, or modules). I don't know what purpose the theme or module would have as a node though.
With Drupal I guess it's more that all content is content which make me like it, more than everything is a node.
Re: (Score:2)
That was a complaint about joomla, in Drupal it is all content (though i guess not users, themes, or modules). I don't know what purpose the theme or module would have as a node though.
If you want to manipulate a theme or module you use theme or module specific functions. If everything is a node you don't. This is far more annoying in the case of taxonomies and terms, of course.
With Drupal I guess it's more that all content is content which make me like it, more than everything is a node.
I don't really know what you're trying to say. In Drupal, not all content is a node, although the Drupal 6 "way" is to use CCK (since that's integrated these days, at least the basics thereof) to create nodes for all content. This wasn't true in Drupal 5, leading to much frustration in migration, especially for use
Re: (Score:1)
But is a category really a piece of content?
It would be nice I guess to be able to treat a taxonomy page or display page as a node and augment it with CCK (I know I mess around more than I would like trying to get the Term pages to display as i want), but I don't think the distinction between them and content is purely artificial.
I guess i really just need more imagination though, as the everything engine description did not really help me out.
Another thing I like about Drupal is that it doesn't feel like I
Re: (Score:2)
But is a category really a piece of content?
Content as you see it is a node with body text ($node->body). But a category has text associated with it as well, which could well be considered body text (and which is often used as such) yet you can't get it from the node object, because it's not a node.
It would be nice I guess to be able to treat a taxonomy page or display page as a node and augment it with CCK (I know I mess around more than I would like trying to get the Term pages to display as i want), but I don't think the distinction between them and content is purely artificial.
It really is, though. Unfortunately it's the way it was done and it's hard to change now.
Re: (Score:1)
Not to be dense, but would this simpley make the way a category is defined essentially a field type using CCK?
So I could essentially create a content type of taxonomy, and define it using the category field type, making it work more the way i originally claimed it did?
Also, with CCK being integrated into core, it could very well move in that direction I would guess.
Re: (Score:2)
I wish more module developers would use more specific class names so I can customise things easier. I've got dozens of
Probably approaching it wrong (I usually am) but adding a simple '
Re: (Score:1)
I've been using drupal for the first time to design a site fully from scratch (rather than just using a theme) and I'm both impressed and frustrated by it.
"Impressive and frustrating" should be the Drupal motto, and I say this as a guy who's largely happy with his two-year-old migration to the swiss army beast. (http://mgoblog.com) I'm hoping 7 hammers out 50% of the frustration -- seems like it should -- and am looking forward to the day nine months after its release when all my modules are ported.
Re: (Score:2)
Probably the outer element contains some sort of class name. So you would have to go with css like .modulename_element div h2{
font-weight:bold;
}
which would by the way make your css dependent on template changes.
Re: (Score:2)
Drupal? (Score:3, Funny)
I thought that tranny's name was RuPaul.
Wait 6 months... (Score:3, Interesting)
... and he'll be able to write the definitive guide to Views in Drupal 7. CCK got integrated into the core, but Views didn't. I suspect getting Views ported is going to be a pain.
Re: (Score:1)
Re: (Score:1)