Store annotations user-wise in Java

GroupDocs.Annotation Product Family
1

Hi,


do you have some document describing all the DAO interfaces and relations between user, collabolator, session, annotation and reply?
I need to implement a custom connector to store the annotations per document in some repository.
Users are already defined in my repository, I’m not sure why in the DAO there is a method to store users? The same concerns collabolators,sessions and system info, I don’t know why do I need to implement it. I don’t use a standard database, but a third party API.

All I need is to store annotations per document per user. Looking at IAnnotationDao I see I can get the document ID from the IAnnotation (not directly which is odd, but via some sort of session). That’s OK. Can you explain me what are the possible paramList and paramVarArgs of the methods below?

public abstract T selectBy(List paramList, Object… paramVarArgs)
throws AnnotationException;
public abstract List selectAllBy(List paramList, Object… paramVarArgs)
throws AnnotationException;

Thanks,
Mariusz
2
Hi Mariusz,

Unfortunately there is no yet the document describing entity relations and possible parameters. At the moment we have a general documentation on implementing custom meta-data storing http://groupdocs.com/docs/display/annotationjava/How+to+store+annotations+in+a+DB. There are also links to samples where you can look at one way how it can be implemented.

Also, you can check entities diagram to get a better understanding of the structure: http://screencast.com/t/rxiJxh5T7
For now, I suggest you to place the break-point in the selectBy and the selectAllBy methods and examine what parameters are possible there.

3

Can you at least describe me how it suppose to work? I mean when the session is created, how it correspond to the user, document and collaborator? In my scenario the annotation has just a content, creator name (user name) and the document to which it’s attached. I’m not sure how should I populate it. Can you share the Alfresco code? That would be really helpful I guess. Thanks.

4

Alfresco code unfortunately contains just a custom input handler sample which doesn’t work with 1.7 anyway. I’d really appreciate some sample to understand what and how needs to be implemented to store annotation in e.g. Alfresco or any custom (not db) location. Thanks.

5
Hello Mariusz,

Sorry for the delay with the response. I’ll explain the entity structure and serialization/deserialization process. A session is an entity which represents a user activity on a particular document. In the current implementation there is a session for every user-document pair. The same time the user entity holds only user specific info (currently user name, password, etc.). The access rights and document collaboration info are hold with the collaborator entity, which links to the appropriate user and session.

At the moment you the deserialization should fully restore all this data to make the library work correctly. The only thing you can skip is info about collaborators and sessions, but then you’ll have to recreate them every time with the same input parameters (addColaborator method). Also, this option should be checked, because we did not try this before.

All this is the GroupDocs.Annotation for Java library internal structure. To connect it with your application database you should implement a custom mapping between your application entities and GroupDocs.Annotation ones, you can’t substitute some entities in place of Annotation’s ones.

6
Couple of questions:

1. session - is it one per document or one per user-document pair?
2. session - contains a reference to document table that has only name attribute - document name should be in session table in that case
3. annotation - why is it related with session and not the document directly? as I understand you can have multiple sessions and the same annotation should be used, not multiply
4. user - what are all those attributes like signupDate, isActivated, pswdResetToken? those are user specific data that comes from the external system and are irrelevant here so should not be part of the IUser interface. This kind of information is not available or displayed in the tool and only user name is actually used.
5. systeminfo - is it really required? It's irrelevant and meaningless in case of custom implementation

Thank you,
Mariusz
7

Let me describe what I need:


1. User opens the annotation dialog with the objectId, userName and userTicket parameters
2. AnnotationHandler is retrieved from the HTTP Session, if it’s not present it is initialized and set as HTTP session attribute. That’s because the CustomDataInputHandler is user specific, it initializes an internal ECM user session that allows reading data from the ECM system:
annotationHandler = new AnnotationHandler(serviceConfiguration, new CustomInputDataHandler(userName, userTicket));

Connector needs to be initialized also per HTTP session as it requires the internal ECM user session to retrieve annotations and it is user specific.

That’s fine assuming that you will fix the CustomInputDataHandler issue reported in a separate thread.

Then there is glitch. I want to implement the annotation reading and saving but I have no idea what to do.


8
Hi Mariusz,

Unfortunately, you’ll have to wait a bit for new version of the GroupDocs.Viewer to be released and then we will be able to provide you the GroupDocs.Annotation 1.8.0 beta – so you can continue the development.

Also, here are answers to your questions:
  1. Session for now is per user-document pair.
  2. We are bound to this structure for a moment. This level of abstractions is needed.
  3. It’s made to give an additional flexibility in cases where some custom annotation handling will be requested.
  4. You can skip it or fill it with null values for now.
  5. This can be skipped also.

9

In my opinion the diagram should look more like on the attached screenshot. With that, we could create and keep the session in the HTTP session as it is volatile. User table is rather not required. All we need is the user name so we can read the user’s right to the document from the ECM system. Additionally document table is not required unless the DAO can replace the InputHandler, it would make much more sense then. All the integration in one place. Right now I have to implement two interfaces, one to return the content (InputHandler) and one just to return the file name, although I don’t know where that name is actually used:)


Thanks,
Mariusz
10
Hello Mariusz,

Thank you for this proposition of the data structure. It was passed to our developers. We already thought about changes in that area, but as you may guess structure changes are “hard” ones (may take a long time, in most cases led to incompatible changes, etc.). Maybe something will be changed already in the 1.8.0 version of the GroupDocs.Annotation library.