You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Ian Boston <ie...@tfd.co.uk> on 2010/07/27 11:35:50 UTC
Pooled content
Hi,
We have a requirement to store content based on a ID not on a path. I know that this will violate aspects of David's model but the requirement is still there and I have to support it. Details (for background reading only are at [1] and [2]).
I have an implementation that is close to working that uses a Filter to http access to the underlying jcr storage and a ResourceProvider that does the translation from http://localhost:8080/p/<ID> to jcr:/_p/hashPath(ID)/ID, however we want to be able to
a) reuse all of the SlingEngine functionality and
b) upload files with a multipart post to /p where the file is stored as /_p/hashPath(ID)/ID, where ID is generated
c) upload files with a multipart post to /p/ID where the file is stored as /_p/hashPath(ID)/ID
For b, I can generate the ID and the file node, but AFAICT there is no way of stopping the SlingFileUploadHelper from taking the name of the file from the multipart post element and using it as the JCR path.
I dont want to replicate the entire SlingPost infrastructure for this operation, I would like either to make it possible to persuade the SlingFileUploadHelper to use the resource path directly, or to hook in another operation.
Any ideas,
whats the best Sling way of achieving this without replicating code ?
Ian
1 http://jira.sakaiproject.org/browse/KERN-891
2 http://confluence.sakaiproject.org/display/KERNDOC/KERN-891+Pooled+Content+Service
Re: Pooled content
Posted by Ian Boston <ie...@tfd.co.uk>.
On 28 Jul 2010, at 17:29, Justin Edelson wrote:
> On 7/27/10 9:11 AM, Ian Boston wrote:
>>
>> On 27 Jul 2010, at 13:59, Ian Boston wrote:
>>
>>>
>>> On 27 Jul 2010, at 13:38, Justin Edelson wrote:
>>>
>>>> Ian-
>>>> I'm not near a Sling working copy right now, but have you looked at using the NodeNameGenerator interface? I added it to solve a similar use case.
>>>
>>> Will do,
>>> thanks for the pointer.
>>> Ian
>>>
>>>
>>
>> Yes that generates a node where a post is performed to a URL ending / or *, which would be Ok except that the SlingFileUploadServlet is hard bound to creating a file of the name specified in the file upload field, rather than the parent which the NodeNameGenerator can supply
>>
>> eg
>> currently
>> multipart file upload to /pool/ or /pool/*
>>
>> would generate a path of /pool/<generatedname>
>>
>> and then SlingFileUploadServlet would create
>> /pool/<generatedname>
>> - jcr:primaryType = nt:folder
>> /<post-file-name>
>> - jcr:primaryType = nt:file
>> etc
>>
>> I need
>> /pool/<generatedname>
>> - jcr:primaryType = nt:file
>>
>>
>> I have created a servlet at /system/pool/createfile which doesn't implement all the the sling protocol, but will do for the moment. (its Ugly).
>>
>> The alternative would be to modify the SlingFileUploadServlet to use a NodeNameGenerator implementation to create a sub path rather than always relying on the name provided in the file upload.
>>
>> Ian
>>
> What about:
>
> POST /pool/*
> jcr:primaryType = nt:file
> jcr:content = (the file form field)
>
> By default, SlingFileUploadHelper will create a nt:resource, so I think
> this will create the right thing.
>
> I think everything else can be done with filters.
>
> Justin
>
Thanks I will give that a go
Ian
>
Re: Pooled content
Posted by Justin Edelson <ju...@gmail.com>.
On 7/27/10 9:11 AM, Ian Boston wrote:
>
> On 27 Jul 2010, at 13:59, Ian Boston wrote:
>
>>
>> On 27 Jul 2010, at 13:38, Justin Edelson wrote:
>>
>>> Ian-
>>> I'm not near a Sling working copy right now, but have you looked at using the NodeNameGenerator interface? I added it to solve a similar use case.
>>
>> Will do,
>> thanks for the pointer.
>> Ian
>>
>>
>
> Yes that generates a node where a post is performed to a URL ending / or *, which would be Ok except that the SlingFileUploadServlet is hard bound to creating a file of the name specified in the file upload field, rather than the parent which the NodeNameGenerator can supply
>
> eg
> currently
> multipart file upload to /pool/ or /pool/*
>
> would generate a path of /pool/<generatedname>
>
> and then SlingFileUploadServlet would create
> /pool/<generatedname>
> - jcr:primaryType = nt:folder
> /<post-file-name>
> - jcr:primaryType = nt:file
> etc
>
> I need
> /pool/<generatedname>
> - jcr:primaryType = nt:file
>
>
> I have created a servlet at /system/pool/createfile which doesn't implement all the the sling protocol, but will do for the moment. (its Ugly).
>
> The alternative would be to modify the SlingFileUploadServlet to use a NodeNameGenerator implementation to create a sub path rather than always relying on the name provided in the file upload.
>
> Ian
>
What about:
POST /pool/*
jcr:primaryType = nt:file
jcr:content = (the file form field)
By default, SlingFileUploadHelper will create a nt:resource, so I think
this will create the right thing.
I think everything else can be done with filters.
Justin
Re: Pooled content
Posted by Ian Boston <ie...@tfd.co.uk>.
On 27 Jul 2010, at 13:59, Ian Boston wrote:
>
> On 27 Jul 2010, at 13:38, Justin Edelson wrote:
>
>> Ian-
>> I'm not near a Sling working copy right now, but have you looked at using the NodeNameGenerator interface? I added it to solve a similar use case.
>
> Will do,
> thanks for the pointer.
> Ian
>
>
Yes that generates a node where a post is performed to a URL ending / or *, which would be Ok except that the SlingFileUploadServlet is hard bound to creating a file of the name specified in the file upload field, rather than the parent which the NodeNameGenerator can supply
eg
currently
multipart file upload to /pool/ or /pool/*
would generate a path of /pool/<generatedname>
and then SlingFileUploadServlet would create
/pool/<generatedname>
- jcr:primaryType = nt:folder
/<post-file-name>
- jcr:primaryType = nt:file
etc
I need
/pool/<generatedname>
- jcr:primaryType = nt:file
I have created a servlet at /system/pool/createfile which doesn't implement all the the sling protocol, but will do for the moment. (its Ugly).
The alternative would be to modify the SlingFileUploadServlet to use a NodeNameGenerator implementation to create a sub path rather than always relying on the name provided in the file upload.
Ian
Re: Pooled content
Posted by Ian Boston <ie...@tfd.co.uk>.
On 27 Jul 2010, at 13:38, Justin Edelson wrote:
> Ian-
> I'm not near a Sling working copy right now, but have you looked at using the NodeNameGenerator interface? I added it to solve a similar use case.
Will do,
thanks for the pointer.
Ian
Re: Pooled content
Posted by Justin Edelson <ju...@gmail.com>.
Ian-
I'm not near a Sling working copy right now, but have you looked at using the NodeNameGenerator interface? I added it to solve a similar use case.
Justin
On Jul 27, 2010, at 5:35 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> Hi,
> We have a requirement to store content based on a ID not on a path. I know that this will violate aspects of David's model but the requirement is still there and I have to support it. Details (for background reading only are at [1] and [2]).
>
> I have an implementation that is close to working that uses a Filter to http access to the underlying jcr storage and a ResourceProvider that does the translation from http://localhost:8080/p/<ID> to jcr:/_p/hashPath(ID)/ID, however we want to be able to
> a) reuse all of the SlingEngine functionality and
> b) upload files with a multipart post to /p where the file is stored as /_p/hashPath(ID)/ID, where ID is generated
> c) upload files with a multipart post to /p/ID where the file is stored as /_p/hashPath(ID)/ID
>
>
> For b, I can generate the ID and the file node, but AFAICT there is no way of stopping the SlingFileUploadHelper from taking the name of the file from the multipart post element and using it as the JCR path.
>
> I dont want to replicate the entire SlingPost infrastructure for this operation, I would like either to make it possible to persuade the SlingFileUploadHelper to use the resource path directly, or to hook in another operation.
>
> Any ideas,
> whats the best Sling way of achieving this without replicating code ?
>
> Ian
>
> 1 http://jira.sakaiproject.org/browse/KERN-891
> 2 http://confluence.sakaiproject.org/display/KERNDOC/KERN-891+Pooled+Content+Service