* Make docman new item and update more coherent: since we already created and
  validated an Docman_Item object, DocmanActions should only rely on this
  object. (It imply to develop a validator for Docman_File).


-- General test on performances (by MV).
========================================
I tested serveral optims around permissions and items to see if we can optimize the permission fetching.  Note: I made the test on a medium-large docman (980 items used) with a lot of perms defined (the query that fetch all the perms for all the items return 17200 rows). So we can consider it as a good example for our tests.

I wanna test 2 things: 
- the way to retreive all the perms for all items (large query vs. join) 
- the influence of the type of 'object_id' in the permission_table.

My tests give to me the following results: - The fastest way to retreive all the perms for all items is to make a large simple query (select * from permissions where object_id in (...)).

- The influence of the type of 'object_id' seems to exists. Anyway my test is not comprehensive because the table I used with an object_id contained less data than the real permissions table.

My conclusions are:
1. To improve perf on perms there are mainly two ways:
  
1.1. Reduce the number of rows to handle in PHP. Today, when we retreive all the
permissions, the number of row to handle in PHP is huge (17000), we should reduce it. Maybe by passing ugroup in parms of the request:

SELECT * FROM permissions WHERE  object_id IN (items_ids) AND permission_type IN
("PLUGIN_DOCMAN_READ","PLUGIN_DOCMAN_WRITE","PLUGIN_DOCMAN_MANAGE") AND
ugroup_id IN (static_ugroups, dynamic_ugroups)

1.2. To be able to retreive in one query the items with corresponding permissions so if an item is not in the row returned: it's not viewable.

2. Split permission table by services will improve
- performances (because, in docman, we can have object_id as int).
- security (no risk to affect perms on other services).

!!! Metadata values handeling is crapy (by MV)

This is mainly due to list of values.

I tried this approach:
Since, for user input checking, we are building objects for item, metadata and values, I wanted to reuse these objects for database update.

Unfortunatly, I faced an issue with metadata, metadatavalues and listofvalues.
1. For validation purpose we create a metadata object per project metadata
2. For each metadata, we are looking for a value in user submitted stuff.
3. If something match, we create a MetadataValue object with these data.
4. If the data are valid, we get the value from MetadataValue object and we assign it to the Metadata object.
5. Later, in DocmanActions, I tried to reuse the value assigned to Metadata object, unfortunatly it doesn't work as expected:
 5.1 I made a loop on metadata (I kept only real metadata)
 5.2 and I tried to create a new MetadataValue object to store it in the db but it fails because when I made the assignement at step 4. I got (for list of values) an iterator on ListOfValuesElements while ListMetadata->setValue method require an array of ListOfValuesElements.

Here we have a problem because:
- Metadada object can have a value
- MetadataValue object can have a value too.
- In the example behind value is first assign to a MetadataValue object then transfered to a Metadata object. Later, for DB actions the value from Metadata is assigned again a MetadataValue object !

We should find a solution to make all this homogenous.