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>:
> >
> > 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>>
> > Reply-To: "users@sling.apache.org<mailto:users@sling.apache.org>"
> > <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>"
> > <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/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
