Hi Oliver > > On Saturday 06 December 2014 21:06:34 Bruce Edge wrote: > > Hi Oliver, > > hi Bruce, > > > Was there a reference intended from the [1] in your message? > > I¡¦m interested in what you may have planned. > > I listed the issues SLING-3533, SLING-3534, SLING-3535 and SLING-3619 at >the > bottom of my mail and I've now created a new issue SLING-4223 to track >your > request and a new version (2.2.0) for JCR ContentLoader.
I saw your whiteboard for this work and I'm looking forward to integrating with it. Is there any plan as to when this may be merged into the trunk? I know that some of the sling issues above are still outstanding, but SLING-3534 looked like the only one needing new code. I'm asking because I will have some time to dedicate to sling work in the near future and wanted to assist if possible. -Bruce > > We will need to find a way how to get the right ContentReader for a >format as > we will have the same extension (e.g. .xml, .zip) for different formats. > > Regards, > O. > > > -Bruce > > > > From: Oliver Lietz <apache@...<mailto:apache@...>> > > Reply-To: "users@...<mailto:users@...>" > > > <users@...<mailto:users@...>> > Date: Saturday, > > December 6, 2014 at 8:42 AM > > To: "users@...<mailto:users@...>" > > > <users@...<mailto:users@...>> > 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 ¡X 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 ¡K > > * we create a new org.apache.sling.contentloader.reader package to be > > exported at version 1.0 * move the ContentCreator ( <at> ProviderType) >and > > ContentReader ( <at> 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.edge@...<mailto:bruce.edge@...>>: > > > > > > 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.edge@...<mailto:bruce.edge@...><mail > > > to:bruce.edge@...>> Reply-To: > > > "users@...<mailto:users@...><mailto:users <at> slin > > > g.apache.org>" > > > <users@...<mailto:users@...><mailto:users <at> slin > > > g.apache.org>> Date: Thursday, December 4, 2014 at 2:00 PM > > > To: > > > "users@...<mailto:users@...><mailto:users <at> slin > > > g.apache.org>" > > > <users@...<mailto:users@...><mailto:users <at> slin > > > g.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 > > > ¡K > > > > > > 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: > > > ¢u¢w¢w Folio.xml > > > ¢u¢w¢w META-INF > > > ¢x ¢|¢w¢w pkgproperties.xml > > > ¢u¢w¢w StackResources > > > ¢x ¢u¢w¢w asset_L.pdf > > > ¢x ¢u¢w¢w asset_P.pdf > > > ¢x ¢u¢w¢w scrubber_L1.jpg > > > ¢x ¢u¢w¢w scrubber_P1.jpg > > > ¢x ¢u¢w¢w thumb_L1.jpg > > > ¢x ¢u¢w¢w thumb_P1.jpg > > > ¢x ¢|¢w¢w toc.jpg > > > ¢|¢w¢w 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= <at> ~/bedge/issue.multifolio<mailto:contentFile= <at> ~/bedge/iss > > > ue.multifolio><mailto:contentFile= <at> ~/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 > >
