apologies if this has been answered--this seems like a common enough problem, but i didn't find anything.
in a drupal 6 view, i need to find other nodes that reference same node as current node, sort of like sibling references. this is for a student/parent directory.
the view is a list of students (one content type), the parents per student ('parent' being another content type, node referenced from the 'student' type) and the siblings of students (the stickler)--these are 'student' nodes that share the same 'parent' node references.
something like:
student | parents | siblings
--------------------------------------
jane d. | mom. d, dad d. | jeff d.
jeff d. | mom. d, dad d. | jane d.
any help is appreciated.
in views you should use Relationships and View arguments (if required).
via relationships, you can set your rules (parent > student). Also, please bear in mind that if you're using relationship and want to access related nodes' fields, in display fields, you should choose use relationship, so it will print fields of related nodes, not the parent one.
Hope this helps. Don't hesitate to ask more, I will be glad to help.
Related
We have a requirement to delete certain products from everywhere in hybris (including cart, orders, promotions) and all its references as well like Media, Category, Stocks, etc.
I found this one solution:
REMOVE Product [batchmode=true];itemType(code)[unique=true]
;Product;
I was wondering if just deleting the product, would remove all its references from hybris, or is there any better solution to do this.
Any help is greatly appreciated!
Removing the product will remove references to it, but not the objects which are refering to it (like Media, Category, Stocks, etc.)
The only objects which will be deleted are those refered by attributes with the partOf modifier.
A Part Of relationship between two classes extends an aggregation
relationship by ensuring that the lifecycle of the dependant object
(the part) is bound to the lifecycle of the parent object. When you
delete the parent object, all instances of its attribute types that
are marked as partOf will then be cascade-deleted.
Hybris doesn't know if a Media or a Category is no longer needed after a Product is removed. Therefore you must delete those objects explicitly.
Removing product will remove only instances of product type, but not all data like media.
To remove from cart : it should inform user that product no longer available in store
For successfully placed orders : you should be able to display basic details of product with message as in cart [ :) :) But you should deliver if order is placed successfully and payment is received otherwise its a bad eCommerce impression]
For promotions : you should remove all promotions related to this product Or reconfigure according to business need.
I have two classes Person and Vehicle having owns as relation between them.
There is 1 to many relation between them like one person can own many vehicles. Person has attribute 'name' (person name) and vehicle also has attribute 'name' (brand name).
Question is how to model this in OWL using protege editor?
If there is an attribute on 'owns' relation saying 'DateOfPurchase' how to represents this in OWL ?
If there is an attribute on 'owns' relation saying 'DateOfPurchase'
how to represents this in OWL ?
If that's the domain model, then the UML doesn't capture it. What you're describing is that there's an Purchase or Ownership entity with some additional attributes, more like
+--------+ +-----------+ +---------+
| Person | → * | Ownership | → | Vehicle |
+--------+ +-----------+ +---------+
| date |
+-----------+
This is essentially the same approach that I described in your earlier question, Can OWL punning help in defining data properties on object property?. There's no way to "sneak in" metadata about a relationship; you must make it explicit.
Object properties in OWL describe relation between individuals, not between classes. It is a "borrowed" URI, nothing else. So, what you need is to reify each statement such as :PersonA :owns :VehicleB. RDF allows that, however Protégé does not. So, here's a workaround:
You create two object properties :hasSubjectOfOwns and :hasObjectOfOwns, and for each case you need to describe dateOfPurchase, you define an individual representing the statement, and assert :
:AownsB :hasSubjectOfOwns :PersonA; :hasObjectOfOwns :VehicleB; :dateOfPurchase "2014-10-01"^^xsd:date
Initially you'd need to create a property chain, which in Protégé would look like that:
inverse (hasSubjectOfOwns) o hasObjectOfOwns SubPropertyOf owns
I need to do a many to many relationship in my first Access 2013 web app.
I have a Parents table and a Students table. Each student can have two parents and each parent can have more than one student in the school.
Thinking like a seasoned Access desktop developer I took the usual route of creating a parents_students table to link the other two then hit a wall. How do I make the view show the relationship?
I found this topic: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/ccda03e3-a57b-4128-be72-f469c8ec30af/access-2013-web-app-handling-many-to-many-relationships?forum=accessdev
When I tried it, it is not doing what I want, or I am doing something wrong.
Seems like a very fundamental thing to be able to do.
Got an answer over at the MSDN forums. Link Here
Create a Parents_Students table with three fields
ID: AutoNumber
Student: Lookup the name field in the student table
Parent: lookup the name field in the parent table
To the Students View, add a SubView and add a tab called Parents. In the Data parameters set the Data Source to the Parents_Students table and the related field to Student.
Repeat the same procedure on the Parents View but use parent as the Related Field.
Using the node api i would like to create an array of children nodes.
for example in the menu say i had
Sports
Football
Cricket
How can i list these in php
Assuming you want your hierarchy to be managed from a Drupal menu, you can do this:
start with:
$data = menu_tree_page_data('menu-name')
The children live in the data in something like this:
$data['LONG-KEY MENU-NAME MENU-ID']['below'])
I usually do a little print_r($data,true) to identify the actual key of $data where the children live.. the key naming structure is a little odd to me.. it's not terribly intuitive.
There's a lot going on in the data array there.. more than you need to get an array of children nodes..
I've got an in-depth blog post on this (but geared toward menu implementation rather than a node api list of nodes..) here:
http://www.trevorsimonton.com/blog/sub-menu-children-menu-items-block-menu-children-blocks-sibling
I need to create a somewhat advanced search functionality for my Drupal 6 site. I have a one-to-many relationship between two content types and need to search them, respecting that relationship.
To make things more clear...
I have content types TypeX and TypeY. TypeY has a node reference CCK field that relates it to a single node of TypeX. So, many nodes of TypeY reference the same node of TypeX.
I want to use Views 2 to create a search page for these nodes. I want each search result to be a node of TypeX, along with all the nodes of TypeY that reference it. I know I could just theme the individual results and use a view to add the nodes of TypeY to the single node of TypeX... but that won't allow users to actually search TypeY... it would only search TypeX and merely display some nodes of TypeY along with it.
Is there anyway to get the search to account for content in nodes of both content types, but merge the TypeY results into the "parent" node of TypeX?
In database terms, it seems like I need to do a join, then filter by the search terms. But I can't figure out how to do this in Views.
Thanks for any help i can get!!!
'**** EDIT '****
To make sure this is clear, here's a visual example of what I'm trying to do...
_____________________________________________________________________________________
|Type X Node |Type Y Node |
| | |
| Content in node of TypeX that gets |Has a node reference that points to the node |
| searched by the view... |of TypeX. This content gets searched too! |
| |_____________________________________________|
| |Type Y Node |
| | |
| |Another TypeY node with a node reference to |
| |to the TypeX node. This gets searched too! |
--------------------------------------------------------------------------------------
This would be a single result from the search View. They content in all three nodes would be considered by the Search : Terms filter in the view. So if I searched for "This gets searched too!", I would get the above result. Or, if I searched "Content in node of TypeX", I'd get the same search result above.
I know I could search for TypeX and load up the TypeY nodes in the result display using another view, but it wouldn't search the content in the TypeY nodes.
Any ideas... short of rolling my own search functionality (not something I'd like to do at the moment)?
Wow, just wow. I finally found an elegant solution to this problem. I can't believe how simple it turns out to be!!!
I won't take credit for the solution... I stumbled upon a great blog post that answered this question completely (wasn't even looking anymore!). The article is by a guy name Davy, and he's my new hero.
The article is here: http://www.drupalcoder.com/story/667-improving-search-results-when-working-with-node-references-in-drupal
He also wrote a follow up article that simplifies the process even more!! http://www.drupalcoder.com/story/696-a-better-alternative-for-improving-search-results-when-working-with-node-references-in-dru
It turns out the good folks that wrote CCK had already thought of indexing a referenced node's content. In the Display Fields section of editing a content type, click on the Search option! It lets you determine how the referenced node should be indexed when the parent node is indexed... and you can set it to full node. This will index the full contents of the referenced node as part of indexing the parent node. The only thing left to do (which Davy explains) is to make sure the parent node gets reindexed whenever a referenced node's content changes.
Provided you can get your view to a point where it is searching both content types, I think this actually does become a theme issue. You could override the various theme templates for the view and organize the returned array of nodes in a particular way. You could also simply omit content type Y from the list during output and theme the content type X node to list the nodes from the CCK node reference field (this would be similar to what you mentioned, but you'd still leave content type Y in the view query and omit it during output). There might be some performance implications depending on the amount of content type Y nodes per content type X nodes there are.
I think no matter what you end up doing this will be a theme issue albeit a complex one.