jllort wrote:I don't suggest modify DocumentServlet, Document.java class etc ... because we're doing strong changes on actual source code and you'll get problem to upgrade newer version from actual, and because it's not the idea we've got in mind to extend OpenKM features. I'll try explain you better how I thinking it.
HI there Josep. Your position is clear. For the record, I was trying merely to see if a more direct approach could work, with the aim to get myself familiarised with the platform and the role of specific classes thereunder. As it stands, the OpenKM platform has great features worth building on. So, by changing code directly, I am actually trying to better understand the inner workings of the application. With this in mind, when you have a bit of time, maybe you could detail a bit on the role of the diverse classes within OKM ,e.g. basedocument, okmdocument, gwtdocument, documentmodule etc.
jllort wrote:
We can separate the solution in two problems, assign UUID and view it.
Start with the second to view it ... simply create a property group ( metadata ) with field UUID, and register to openkm. From this point you've got manually UUID. Take a look here http://wiki.openkm.com/index.php/Property_Groups and http://wiki.openkm.com/index.php/Proper ... definition
When it'll be done then we want automatically UUID setting ... I suggest to starting the most easiest way, and probably what will run better, scripting. Take a look here http://wiki.openkm.com/index.php/Scripting
That could be separed by two task:
First; register script to okm:root node because we wants to take effect on all repository. The first step idea is, when event CREATE_DOCUMENT is fired must add property to the document ( take a look at PropertyGroupServer to know which class method must be used ( it's easy )).
Secondly you must change property group value, here must generate some number etc... I'll need to understanding the logic of the autogenerated number to help you on how doing it ( are several ways depending what you want to doing ).
This is indeed a very suple, non-invasive approach and update ready. I am currently working on it as well. The only issue I had with it was that it is not all code, it also requires certain non-code related steps (metadata creating + code for metadata access) as well as scripting. In my current implementation, the documentid is a string, a property of the document class, and gwtdocument - think of it similarly to the "title" implementation that is currently being marked as comment in the source code.
jllort wrote:
Secondly you must change property group value, here must generate some number etc... I'll need to understanding the logic of the autogenerated number to help you on how doing it ( are several ways depending what you want to doing ).
The number is a simple incremental id. You set the base, eg. 10000, and then each document created in the repository gets a new number base+1. As a simple primary key in a data base, which means that whatever happens to the document, the id keeps increasing. What it is important is that each document (not each version) gets such an id upon create in the repository. The idea is to be able to search the document based on this id, rather than title. Also, if one deals with docx documents, one could pass the id to the actual docx document using properties and fields. In essence, this approach allows a far better tracking of the printed documents and their correspondents in the repository. If you ask me, this should definetly be included in one of your future releases. I am ready to help as well, if the case.
Hope this helps and keep in touch.
WIth kind regards,
JO