cancel
Showing results for 
Search instead for 
Did you mean: 

Get All Content Types From Java-backed Webscript

riya_soni42
Champ on-the-rise
Champ on-the-rise

Hi,

I want all custom content types which we can see on Aflfresco Advanced Search Page from Java-backed Webscript.

I have referred advsearch.get.js, it retrieves all the content types from share-config-custom.xml, but I want to that from Java Backed Web script.

Is there anyway we can parse share-config-custom.xml from Java class and get content types, or is there any other way to use any  Public Java API like Node service for retrieving the content type.

Thanks in advance.

6 REPLIES 6

cesarista
World-Class Innovator
World-Class Innovator

Maybe this helps:

DictionaryService | Alfresco Documentation 

There is also a webscript retrieving full dictionary data:

/alfresco/service/api/dictionary

Regards.

--C.

But I want only those content types which we can see on advanced search page, currently that arrays is created in advsearch.get.js, but if I wan to pass this content types array via remote call to repository side, so how to pass it and on java side how to retrieve it. Please let me know  if any ideas are there.

Thanks.

cesarista
World-Class Innovator
World-Class Innovator

Hi Riya:

If you need only few of them, you need some kind of config file like share-config-custom.xml for Alfresco Share.

You can configure your webscript with a config xml file mywebscript.get.config.xml directly and having these custom content types.

Maybe this helps:

Best way to inject .properties file to a webscript 

Regards.

--C.

Ok, thanks, let me try thi once.

So, to get this straight, if you want to retrieve all custom created content types, you cannot get them via the API and you have to manually write them into a file instead?

afaust
Legendary Innovator
Legendary Innovator

No, there are APIs for that. Cesar referenced the Repository-tier Java API for it. The CMIS API also exposes dictionary information, and there is also a ReST API for internal use that exposes types and other dictionary information. It is just that there currently is no public v1 ReST API to access dictionary information in a generic way.

The file option is something Cesar mentioned as a potential simplification for a known set of custom types.