Currently I have 33 custom content types, each with just a few fields (6) of no great length. Each, for now, has a one page display (path, no menu) associated with it. I hide all the fields but one and in the last field present the fields through View's token mechanism and toss some divs and style around them, along with a a few paragraphs of extra text.

In order to do some things in mind I had to create two views per content type. (One view is a page display per cck and another view is used strictly as a filtering mechanism for locating related nodes in another content type.)

1. I guess one of my first questions is along these lines: http://drupal.org/node/144898 maximum number of Views

Related to that is my main question.

2. I read that theme functions serve content significantly faster than using tpl.php files. http://drupal.org/node/173880 Is views, in the same way, or similar manner, faster than using tpl.php files to serve for each content type? Or are using tpl.php for some reason a speed advantage?

My guess is there are numerous trade offs, but for the time being, since I'm on a shared host… timeouts are a bummer.

According to my calculations :-) 66 views now, but the "logical progression" of the current approach would mean over 200 additional views.

3. Is my main "penalty" a few megabytes of additional views definitions being stored in the database, as well as possible bits that Views might cache?

TIA!

Comments

dawehner’s picture

dawehner
Primary language German
commented

since I'm on a shared host… timeouts are a bummer.

It would be much cheaper, if you don't spend your time in such questions, and buy a better webspace/server. I think its only worth to think about it for high performance / very big sites.

Currently I have 33 custom content types, each with just a few fields (6) of no great length. Each, for now, has a one page display (path, no menu) associated with it. I hide all the fields but one and in the last field present the fields through View's token mechanism and toss some divs and style around them, along with a a few paragraphs of extra text.

So its right, that you are using views for something like theming? This is not the way you should to it, use better a custom node template for each node-type. Views is a list builder, not a single item builder :)

Is my main "penalty" a few megabytes of additional views definitions being stored in the database, as well as possible bits that Views might cache?

The views are stored as a cache, i think you shouldn't think about it. There is a problem with many many views using argument validation. This causes to load many views on every page request, there is an issue about this.

Bairnsfather’s picture

Bairnsfather commented

Thank you. Basically, in my vision of the future, the first version of my "dream page" would be like this:

The content type contains some meta data fields but for the most part exists for one small filtered text-edit field, which is generally less than 1000 characters.

Besides the stock Drupal "View" tab/page which shows the node and its handful of fields, clicking on the 2-Side-by-Side tab (or sidebar link) would cause another view to be displayed without reloading the page. That view would show the user's main paragraph next to a static paragraph.

At some point I'd also like to allow there to be side-by-side comparison with other people's nodes of that type, the Views module seems great for this too.

As I stumble towards my vision of the future it seemed that, at first, I would just use Views to create a path (node/%/pc_01), show the particulars of that node, AND show the static text in a side-by-side display.

I considered making tpl.php for each node type, but in my vision, the main node should be able to be viewed in more than one way (stand alone, side by side with static text, side by side with nodes of same type from other users, etc).

So at least I know I don't want to bring the customizations to node-type.tpl.php, but instead work them in to page-type.tpl.php. But for the time being I've not done this since I am still learning php and am not all that clear on printing $node's specific fields I want to access.

So its right, that you are using views for something like theming?

Not specifically. I was not using Views to build lists, as you seem to indicate I should stick to doing when using it, but I was using it to create "views" of my nodes. :-)

I take a paragraph field from the content type and display it next to an unchanging corresponding paragraph. Each of the 33 content types has a different chunk of text to compare. Also, I didn't necessarily want to show all of the fields of the content type. And in order to show the paragraphs side by side instead of over each other, I knew I'd need to add some simple styling.

View seemed perfect since it offered a page display with its own path,
node/%/pc_01
node/%/pc_02
etc…

But you seem to indicate I should not create 114 views for the next batch of content types I have in mind. :-) Thanks for the heads up.

My challenge is to create a page template that is not always in effect for that node type. In other words I want the node to be seen as the single node it is, but also offer it side by side to static text (at first, later show it next to other nodes).

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Fixed 

Not specifically. I was not using Views to build lists, as you seem to indicate I should stick to doing when using it, but I was using it to create "views" of my nodes. :-)

You can find many examples that this is basically a bad idea! One here :)


But you seem to indicate I should not create 114 views for the next batch of content types I have in mind. :-) Thanks for the heads up.


My challenge is to create a page template that is not always in effect for that node type. In other words I want the node to be seen as the single node it is, but also offer it side by side to static text (at first, later show it next to other nodes).

Use panels for such stuff. It does what you need much much better. Additional i would suggest to look at "node display" module once.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.