What are the benefits of reusing an existing field for a content type?
Alternatively, what are the benefits of making a new field for a new content type?
For example, I have a content type called 'Book Review' with a field labeled 'Summary'. I'd like to create a new content type called 'Movie Review' and also give it a field called 'Summary'.
Benefits of reusing an existing field
One table(in fact 2) less in your database and hence the performance gets better.
Say when you want to display the summaries of all the content(irrespective of content type), reusing the existing fields will make your queries simpler.
When you are using views for the displays you just need to add one fields instead of different fields for each content type. Say you want to display summaries of both Book Review and Movie Review, you can just add both to the content type filters(or) and add the single common field.
When you are overriding the template files, you just need to overwrite one template instead of many.
Benefits of using different(new) fields
If both the fields has to be displayed separately, then you can have more control.
If there are very large number of values in your fields, then instead of querying a single table with 1 lakh entries, you will only need to query a table with 50,000 entries. This might add to your performance(But am not very sure, can be case specific)
My preferred choice
Reuse existing fields when it makes functional sense. For example I generally reuse noderefernces to the parent content type so that it keeps most of my queries simple.
In your user-stories if it doesn't make sense to reuse then better go for the the new fields.
Reusing same field - Let you handle the field at one place. Code handling + theming.
Making a new field - summery is not a good example, since you have a built in text area given by Drupal. Adding an image field with the same preset size for both (movie & book) will give you the ability to show images on each content type and let them look the same if you want (without double work).
Related
I have a content app with a dominating unique field that I would like to use as the node name for new nodes. The problem is that it contains characters that cannot be part of a JCR node name, and thus if I were to link it to jcrName rather than a custom property it will get mutated into something that isn't useful for the fields original purpose (among others, the field value will contain slashes).
My current solution adds an additional field for the node name, and while this certainly works, it adds a UI field to the detail for no reason that is apparent to the users of the app.
Is there a way to have a field that reads and writes a string value to a custom property, yet that is also used (in its clened form) to name the node?
You could use this as a base, paying special attention to the code in 2.b.ii. (especially setNodeName), and ignoring the yaml bits.
I hope this helps!
i have the following case: I am building a website that has information on filmmakers and their films. I have a node type for the filmmaker, with biographical content, etc and another one for the films, with a field 'author' that references one or more of the filmmakers (since one film may have been made by several of them).
I also have a views block called 'filmography' that lists all the films whose author is the filmmaker (node) the user is seeing. Setting this up with a contextual filter was quite easy.
But now I want to present in this block along with the film name, all the filmmakers that may have made the film ('author' field in the film node) and that are different from the filmmaker being viewed. Displaying all the filmmaker nodes referenced by the author field is immediate, but I want to remove the filmmaker that I am using in the contextual filter. The goal is to get something like this:
Filmmaker 1
Movie 1
Movie 2 (with Filmmaker 2)
Movie 3
I have the notion that this might be done using views php and filtering the node references returned, but I wonder if there is an easier solution for that...
Thanks
Update: I have managed to get a result using the Views Field View module, passing the list of referenced nodes (filmmakers) as a contextual filter (node ID) and then adding another contextual filter (node ID as well) as an exclusion, and getting the default value of the letter from 'node id from URL option' (that is, from filmmaker's page the filmography view is embedded in). Keeping the question open for a while to get other, possibly more efficient, alternatives.
As I read your question, the Views Field View module popped into my mind as the obvious solution (then I saw your edit). I think this will still be your best bet. Definitely avoid using php fields as that is not a good practice in general from a security standpoint. If you are concerned about efficiency/performance, then you should just use views caching setting under the advanced options. Seems like this option is always looked over.
If you are looking for alternative options, one might be to use rendered nodes as your View style instead of fields, then use Display Suite to generate additional display modes beyond "Default" and "Teaser," create a view with the filters, then use the Entity Views Attachment (EVA) module to insert a view as a display mode field. While this is certainly a robust approach, it adds a lot of processing overhead with the rendered entities, so you definitely want to cache the results of that as well.
p.s. You might get faster/more responses over at https://drupal.stackexchange.com/
I know it is possible in plone to create content types with their own fields.
So, is it possible to create a collection with those fields?
I'm not sure what you like to achieve, but to answer your question:
Yes it's possible to create a collection based type with your own fields.
If you are using the DX based collection type of plone.app.contenttypes you can easily extend it. You also have to register your own view template, which takes care of the new fields.
Of course it is also possible to create a completely new content type.
Check the Collection FTI of plone.app.contenttypes
You also need some basic knowledge about dexterity
If you ment to extend the possibly choosable criteria of collections by any field-names of your portal's contenttypes and you are using the old-style collections (type_name=Topic), you can do like this, to add any of these fields as a choosable criterion to (old-style-)collections:
Make sure, the field is registered in the portal_catalog, which you can check by accessing http://yourhost.com:8080/Plonesitename/portal_catalog/manage_catalogIndexes. If it's not already there, you need to add it via the dropdown-selection in the upper right corner, choose "Field Index".
Make sure, the field is registered in the configuration of collections, which you can check by accessing http://yourhost.com:8080/Plonesitename/portal_atct/atct_manageTopicIndex. If it's not there, click on "All fields" in the upper right corner, search for the field-name and check the radiobox to make it available, save.
In newer Plone-versions the old-style-collections are disabled by default, you'll probably need to enable them via http://yourhost.com:8080/Plonesitename/portal_types/Topic/manage_propertiesForm, check "Implicitly addable", save.
I am currently trying to create a custom post type for recipes. My goal is to include the schema.org/Recipe and or hrecipe microformat and also have the ability to filter for ingredients in the future.
To do this I intend to have an interface with fields for title, photo, description, ingredients and instructions.
My question is: Should I create separate fields for each ingredient and each amount? Or would you say it is sufficient to just create one field for all ingredients? (also keeping the aforementioned microformats in mind).
http://schema.org/Recipe
http://microformats.org/wiki/hrecipe
Having ingredients as a single field is what is expected in both formats you linked to. Querying / filtering based on ingredient name will be slightly more complex...but you should be able to handle it.
There are 3 parts to this answer.
How should you save ingredients in WordPress
How should you allow users to modify the ingredients list
How should you display ingredients publicly
For point 1, you will have to give a bit of thought as to how you save the ingredient list and how you retrieve/display it along with how it is queried. One of the formats indicate you could have properties for each ingredient (still in draft).
You could save an ingredient list as a serialized PHP array, something like this:
$ingredients[]=array('milk','value'=>'125','type'=>'ml');
$ingredients[]=array('sugar','value'=>'1','type'=>'cup');
Since serialized PHP arrays are standardized, you could fairly easily write an WP query that takes it into account.
Keep in mind you will want to have a plan for when the 'value' and 'type' modifiers are set in stone and how to migrate what you saved if they are different.
For point 2, you could create a custom meta box that deserializes the PHP array saved and render individual controls for each ingredient along with controls to allow management (Add, Deletes, Updates).
For point 3....the easiest would be to get the value and manipulate it how you want in the output.
I am developing a custom content type by using CCK and new module as described in
http://drupal.org/node/1044248
Besides the standard fields, it can have 1 - N additional fields.
N is dynamic.
Instead of creating, say 5 pre-defined fields, I would like to support N fields, which the user can add as many he/she wants.
Is this possible to do using CCK in Drupal 6.X? Or, can it be done via any other way?
Thanks
Did not realise there was a property for selecting number of fields with unlimited option that can be selected - thought it might help who might have overlooked that field.