Defining new content types and associated import actions

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Defining new content types and associated import actions

Bruce Edge
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"
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

Reply | Threaded
Open this post in threaded view
|

Re: Defining new content types and associated import actions

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 <[hidden email]<mailto:[hidden email]>>
Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Date: Thursday, December 4, 2014 at 2:00 PM
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
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>"
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


Reply | Threaded
Open this post in threaded view
|

Re: Defining new content types and associated import actions

Felix Meschberger-3
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 <[hidden email]>:
>
> 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 <[hidden email]<mailto:[hidden email]>>
> Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
> Date: Thursday, December 4, 2014 at 2:00 PM
> To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
> 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>"
> 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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Defining new content types and associated import actions

Oliver Lietz
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
> > <[hidden email]>:
> >
> > 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
> > <[hidden email]<mailto:[hidden email]>>
> > Reply-To: "[hidden email]<mailto:[hidden email]>"
> > <[hidden email]<mailto:[hidden email]>> Date: Thursday,
> > December 4, 2014 at 2:00 PM
> > To: "[hidden email]<mailto:[hidden email]>"
> > <[hidden email]<mailto:[hidden email]>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Defining new content types and associated import actions

Bruce Edge
In reply to this post by Felix Meschberger-3
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 <[hidden email]<mailto:[hidden email]>>
Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Date: Friday, December 5, 2014 at 11:00 PM
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
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 <[hidden email]<mailto:[hidden email]>>:
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 <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>>
Reply-To: "[hidden email]<mailto:[hidden email]><mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>>
Date: Thursday, December 4, 2014 at 2:00 PM
To: "[hidden email]<mailto:[hidden email]><mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>>
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


Reply | Threaded
Open this post in threaded view
|

Re: Defining new content types and associated import actions

Bruce Edge
In reply to this post by Oliver Lietz
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 <[hidden email]<mailto:[hidden email]>>
Reply-To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
Date: Saturday, December 6, 2014 at 8:42 AM
To: "[hidden email]<mailto:[hidden email]>" <[hidden email]<mailto:[hidden email]>>
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
> <[hidden email]<mailto:[hidden email]>>:
>
> 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
> <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>>
> Reply-To: "[hidden email]<mailto:[hidden email]><mailto:[hidden email]>"
> <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>> Date: Thursday,
> December 4, 2014 at 2:00 PM
> To: "[hidden email]<mailto:[hidden email]><mailto:[hidden email]>"
> <[hidden email]<mailto:[hidden email]><mailto:[hidden email]>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Defining new content types and associated import actions

Oliver Lietz
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.

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 <[hidden email]<mailto:[hidden email]>>
> Reply-To: "[hidden email]<mailto:[hidden email]>"
> <[hidden email]<mailto:[hidden email]>> Date: Saturday,
> December 6, 2014 at 8:42 AM
> To: "[hidden email]<mailto:[hidden email]>"
> <[hidden email]<mailto:[hidden email]>> 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 (@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
> > <[hidden email]<mailto:[hidden email]>>:
> >
> > 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
> > <[hidden email]<mailto:[hidden email]><mail
> > to:[hidden email]>> Reply-To:
> > "[hidden email]<mailto:[hidden email]><mailto:users@slin
> > g.apache.org>"
> > <[hidden email]<mailto:[hidden email]><mailto:users@slin
> > g.apache.org>> Date: Thursday, December 4, 2014 at 2:00 PM
> > To:
> > "[hidden email]<mailto:[hidden email]><mailto:users@slin
> > g.apache.org>"
> > <[hidden email]<mailto:[hidden email]><mailto:users@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=@~/bedge/issue.multifolio<mailto:contentFile=@~/bedge/iss
> > ue.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
Reply | Threaded
Open this post in threaded view
|

Re: Defining new content types and associated import actions

Bruce Edge
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
>
>




Reply | Threaded
Open this post in threaded view
|

Re: Defining new content types and associated import actions

Oliver Lietz
On Tuesday 30 December 2014 15:25:29 Bruce Edge wrote:
> Hi Oliver

Hi Bruce,

[...]
> 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.

I'm currently preparing a new release of Scripting Thymeleaf and will try to
find some time to address the issues related to content loading after that
release. Patches are always welcome.

Regards,
O.

> -Bruce
[...]