I know it is possible to create custom facets from a document property, and it works well.
But is it possible to create a facet based on the node type title ?
With the following standard model, there would be a facet with values named Folder and Content.
<type name="cm:folder">
<title>Folder</title>
<parent>cm:cmobject</parent>
<archive>true</archive>
...
<type name="cm:content">
<title>Content</title>
<parent>cm:cmobject</parent>
<archive>true</archive>
<properties>
...
This is going to be an Alfresco platform focused answer rather than a share oriented answer.
It is possible to facet on the TYPE field.
This will be the QName of the type (e.g. cm:folder).
The title you really want to display will be language specific so should use this as a key for localisation.
So, you can do the roll up via the API but would have to customise share faceting to display the correct thing. I believe this is possible as share faceting is extendible and configuration driven. I also suspect it is not easy to do and configure - it is not something that is normally changed.
You may also want some structural roll up as TYPE is a hierarchy. You would have to use the data model to do this.
It may be that TYPE is already in the facet list ...
It may be that content mimetype gives you more information and is a better choice. Most people do not strongly type documents (which would be a good thing ...)
Andy
Related
I've been trying to wrap my head around authoring profiles in FHIR. The trouble I'm having is around the use of using extensions.
The documentation talks about extensions as if they are simply just there to extend existing elements of the resource which a profile belongs to, this is kind of confirmed to me when using forge because I can add new elements which don't have extensions.
It feels very foreign to me as in our proprietary storage system, we have the equivalent of profiles, and they have properties about them (which I think are similar to elements in fhir), however a property is only designed to store one type of thing; e.g. you might have a patient profile that has the properties DOB, ethniticy, identifier, etc. I don't really understand what profiles are for in the context of fhir, are they similar to my properties? Can I use the to limit the datatype that a profile instance can have for a particular element?
Is there any better documentation than the spec? I'm finding it really hard to get to grips with.
FHIR extensions are used to be able to enter extra data elements, when there's no field for that in the standard definition. Mother's maiden name is an example of that for the Patient resource.
The use of an extension is a standard FHIR mechanism and will always look like this:
<extension>
<url value="http://hl7.org/fhir/StructureDefinition/patient-mothersMaidenName"/>
<valueString value="Williams"/>
</extension>
The url is the canonical url for the definition of the extension, which is a StructureDefinition resource defining the extension and the datatype(s) of the value.
You can have extensions on every level of a resource/datatype.
Since profiling is a very overloaded term, it is hard for me to understand what you're saying about profiles and properties in your proprietary system, or how that relates to your question. But in general, FHIR profiling is needed and used to
be able to add data when there's no data field for it in the specification (i.e. an extension of the specs)
constrain the specification in places where you need to be more strict, for example to make an optional field mandatory (i.e. a constraint on the specs, also called a profile)
I recommend browsing through some of the profiles and their descriptions on the Simplifier repository to get an idea of why people are creating profiles on FHIR.
I wish to extend the person object with additional attributes through an aspect, however several of the aspect properties need to be multi-valued i.e. contain more than one value.
e.g a person's skill set.
How do I achieve this?
What you want to do is define your property with multiple="true" to make it multi-valued. This is detailed in the documentation here.
If you're new to creating Alfesco models, you might find these two wiki pages helpful. The book Professional Alfresco is also recommended, and the modelling section hasn't changed since it was written (though a few other areas have)
I'm building a site with OpenAtrium Drupal installation profile. I want to have multiple content types of "cases" that can be tracked together (obviously they would all share the basic case fields). I'm wondering what the best way to approach this is. Should I make an override module that overrides atrium_casetracker? Should I make a completely new feature?
I've been in this position before. Here's what I recommend.
Create your new feature. Possibly even one new feature per case type if each case has a lot of associated configuration and customization code.
Modify the casetracker_case_node_types variable so your content type is recognized by casetracker as being a case type. You need to do this before creating nodes of your new case type, otherwise you will have migration complexity. (See http://drupal.org/node/734542 to make that better.) **For compatibility with OpenAtrium's Atrium Casetracker feature, modify this variable with hook_strongarm_alter() to avoid creating a feature that conflicts with Atrium Casetracker.
Be sure when exporting your content type that all variables and node options are properly configured and exported with your content type, such as the atrium updates variable and the og usage variable.
If you need to change the default case, you can export CCK fields and other configuration related to that node type in your new feature.
If you have questions on this, please comment and I will update my answer to clarify further.
Let's say
Taxonomy_A is associated to Node_Type_A
Taxonomy_B is associated to Node_Type_B.
AND
Both Taxonomy_A and Taxonomy_B have a term called 'yellow'.
Is it possible to make terms 'yellow' synonymous, so that if I'm looking at a list of 'yellow' stuff, I'm seeing content of both types (Node_Type_A, and Node_Type_B)?
Progress:
Unfortunately it is not possible for taxonomy terms to behave in Drupal as described in my question (at least not without forcing it):
It is clear by taking a look at the terms_related table that it would be possible to create paths that forced related terms together using the taxonomy_get_related function regardless of what vocabulary the term belongs to:
However, the way to get to these terms is through the taxonomy_get_related function in the taxonomy module. This function is not used at all in drupal-6 core except to define it. (I did find it once in the ctools module).
I think you are doing it wrong. I mean using taxonomy wrong, not technically, but as a concept. Ask yourself why do you have 2 vocabularies with term yellow? Both are colour. they belong to same dictionary. Maybe tell little more of what you are trying to make.
Maybe you need to change setup so you don't associate one dictionary to one content type, maybe CCK, views and this module can do what you need http://drupal.org/project/content_taxonomy
I'm currently pondering my options for the following problem:
I have a (relatively) simple but often changing configuration file for my application which I want users to be able to edit and change without have to "understand" xml. I do not want them to have know anything about encoding or understand that they have to close every node they opened. Here is an example of a section in the configuration file (defining facets for some arbitrary search engine):
<section name="facets">
<facet type="format" label="Format" max="4"/>
<facet type="marcfields" Label="Author" max="5">
<mfield name="df100" subfields="abcdjq"/>
</facet>
<facet type="language" max="4"/>
<facet type="pubdate" max="6" submax="8"/>
</section>
Editing this section, user should should be able to re-order the facets, delete facets, configure existing facets or add new ones. So far so good, but the xml is not completely free form and comes with a couple of restriction/structure:
Facets come from a pre-defined set of
types (forkamt, marcields, language &
pubdate above), so when people choose
to add a new one, they need to be
able to choose a type.
Each facet type comes with "parameters" - some common for all types some specific. For example in the above XML, one can edit the label & max attribute for each facet. For the "marcfields"facet, one can add sub-nodes (with two editable attributes). For the"pubdate" facet, one can edit the submax attribute.
I am looking for a way to take my configuration file and make it editable in ASP.NET web environment. All of this would be fine to program, but I except the configuration file to change often and I don't want to have to recode my site for every change. Therefore I'm looking for an open source frame work which can:
Take an XML file with a known structure and constraint (via an XML schema or anything else).
Generate a ASP.NET based editing environment , allowing people to safely manipulate the xml file.
Be very friendly where people make mistakes.
Any suggestions?
How about creating an HTML form using an XSL Transform of the XML file? This way, you can surface the parameters into form fields. Using JQuery, you would even be able to offer re-ordering and the like.
A framework may be a little heavy for this task.