Hi Oliver, Was there a reference intended from the [1] in your message? I’m interested in what you may have planned.
-Bruce From: Oliver Lietz <apa...@oliverlietz.de<mailto:apa...@oliverlietz.de>> Reply-To: "users@sling.apache.org<mailto:users@sling.apache.org>" <users@sling.apache.org<mailto:users@sling.apache.org>> Date: Saturday, December 6, 2014 at 8:42 AM 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 On Saturday 06 December 2014 08:00:41 Felix Meschberger wrote: Hi Bruce hi, 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 ? we have some improvement issues open [1] for content loader, I will do some experimenting in my whiteboard area including Felix ideas. Regards, O. [1] SLING-3533, SLING-3534, SLING-3535, SLING-3619 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/iss > ue.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
