Home » Liferay Portal » English » 3. Development

Combination View Flat View Tree View
Threads [ Previous | Next ]
Jakub Liska
A use case for Document Library
March 19, 2011 3:33 PM

Jakub Liska

Rank: Regular Member

Posts: 187

Join Date: March 25, 2010

Recent Posts

Hi Ray,

I'm responding to yesterday's conversation.

My use case is :
- I receive documents (pdf, ms docs, ods, etc.) that are part of an entity ORDER with order specific metadata entered by a user via html form
- file(s) are uploaded dynamically by ajax before the form is submitted
- and file references to filesystem only are then submitted if everything is fine

- when files are subsequently uploaded, I have to persist them somewhere and get some metadata via apache tika (note: file's future existence depends on validity + user may decide to cancel the order) - he can dynamically add, remove files via Ajax, before submitting the form

- so, within LR, I can use DLLocalService that uses jcrHook directly (avoiding DLAppLocalService because I just need file persistence and performance )
- so that I can store the metadata as custom props of fileEntry
- DLLocalService.addDirectory( )
- DLLocalService.addFile( file, fileEntryId )
- DLLocalService.addFile( file2, fileEntryId2 )

- Now there are a few situations
- user submitted all files that he uploaded
- user uploaded 5 files, but decided to submit only 3 - > orphaned files
- user uploaded files and decided not to submit the order -> orphaned directory of files


So that after the form is submitted, I need to set a custom property to fileEntry - (submitted, true) for it to have a status
Also I need to run scheduler to remove fileEntries with expired createDate and (submitted, false)

in DLLocalServiceUtil there is only "search( ...., String keyword, ...)" for fulltext search and in DLAppLocalServiceUtil or DLFileEntryUtil there is no search() at all.

So I suppose that I would implement something like :
 1        public Hits search() {
 2            Map<String, Serializable> attributes = new HashMap<String, Serializable>();
 3                        attributes.put("submitted", false);
 5            SearchContext searchContext = new SearchContext();
 6            searchContext.setAttributes(attributes);
 8            Indexer indexer = IndexerRegistryUtil.getIndexer(FileEntry.class);
 9            return;
10        }

As I have fileEntryIDs I can remove FileEntries - > the orphaned files and all the custom props that belong to them
- DLLocalService.deleteFile( )

- otherwise I don't see any interface to deleteFileEntry except DLFileEntryUtil.remove(DLFileEntry)


I'm going to send that file via WS to a third party that makes some changes and sends it back. Unfortunately, it comes back with another custom properties regarding the third party, that belong to the file - not to the Order.

From this point, things start to get complicated.
- There are 2 files that belongs together (original and modified)
- > I'd have to create a dedicated folder for each pair
- > I'd have to have new custom property to differentiate between them
- > new custom properties for third party metadata

Third party metadata is for instance an email address of the user that is registered in my portal, so that I would be joining USER table with ExpandoValues table etc. etc.

very complex stuff follows, 2 similar phases at least....

Now consider if I could use jackrabbit directly
- I'd create a JCR mixin that suits my requirements best
- I'd create one nt:file for each pair with two nt:contents for those 2 files having nt:resources with the mixin of mine

You can imagine how simple this is in comparison with employing DocumentLibrary. I absolutely understand why, Liferay is not a JCR repository :-) But one can see, that if there is something more complicated to be done regarding document management, DocumentLibrary isn't easy to use.
Ray Augé
RE: A use case for Document Library
March 19, 2011 12:05 PM

Ray Augé


Rank: Liferay Legend

Posts: 1196

Join Date: February 7, 2005

Recent Posts

Wow! Now I understand.

After thinking on this, I don't think I would use Liferay doclib at all.

The issue is really that you are building an application that deals with "documents", but is not really a "document" repository in the traditional sense of just some place to store files and perhaps have some workflow on those.

It seems more like you are building some kind of brokering market place which just so happens to have as it's brokered product "documents" where these are moving:

client <-> broker <-> service vendor

To that end, I imagine that there are lower level "document" APIs than Liferay's doc lib which would get less in your way to achieve this.

So, in your case, I could see why you are thinking to go direct to a JCR repository.

Participate in the State of Liferay Community 2017. Help the community and even win some prizes!