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!
Related
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 have two fields: Supervisor and agent in a new content type. The list of agents depends on the supervisor selected. How can I create such a dependency i.e. each time a different supervisor is selected from a list a new list of agents is set?
Do I need to set up the supervisor and the agents each as nodes and then use entity reference?
How can I set up the dependency in the content type?
Cannot ask for clarification since I'm new here but here goes
Taxonomy terms can be a solution to the problem depending on the amount of information Supervisor and agent holds. If they hold information like phonenumbers, adresses, names etc. then they need a content type. If these are in fact references to users in the system then you need to use those users. If it's just for categorization, taxonomy terms will work just fine.
Set up the Supervisor as the parent term and the agents as children. Then use a widget like this one to handle the input: https://drupal.org/project/term_reference_tree
Afterwards you can retrieve and show data based on which term/agent is relevant.
I need to create a fairly complex rule in Drupal - I am willing to use either code or the interface to do so.
I am more familiar with the interface, however, as opposed to the Rules API.
Anyway, the rule will be as follows:
It will happen based on a form submission from entityforms (which is one entity). It will take the checkbox value of a field (not just the true or false, but rather the value submitted when a value is true or false). It will convert this number to an integer.
At this point things get interesting - I want to create a new entity of registrations (a different entity), which as far as I can tell, means I'll have to bring a registration into scope. I also need to bring node (and not just node: type and other data selectors, but specifically node) into scope, because the next step requires it.
So at this point, I should have three entities loaded into scope:
entityforms
registration
node
I believe the best way to bring registration into scope would be entity is of type? The documentation page says that content of type should be appropriate - but that seems like it might be related to the specific use case of the example - not in my more complex example where registration isn't the first entity dealt with, but rather a second.
https://drupal.org/node/1463042
So anyway, if all three of these entities is called in correctly, the ultimate result should be the following:
Value from boolean field (not the straight 1 or 0, but whatever the value to be submitted is switched to) from the entityform is converted to an integer, and inserted where entity host ID is required. In the section where host entity type is the value should be node.
I am also open to alternative suggestions if this seems overly complex or poorly architected.
The Host Entity Type cannot be of Entityform? Why be a Node since a Registration can be attached to any entity? Then you will get the id of the Entityform as also as any other fields from that entity type instead of Node. Next steps are the same.
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).
I am trying to write a relationship handler for Views 3 in Drupal 7, but am failing even to begin.
Basically, I have a bunch of nodes of various types all with the same field attached to them. This field is a reference field linking off to a Civicrm contact - but that's not important, as essentially these fields just contain integers.
Now, let's say I have a node of content type 'story', and its reference field contains the integer, oh, let's say 55. In addition, there are nodes of content type 'news' which also contain the reference ID 55.
I want to build a block view, that sits on the story page, that reads in the node's nid as its argument, and then through a relationship it discovers all other nodes that contain the same reference integer as itself.
(In my head, the sql looks something like: SELECT n.nid FROM node n INNER JOIN node n2 ON n.reference = n2.reference [Assuming, for the sake of simplicity, the field data is kept in the node table]).
How do I create a Views handler that caters for this relationship? The only documentation I can find is the views api, which is for version 2 and not 3, and besides is utterly unhelpful. Reading various module's views handlers is not helping either, and views tutorials on the web are almost non-existent.
What are you doing and what is the problem? It sounds like you have everything you need right here...the nid as an argument and the reference field as a relationship. What are your filters set to? and what display type are you using? You could just have the block display some information without sorting, arguments, or relationships and then using the devel module you can change the tpl file for the block to dpm($views) and see what information you have access to.
Let us know what you have configured so far and what your results are if any. Remember that you can use the nid as an argument in the preview, so if the nid is 213 you can type 213 in the preview field (make sure the display is set to the block you are talking about) and see what comes up.
Good luck.