In attributesDate you store an associative array with all the attributes of your object
You can also look here : http://pubsvn.ez.no/websvn2/listing.php?repname=nextgen&path=/trunk/tests/toolkit/extras/kernelwrapper/#path_trunk_tests_toolkit_extras_kernelwrapper_
You'll find a kernel wrapper. I think eZ Systems use it for their unit tests.
I did not know about the eZContentFunctions::createAndPublishObject method and about the kernel wrapper classes (ezpClass, ezpObject and ezpNode) available in the "Test" folder.
Both are interresting sources to understand the process, and gives some more information to handle attributes, versions and language versions.
I am still wondering :
what the NodeAssignment is used for ?
is there a way to update object attributes without republishing the object?
A node assignment is used to link your object to a node and then give him a position in your content tree.
I don't really understand what you mean by republish the object but basically when you edit an object is create a draft you can store it for later editing or publish it so that it becomes your published version.
>>A node assignment is used to link your object to a node and then give him a position in your content tree.
From what I have seen in the structure of a NodeAssignment, there is no information about the content tree (which is built in the TreeNode objects - ezcontentobject_tree table).
It looks like there is a relation 1 to 1 or 1 to 0 between the two tables and there is an "op_code" field and a "from_node_id" (which is set either to 0 or -1) in the table eznode_assignment that are not available in ezcontentobject_tree.
There might be a reason why of this structure but I do not get it.
>> I don't really understand what you mean by republish the object
>> but basically when you edit an object is create a draft you can store it >> for later editing or publish it so that it becomes your published version.
I was talking about updating an object through a php script, not through the user interface. I do not think that draft versions are created automatically when you update the attribute of an object, I suspect that you would have to create explicitely a draft version of the object.
You can change your content objects without republishing them. I use it rather often, due to heavy processing included in publishing new version of an object, which makes it impractical if you are doing a batch of work including changing a few thousand objects.
The procedure is very simple, you fetch current version of your object, change the attributes and store the changes. The last thing you need to do is to clear the caches, so that your view cache would be correctly created.
$contentObject = $node->attribute('object');
// get the current version,you can also set the modified timestamp
$version = $contentObject->version($contentObject->attribute('current_version'));
$version->setAttribute( 'modified', eZDateTime::currentTimeStamp() );
// change the attributes
...
...
// store the changes and clear view cache of the object
$contentObject->store();
$contentObject->expireAllViewCache();
// also, you may have need to change the object name:
$class = $contentObject->contentClass();
$contentObject->setName( $class->contentObjectName( $contentObject ) );
$contentObject->store();
Internal research showed that 'ezcontentobject_tree' table stores child nodes sort type and sort order, and not 'eznode_assignment' (but it also has related fields) but didn't find place in code where it is used.