Now really we are not that interested in the class or model when it comes to viewing our data, we only use it to act as a filter for documents (ie give me all the documents for 'model n') or to archive whole series of documents off when a model is no longer available. The document sare what we are really interested in. So my question is conceptually how should I structure our pages? I thought of making it hierarchical as described above but I'm not sure that is the best way to achieve this?
Also as I am mainly interested in reporting on documents should I be/can i extend the main media types library or should they be different things?
Sorry to be a newbie, I'm actually only new to umbraco Lol!!
I've looked at tagging and I dont really think its gonna cut it. In the first instance I dont really need to share documents across models/ranges and in the second tagging is too loose as I need to store properties against the Class/Models to allow me to display their name/image and whether they have been discontinued etc..
Hierarchically my structure looks like this and as far as data entry this defintitely makes the most sense to a user:-
Class
|____ Model
|________Document Branch
|__________Document Types
|____________Physical Documents (This is what I'm really interested in)
I need to be able to select physical documents based upon document type filters, model filters and class filters so theoretically if I was to use this structure saying something like give me all the documents of type 'image' associated with Class 'x' and model 'y' is realtively easy. However asking a question like give me all of the images regardless of the model or class is not so easy as I would have to iterate over the sub branches of each class/model which I dont really want to have to do.
My UI however needs to start displaying the data at Document Branch Level so the menuing system utilises the following:-
Document Branch
|_______________Document Types
To me it seems to make the most sense to say, store all of the Physical Documents in a flattened form thus
All Documents
|_________________ Physical Documents
And on each physical document provide properties (Model/Class/DocumentType) that reference the two distinct branches which are utilised to allow the users to manage classes and their models and Document branches and their document types thus:-
Class
|________ Model
Document Branch
|______________ Document Types
Does this sound like the best way of achieving it? I cant really use either of these as traditional dropdowns as in my instance I need to store properties against them and of course there is a relationship present as well? Which brings me to my second question.... What happened to the ultimate picker? I would have liked to have used this as it allows you to specify a Document Type that can be selected....
I'm open to any other ideas that anyone else may have too.....
Another thing to look at might be faceted search in Examine. It's a bit of a headf**k to get your head around initially, but it allows you to define "facets" on your indexed data that you can use for querying. You might be able to use that on the front end?
Heirarchical Data
Hi all,
Just struggling a little conceptually with umbraco though it looks great. I have heirarchical data structured thus:-
Class contains Models contains Documents (real documents image files, pdfs etc).
Now really we are not that interested in the class or model when it comes to viewing our data, we only use it to act as a filter for documents (ie give me all the documents for 'model n') or to archive whole series of documents off when a model is no longer available. The document sare what we are really interested in. So my question is conceptually how should I structure our pages? I thought of making it hierarchical as described above but I'm not sure that is the best way to achieve this?
Also as I am mainly interested in reporting on documents should I be/can i extend the main media types library or should they be different things?
Sorry to be a newbie, I'm actually only new to umbraco Lol!!
Can a document be in more than one class/model? If so, you might want to look at using tagging to organise your content maybe?
Hi Tim,
I've looked at tagging and I dont really think its gonna cut it. In the first instance I dont really need to share documents across models/ranges and in the second tagging is too loose as I need to store properties against the Class/Models to allow me to display their name/image and whether they have been discontinued etc..
Hierarchically my structure looks like this and as far as data entry this defintitely makes the most sense to a user:-
Class
|____ Model
|________Document Branch
|__________Document Types
|____________Physical Documents (This is what I'm really interested in)
I need to be able to select physical documents based upon document type filters, model filters and class filters so theoretically if I was to use this structure saying something like give me all the documents of type 'image' associated with Class 'x' and model 'y' is realtively easy. However asking a question like give me all of the images regardless of the model or class is not so easy as I would have to iterate over the sub branches of each class/model which I dont really want to have to do.
My UI however needs to start displaying the data at Document Branch Level so the menuing system utilises the following:-
Document Branch
|_______________Document Types
To me it seems to make the most sense to say, store all of the Physical Documents in a flattened form thus
All Documents
|_________________ Physical Documents
And on each physical document provide properties (Model/Class/DocumentType) that reference the two distinct branches which are utilised to allow the users to manage classes and their models and Document branches and their document types thus:-
Class
|________ Model
Document Branch
|______________ Document Types
Does this sound like the best way of achieving it? I cant really use either of these as traditional dropdowns as in my instance I need to store properties against them and of course there is a relationship present as well? Which brings me to my second question.... What happened to the ultimate picker? I would have liked to have used this as it allows you to specify a Document Type that can be selected....
I'm open to any other ideas that anyone else may have too.....
Another thing to look at might be faceted search in Examine. It's a bit of a headf**k to get your head around initially, but it allows you to define "facets" on your indexed data that you can use for querying. You might be able to use that on the front end?
http://thecogworks.co.uk/blog/posts/2013/january/examiness-hints-and-tips-from-the-trenches-part-6/ has some useful exaples on, have a look at that and see if it would help with your structure and querying?
is working on a reply...