I'm migrating content from Archetypes to Dexterity and I need the new items to have the same UID as the old ones.
On Archetypes items I can call context._setUID('my-uid'). Is there something similar for Dexterity?
For Dexterity UUID values, the plone.uuid package is used. plone.uuid simply stores the value in a attribute.
The following suffices to set a predetermined UUID on an existing Dexterity object obj:
from plone.uuid.interfaces import ATTRIBUTE_NAME
setattr(obj, ATTRIBUTE_NAME, uuid)
Related
I have a simple csv file with 3 columns: NID|Key|List where NID is the node id and Key was the unique value used to add field collections to the respective node. "List" is a multi-value field separated by ";".
Example (csv file):
NID,Key,List
1,2,text1;text2;text3
1,3,text4;text4
2,123,text1
...
Field collection has an entity reference field to a taxonomy plus other fields.
Field Collections:
Field1: text;
Field2: Term Reference;
Field3: Entity Reference; <-- importer/tamper not working!
...
The field collection fields were mapped correctly, except for the field that was an entity reference to a taxonomy. I configured Feeds Tamper and the Field Collection Feeds module but nothing was imported.
Does anyone has experience importing a multi-value field from a csv file into an entity reference field within a field collection?
Using the same feeds importer configuration but instead of importing with the standalone form, it worked once it was moved to a content type form. If a content type is selected a source is imported by creating a node of that content type.
We would like to use Realm mobile database, but couldn't find any reference about how do you read and write a HashMap (Map/Dictionary in Apple languages) or any other Collection type field of your RealmObject subclass?
Is there a way to make Realm handle these fields like primitive type fields for serialization?
There's no direct support for anything but List in Realm right now. One workaround is to define your own tuple as a model class and operate on that instead. You can specify your key to be a primary key so that will ensure uniqueness.
I would like to make a collection which returns my custom dexterity type if it's "featured" field is true. I have added this field to the catalog... is there anything else I need to do to be able to see it in the collection search terms?
When you say "I have added this field to the index" you mean to the portal_catalog?
If yes, you must also configure that index as a new collection criteria. If you are using new style collections you need a Generis Setup import step registry.xml. See plone.app.querystring package: https://github.com/plone/plone.app.querystring/blob/master/plone/app/querystring/profiles/default/registry.xml
I have some indexes in portal_catalog, for various types.
Given a portal_type and a fieldname, how can I find out the name of the index (if any) for that field?
Some relevant pointers to documentation about zcatalog might help me too!
Thanks..
There is no easy one-on-one way to determine this. In Plone 4, there are basically three different ways that an index in the catalog can obtain the information from your content type.
Index configuration
First and foremost, indexes can optionally be configured with the name(s) of the attributes or methods to index on a given object. Indexes generally have a getIndexSourceNames method that'll tell you what items they'll index.
Usually this is the same as the index id, but this is not a given. Generally, if your field accessor is listed in the result of getIndexSourceNames then that index will be indexing that field for a given type:
from Products.CMFCore.utils import getToolByName
catalog = getToolByName(context, 'portal_catalog')
for index in catalog.index_objects():
if field.accessor in index.getIndexSourceNames():
print 'Index %s indexes %s' % (index.getId(), field.getName()'
In the above examples, I assumed you already have a hold of your field object in the variable field, with an actual instance of your type in the variable context.
Custom indexing adapters
When an object is indexed, the catalog also constructs a wrapper around the object and will look up indexing adapters for your object. These adapters are registered both for the indexed name (so the name listed in getIndexSourceNames) and an interface or class. If your content class implements that interface or has an indexing adapter directly registered for it's class or a base class, the indexing adapter can be brought into play.
Indexing adapters are arbitrary snippets of code, and thus could call any field on your content object to produce their results. There is no programmatic way for you to determine if a given field on your content type will be used, or if any fields will be used at all.
The CMFPlone.CatalogTool module lists several examples of indexing adapters, these are all registered for Interface, meaning all objects:
allowedRolesAndUsers collects security information about your object.
getObjPositionInParent determines the position of the current object in it's container. Thus, this indexer does not need any information from the object itself to determine it's value.
sortable_title takes your content Title value and generates a value suitable for sorting catalog search results with. It normalizes the value, lowercases it, and prefixes numbers with leading zeros to make sorting on numbered titles easier.
Direct method access
Fields are basically generated methods on your content object. But your content class can also implement methods on it's class. The same remarks as for custom indexing adapters apply here; these are arbitrary Python code so they could be using your content type fields, aggregating and mangling the information before passing it to the index.
The Archetypes BaseObject class (used in all Archetypes content types) defines the SearchableText method for example. This method takes all available fields with the searchable property set to True, tries to get each field value as plain text, and aggregates the results for the SearchableText index.
Conclusion
You can only make educated guesses about index contents as they relate to your fields. By introspecting index configuration, you won't see if there might be a custom indexer adapter masking your field (register a getField index adapter and it'll be used instead of directly calling getField). Custom indexers and class methods can still access your fields and pass on the information to a catalog index.
You just add an index for the method or attribute name that you want to use for the index value--there's nothing too tricky about it and it can potentially all be done TTW
If you need a bit more logic to grab the index, check out this stackoverflow question: Problem with plone.indexer and Dexterity
I need to have a datatype of Amount (reference) for my Amount field. How to change that? Now I just get the normal datatypes (xs:string, xs:double, etc), but the existing fields are strongly typed like this - Datatype : Amount (Reference). How to do that?
seems like you need to import your reference schema and set the data type to the Amount field defined within it.
If that's the case, you can do that by;
a) selecting you the node
b) Selecting the Import property in the Property Window
c) Leave the 2Import new schema as:" option as XSD Import and click "Add..."
d) Point to your reference schema.
You should be able to set the data type of your amount field to the refernce type now.
HTH