Felix, that sounds damn near perfect. I can work on a folio import service now, given those assumptions. I can build it into the internal API now and migrate it over later, and if no one objects, contribute it as an optional extension.
-Bruce From: Felix Meschberger <fmesc...@adobe.com<mailto:fmesc...@adobe.com>> Reply-To: "users@sling.apache.org<mailto:users@sling.apache.org>" <users@sling.apache.org<mailto:users@sling.apache.org>> Date: Friday, December 5, 2014 at 11:00 PM To: "users@sling.apache.org<mailto:users@sling.apache.org>" <users@sling.apache.org<mailto:users@sling.apache.org>> Subject: Re: Defining new content types and associated import actions Hi Bruce I think you are on the right track. ContentReader would probably help solving your problem. Yet, for now the content loader is not extensible - by intent because we didn’t have a need for making it extensible so far and we were not sure about how to do it. This might be a good opportunity, though, to do it. Quickly glancing through the code, I’d think that … * we create a new org.apache.sling.contentloader.reader package to be exported at version 1.0 * move the ContentCreator (@ProviderType) and ContentReader (@ConsumerType) to that new package * convert the BaseImportLoader into a standalone ContentReader service holder used by the DefaultContentImporter and ContentLoaderService components. * For the ContentReader service interface we define service registration properties for the service to expose the file name extension (and maybe content type) the reader supports. WDYT ? Regards Felix Am 06.12.2014 um 06:32 schrieb Bruce Edge <bruce.e...@nextissuemedia.com<mailto:bruce.e...@nextissuemedia.com>>: After digging around in the sling code a bit I found the ContentReader interface, with Json, Zip, and XML reader classes. This looks looks like the right option, IOW implement a new ContentReader class for my data type. The one remaining question is, how does this tie in with the content type detection on the front end? I am setting up the mimeType for this extension already: mimeTypeService.registerMimeType("application/vnd.adobe.folio+zip", "folio"); but what else do I need to do to invoke the new ContentReader once this mimeType is detected? I see the existing loaders are all defined in BaseImportLoader. Is there an API to append new extension/loader mappings to this? -Bruce From: Bruce Edge <bruce.e...@nextissuemedia.com<mailto:bruce.e...@nextissuemedia.com><mailto:bruce.e...@nextissuemedia.com>> Reply-To: "users@sling.apache.org<mailto:users@sling.apache.org><mailto:users@sling.apache.org>" <users@sling.apache.org<mailto:users@sling.apache.org><mailto:users@sling.apache.org>> Date: Thursday, December 4, 2014 at 2:00 PM To: "users@sling.apache.org<mailto:users@sling.apache.org><mailto:users@sling.apache.org>" <users@sling.apache.org<mailto:users@sling.apache.org><mailto:users@sling.apache.org>> Subject: Defining new content types and associated import actions I keep finding that I’m doing things the hard way and that someone has already thought of this and has implemented something far better than my current attempt. Therefore I have to ask this question. I need to import content with a well defined structure adobe multi-folio archives. These are zip files consisting of an xml content descriptor, a mime type file and a number of child folio archives. Folio.xml mimetype 0000_Cover.folio 0001_article_xx.folio 0002_artivle_yy.folio … The mime type contains: application/vnd.adobe.folio+zip% where each child .folio file is a zip consisting of another folio.xml descriptor file and additional media files: ├── Folio.xml ├── META-INF │ └── pkgproperties.xml ├── StackResources │ ├── asset_L.pdf │ ├── asset_P.pdf │ ├── scrubber_L1.jpg │ ├── scrubber_P1.jpg │ ├── thumb_L1.jpg │ ├── thumb_P1.jpg │ └── toc.jpg └── mimetype Is it possible to define a new content type for each of these, the parent multi-folio and the child folio structures such that when I post using something like: curl -u uid:pwd -F":contentType=multifolio" -F":operation=import" -F":contentFile=@~/bedge/issue.multifolio<mailto:contentFile=@~/bedge/issue.multifolio><mailto:contentFile=@~/bedge/issue.multifolio>" http://localhost:8080/content/issue that the behavior would be to unpack the multifolio, then upon discovering the child .folio files, and recognizing the registered format for these, also unpack each of these? The gravy would be to also parse the folio.xml files and validate that all resources defined in the xml are indeed present, but I admit that’s getting greedy. -Bruce
