I am reading the spree code source and I am wondering why there is a model Taxon and a model Taxonomy.
According to the Spree documentation:
Taxonomy – a hierarchical list which is made up of individual Taxons.
Taxon – a single child node which exists at a given point within a
Taxonomy. Each Taxon can contain many (or no) sub / child taxons.
As Taxon can have many taxons and taxons can have children. Why there is a need of the Taxonomy model? Is this due to performance?
(NOTE: I am not sure this is the right place to ask as it's not really code related issue)
Thanks for your explanation
A taxonomy is representative of the root node. It provides the over-arching classification for a set of items. For example, "Clothing" could be a taxonomy (with a root "Clothing" taxon) and then underneath that root there would be other taxons like "Pants", "Shirts", "Shoes" and so on.
There's no particular reason why we have both taxonomies and taxons other than that's the way it's always been and to change it right now does not leads to any particular benefit.
I haven't worked with Spree in a while, but if i remember correctly, then Taxonomy represents an entire tree, whereas Taxons are the nodes that make up that tree.
A possible reason for this is that a product can have more than one taxon. This way for example a product can have a brand taxon and a range taxon and a size taxon on a color taxon (assuming not set as a variant), allowing multiple selection pathways for a product.
Related
I have a use case where I have a 'web' with the following relationships; what's the best way to model this in Django?
There is a logical top layer (could be modelled as a single 'very top' node if required)
There are logical leaves at the bottom
Nodes can have relationships to nodes in the layer above and/or below but never to siblings
So like that chinese game with a coin dropping through pins, there are multiple routes from top to bottom but a traversal will always work, albeit in some manner determined elsewherre (actually user input in my case).
I have tried using ManyToMany relationships but can't see how to spot the top and bottom of the relationships; do I need to switch to many OneToMany relationships for independent child and parent relationships?
I don't think you can make this kind of graph explicit in the data structure, but you can enfore it with semantic actions in the creation/update of nodes. Let's say you have a model of a Node:
class Node(models.Model):
connections = ManyToManyField(Node)
layer_level = IntegerField(null=False, default=1)
In the constructor and the magic setter __setattr__ you can then check if the connections of the node all have a layer level greater or less than the node itself and raise an exception if they're equal. I admit that it's possible that in Django "interjecting" the setting of fields of a model instance is more complicated than overriding the __setattr__ method, but that's beyond the scope of this answer.
The point is that you can set up a model that your desired structure but with less restrictions and then enforce the restrictions on creation/update, rather than making them implicit in the model structure. The latter would be a better solution, but also one that is likely not possible with relational databases and/or Django's ORM.
Is it possible to choose only specific items from the list in selectOneMenu?
For example. I have List Products has many fields like name, id etc. One of it is category (1,2 or 3) I want to have only one category in the selectOneMenu without making new Lists and new classes. Can you help me?
I think the easiest way is to set the value attribute of f:selectItems to a method which filters your original collection.
Otherwise you'd have to implement your own version of f:selectItems which allows filtering - as we once did in one of our projects.
I'm working on a C++/Qt project. I have two business models (one is a hierarchical tree-like structure, i.e. film categories/sub-categories, and the other one is a simple vector, i.e. film titles which can belong only to a subcategory) and I want to display both in a unique tree-view, where leaf nodes can belong to both models and non-leaf nodes belong to the first model. In addition to this view, I also want to display in model specific views, a tree-view for the first model and a list view for the second one.
I've considered 3 approaches:
1) Create one QAbstractItemModel for each business model and another one to represent the mixed model. Thus, each view is associated with only one model.
2) Create only two QAbstractItemModel for each business model and implement a special view that deals with that information.
3) Use a QStandardItem model and implement subclasses of QStandardItem for both my business model elements.
Because I'm working with external data, I don't want to duplicate any information if possible.
What do you think is the best/proper approach to follow? Any implementation advices?
QDataWidgetMapper is your best bet in that one.
Make one model of your data. I would make one tree model, which is option c of your choices, but could be implementing your own tree model.
For the list view, see if you can't set the tree model on it as well, and use setRootIndex to only show the list of items you want to see. I know it works on table and tree views, so I assume it would also work on a list view.
Given the following content tree, how could I associate Dealerships with Cars so that I can get a URL like this?
http://website/Dealerships/JimWhite/Ford
I need to be able to have the content viewable and editable under cars, but automatically updated under the dealerships.
I assume there is some kind of link I can do?
Home
Cars
Ford
Honda
Toyota
Dealerships
JimWhite
TomJones
Take a look at this document on SDN, especially the chapter about Sharing and Reusing Items and Field Values (Aliases, Proxies, Wildcard items).
I think you should look into aliases on the SDN.
My Item Mirror module might do the trick.
http://blog.capaxsolutions.co.uk/2010/06/09/sitecore-item-mirroring-making-an-item-appear-in-more-than-one-place/
In my content tree, I have a tree of content items which represent cities. For each of those I want to have logical connections to a set of... let's say... National Parks that are within 2 hours driving distance. So a city will have multiple parks... and each set will be different... but of course a park will also be associated with more than one city.
What kind of Item and field setup works well for this sort of situation? I will be creating a custom renderer for these items, so I'm mostly concerned with how this should look in Sitecore to maximize ease of use and performance.
I'm using Sitecore 6.2.
(cross-posting from SDN, please forgive me... but I want to encourage more Sitecore community here on StackOverflow)
For this kind of relationship you'll need the following structure:
Home
Cities
NY
London
Paris
Parks
Park1
Park2
Park3
The "City" template should have the Multilist type field called "Parks". The soulrce of this field should look to the root of Parks (Home > Parks). The same way the "Park" template has the Multilist field called "Cities". The source of this field should look to the root of Cities (Home > Cities).
In this way you'll be easily able to perform any kind of request.
Hope this helps.
If the connection has to be both ways one way you could handle it is by adding some code to the save event.
Let's assume we have a City template with a field called "Related Parks", and a Park template with a "Related Cities" field.
Say we save a City item with two parks in the "Related Parks" field. On the save event we could retrieve the two parks and insert the current city being saved into the "Related Cities" field on those parks.
I am not necessarily saying this is the best way to go about it, just another option.
Are you going to be doing any lookups from park to city? For instance, would you need to say "find all the cities that are associated with a given park"? Or will it just be "find all the parks that are associated with a given city"? If you need to do the lookups in both directions, things get a little trickier and I would probably recommend using a search index. However, if your lookup is only in one direction, you could just use a treelist field to make associations from one item to many others.
From your description I'm not entirely sure if you actually need to use that many-to-many relationship, or if a one-to-many path is all you need?