[jira] [Updated] (SLING-9732) Friendly Names / Alias for persisted GraphQL queries
[
https://issues.apache.org/jira/browse/SLING-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Knobloch updated SLING-9732:
---
Summary: Friendly Names / Alias for persisted GraphQL queries (was:
Friendly Names for persisted GraphQL queries)
> Friendly Names / Alias for persisted GraphQL queries
>
>
> Key: SLING-9732
> URL: https://issues.apache.org/jira/browse/SLING-9732
> Project: Sling
> Issue Type: New Feature
> Components: GraphQL
>Reporter: Gilles Knobloch
>Priority: Major
>
> The current implementation generates a URL with a hash, for instance
> \{{/persisted/9bae4aa26ea4b2e06889a1e02179e02a902211bf970185c45bceba537107e2fc}}
> It would be great to be able to specify a "friendly name" that an external
> application could use, for instance {{/persisted/listArticles}}
> Should probably have things like
> * POST - register a query, ensuring a unique name is used
> * PUT - to update existing query
> * DELETE - to remove a persisted query
> I wonder if there should be some namespacing for the query name, like
> {{/persisted/projectA/listArticles}} and {{/persisted/projectB/listArticles}}
> to give it more flexibility.
> And probably an endpoint for listing existing queries within such a scope.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SLING-9732) Friendly Names for persisted GraphQL queries
[
https://issues.apache.org/jira/browse/SLING-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Knobloch updated SLING-9732:
---
Description:
The current implementation generates a URL with a hash, for instance
\{{/persisted/9bae4aa26ea4b2e06889a1e02179e02a902211bf970185c45bceba537107e2fc}}
It would be great to be able to specify a "friendly name" that an external
application could use, for instance {{/persisted/listArticles}}
Should probably have things like
* POST - register a query, ensuring a unique name is used
* PUT - to update existing query
* DELETE - to remove a persisted query
I wonder if there should be some namespacing for the query name, like
{{/persisted/projectA/listArticles}} and {{/persisted/projectB/listArticles}}
to give it more flexibility.
And probably an endpoint for listing existing queries within such a scope.
was:
The current implementation generates a URL with a hash, for instance
\{{/persisted/9bae4aa26ea4b2e06889a1e02179e02a902211bf970185c45bceba537107e2fc}}
It would be great to be able to specify a "friendly name" that an external
application could use, for instance {{/persisted/listArticles}}
Should probably have things like
* POST - register a query, ensuring a unique name is used
* PUT - to update existing query
* DELETE - to remove a persisted query
I wonder if there should be some namespacing for the query name, like
{{/persisted/projectA/listArticles}} and {{/persisted/projectB/listArticles}}
to give it more flexibility.
> Friendly Names for persisted GraphQL queries
>
>
> Key: SLING-9732
> URL: https://issues.apache.org/jira/browse/SLING-9732
> Project: Sling
> Issue Type: New Feature
> Components: GraphQL
>Reporter: Gilles Knobloch
>Priority: Major
>
> The current implementation generates a URL with a hash, for instance
> \{{/persisted/9bae4aa26ea4b2e06889a1e02179e02a902211bf970185c45bceba537107e2fc}}
> It would be great to be able to specify a "friendly name" that an external
> application could use, for instance {{/persisted/listArticles}}
> Should probably have things like
> * POST - register a query, ensuring a unique name is used
> * PUT - to update existing query
> * DELETE - to remove a persisted query
> I wonder if there should be some namespacing for the query name, like
> {{/persisted/projectA/listArticles}} and {{/persisted/projectB/listArticles}}
> to give it more flexibility.
> And probably an endpoint for listing existing queries within such a scope.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9732) Friendly Names for persisted GraphQL queries
Gilles Knobloch created SLING-9732:
--
Summary: Friendly Names for persisted GraphQL queries
Key: SLING-9732
URL: https://issues.apache.org/jira/browse/SLING-9732
Project: Sling
Issue Type: New Feature
Components: GraphQL
Reporter: Gilles Knobloch
The current implementation generates a URL with a hash, for instance
\{{/persisted/9bae4aa26ea4b2e06889a1e02179e02a902211bf970185c45bceba537107e2fc}}
It would be great to be able to specify a "friendly name" that an external
application could use, for instance {{/persisted/listArticles}}
Should probably have things like
* POST - register a query, ensuring a unique name is used
* PUT - to update existing query
* DELETE - to remove a persisted query
I wonder if there should be some namespacing for the query name, like
{{/persisted/projectA/listArticles}} and {{/persisted/projectB/listArticles}}
to give it more flexibility.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SLING-9724) Validate queries before persisting
Gilles Knobloch created SLING-9724: -- Summary: Validate queries before persisting Key: SLING-9724 URL: https://issues.apache.org/jira/browse/SLING-9724 Project: Sling Issue Type: Improvement Components: GraphQL Reporter: Gilles Knobloch Fix For: GraphQL Core 0.0.6 GraphQL queries sent for being persisted should be validated. There should be an error message if someone tries to persist a wrong GraphQL query. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SLING-3657) Create a ResourceMerger-style ResourceProvider which merges based on resource super types
[
https://issues.apache.org/jira/browse/SLING-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027663#comment-14027663
]
Gilles Knobloch commented on SLING-3657:
[~justinedelson]: got it, fair enough
I initially didn't think about a custom root path for #2, but more something
like {{ResourceMergerService.mergeSuperTypes(Resource r}} (or whatever better
method name)
Anyway, some methods like {{ResourceMergerService.getMergedResource(Resource
r}} should probably be extended to use the desired mount path, and therefore
corresponding overriding method. Something like
{{ResourceMergerService.getMergedResource(Resource r,
ResourceMergerService.OVERLAY | ResourceMergerService.OVERRIDE)}}
Create a ResourceMerger-style ResourceProvider which merges based on resource
super types
-
Key: SLING-3657
URL: https://issues.apache.org/jira/browse/SLING-3657
Project: Sling
Issue Type: New Feature
Components: Extensions
Reporter: Justin Edelson
Attachments: SLING-3657.patch
The current MergingResourceProvider does a good job of a single use case -
merging resources relative to the search paths. A second use case for merging
is to merge resources based on their sling:resourceSuperType inheritance, i.e.
/content/siteA@sling:resourceSuperType=/content/siteB
/content/siteB@sling:resourceSuperType=/content/siteC
It should be possible to generate a merged resource which combines
/content/siteA, /content/siteB, and /content/siteC (in reverse order so that
siteA overrides siteB, etc.).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (SLING-3657) Create a ResourceMerger-style ResourceProvider which merges based on resource super types
[
https://issues.apache.org/jira/browse/SLING-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027663#comment-14027663
]
Gilles Knobloch edited comment on SLING-3657 at 6/11/14 11:54 AM:
--
[~justinedelson]: got it, fair enough
I initially didn't think about a custom root path for #2, but more something
like {{ResourceMergerService.mergeSuperTypes(Resource r)}} (or whatever better
method name)
Anyway, some methods like {{ResourceMergerService.getMergedResource(Resource
r)}} should probably be extended to use the desired mount path, and therefore
corresponding overriding method. Something like
{{ResourceMergerService.getMergedResource(Resource r,
ResourceMergerService.OVERLAY | ResourceMergerService.OVERRIDE)}}
was (Author: gknob):
[~justinedelson]: got it, fair enough
I initially didn't think about a custom root path for #2, but more something
like {{ResourceMergerService.mergeSuperTypes(Resource r}} (or whatever better
method name)
Anyway, some methods like {{ResourceMergerService.getMergedResource(Resource
r}} should probably be extended to use the desired mount path, and therefore
corresponding overriding method. Something like
{{ResourceMergerService.getMergedResource(Resource r,
ResourceMergerService.OVERLAY | ResourceMergerService.OVERRIDE)}}
Create a ResourceMerger-style ResourceProvider which merges based on resource
super types
-
Key: SLING-3657
URL: https://issues.apache.org/jira/browse/SLING-3657
Project: Sling
Issue Type: New Feature
Components: Extensions
Reporter: Justin Edelson
Attachments: SLING-3657.patch
The current MergingResourceProvider does a good job of a single use case -
merging resources relative to the search paths. A second use case for merging
is to merge resources based on their sling:resourceSuperType inheritance, i.e.
/content/siteA@sling:resourceSuperType=/content/siteB
/content/siteB@sling:resourceSuperType=/content/siteC
It should be possible to generate a merged resource which combines
/content/siteA, /content/siteB, and /content/siteC (in reverse order so that
siteA overrides siteB, etc.).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (SLING-3397) Provide a way for path operations
[ https://issues.apache.org/jira/browse/SLING-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903357#comment-13903357 ] Gilles Knobloch commented on SLING-3397: +1 Provide a way for path operations - Key: SLING-3397 URL: https://issues.apache.org/jira/browse/SLING-3397 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: Resource Merger 1.0.0 With the resource merger we have a new resource provider which is mounted somewhere in the resource tree. While the resource resolver has a method to get the search path, there is no way to find out, the mnt point for the resource merger. In addition, in some cases you already have a resource from within a search path and you want to access the merged resource -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (SLING-3397) Provide a way for path operations
[
https://issues.apache.org/jira/browse/SLING-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Knobloch updated SLING-3397:
---
Attachment: SLING-3397.patch
I think this has to be done through a service, and not just a utility class.
Indeed, you need to get the value of the merge root path and access to resolver
search paths (which you could solve through passing the resolved as first
argument - but merge root path would still be missing).
My proposal is to make the {{ResourceProviderFactory}} implement a new service
{{ResourceMergerService}}, which contains the 3 methods [~cziegeler] proposed.
Misc:
* Fixed {{sling.mergedResource}} as metadata flag instead of
{{sling.mappedResource}} - I guess it's a typo from my initial patch
* Fixed an issue in how the merge root path is initialized if it ends with a
{{/}}
I tested the provided patch in my application and it seems to work fine.
Provide a way for path operations
-
Key: SLING-3397
URL: https://issues.apache.org/jira/browse/SLING-3397
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
Fix For: Resource Merger 1.0.0
Attachments: SLING-3397.patch
With the resource merger we have a new resource provider which is mounted
somewhere in the resource tree.
While the resource resolver has a method to get the search path, there is no
way to find out, the mnt point for the resource merger.
In addition, in some cases you already have a resource from within a search
path and you want to access the merged resource
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (SLING-2986) Merged Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Knobloch updated SLING-2986: --- Attachment: SLING-2986-WithService.zip SLING-2986.zip Sending two archives as patches: * one without the Resource merger service * one with the service I agree it's not needed so far, but as mentioned by [~alexander.klimetschek], it makes sense to have it if you want to use the mechanism at application level. As we might need it anyway at one point, why not adding it from the beginning. Merged Resource Provider Key: SLING-2986 URL: https://issues.apache.org/jira/browse/SLING-2986 Project: Sling Issue Type: New Feature Components: ResourceResolver Reporter: Gilles Knobloch Attachments: SLING-2986-WithService.zip, SLING-2986.zip As exchanged once with Felix Meschberger, the idea is to implement a custom resource provider, with ability to merge multiple resources based on your search paths. For instance, if your search paths are /apps /libs Hitting /merge/my/resource/is/here will check /apps/my/resource/is/here /libs/my/resource/is/here There are some options like: - add/override property - delete a property of the resource under /libs - reorder nodes if available I intend to submit this patch as soon as possible. Code is currently located at https://github.com/gknob/sling-resourcemerger -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-2986) Merged Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876573#comment-13876573 ] Gilles Knobloch commented on SLING-2986: BTW, i agree tests are still missing :-) Merged Resource Provider Key: SLING-2986 URL: https://issues.apache.org/jira/browse/SLING-2986 Project: Sling Issue Type: New Feature Components: ResourceResolver Reporter: Gilles Knobloch As exchanged once with Felix Meschberger, the idea is to implement a custom resource provider, with ability to merge multiple resources based on your search paths. For instance, if your search paths are /apps /libs Hitting /merge/my/resource/is/here will check /apps/my/resource/is/here /libs/my/resource/is/here There are some options like: - add/override property - delete a property of the resource under /libs - reorder nodes if available I intend to submit this patch as soon as possible. Code is currently located at https://github.com/gknob/sling-resourcemerger -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (SLING-3206) Create an API to handle resource vanity paths
[
https://issues.apache.org/jira/browse/SLING-3206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13806073#comment-13806073
]
Gilles Knobloch commented on SLING-3206:
I did not yet had a look at how vanity paths are evaluated (sorry), but in
context of SLING-2986, I would need the vanity path to be set of the merged
resource.
For instance, if you have {{sling:vanityPath}} = {{/mypath}} set on
{{/libs/my/resource}}, the vanity path should actually go to
{{/merge/my/resource}}. I could of course use request filters to redirect, but
then the URL would change. I'd prefer if it's integrated in the vanity path
evaluation.
Create an API to handle resource vanity paths
-
Key: SLING-3206
URL: https://issues.apache.org/jira/browse/SLING-3206
Project: Sling
Issue Type: Improvement
Components: API
Reporter: Carsten Ziegeler
Right now vanity path handling is complicated, it would be nice to have a
central API which allows to set a vanity path for a resource and to query if
a vanity path for a resource is set.
Maybe a method getting all vanity paths back could be added as well.
The implementation would directly write into the mapping structure in the
resource tree. For the query part, it would mark its own entries to easily
identify them in contrast to entries created by other means
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (SLING-2986) Merged Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805207#comment-13805207 ] Gilles Knobloch edited comment on SLING-2986 at 10/25/13 10:28 AM: --- [~jsedding], I logged issues (and fixed) for both of your comments: * https://github.com/gknob/sling-resourcemerger/issues/9 * https://github.com/gknob/sling-resourcemerger/issues/10 was (Author: gknob): [~jsedding], I adressed both of your comments: * https://github.com/gknob/sling-resourcemerger/issues/9 * https://github.com/gknob/sling-resourcemerger/issues/10 Merged Resource Provider Key: SLING-2986 URL: https://issues.apache.org/jira/browse/SLING-2986 Project: Sling Issue Type: New Feature Components: ResourceResolver Reporter: Gilles Knobloch As exchanged once with Felix Meschberger, the idea is to implement a custom resource provider, with ability to merge multiple resources based on your search paths. For instance, if your search paths are /apps /libs Hitting /merge/my/resource/is/here will check /apps/my/resource/is/here /libs/my/resource/is/here There are some options like: - add/override property - delete a property of the resource under /libs - reorder nodes if available I intend to submit this patch as soon as possible. Code is currently located at https://github.com/gknob/sling-resourcemerger -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-2986) Merged Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13805207#comment-13805207 ] Gilles Knobloch commented on SLING-2986: [~jsedding], I adressed both of your comments: * https://github.com/gknob/sling-resourcemerger/issues/9 * https://github.com/gknob/sling-resourcemerger/issues/10 Merged Resource Provider Key: SLING-2986 URL: https://issues.apache.org/jira/browse/SLING-2986 Project: Sling Issue Type: New Feature Components: ResourceResolver Reporter: Gilles Knobloch As exchanged once with Felix Meschberger, the idea is to implement a custom resource provider, with ability to merge multiple resources based on your search paths. For instance, if your search paths are /apps /libs Hitting /merge/my/resource/is/here will check /apps/my/resource/is/here /libs/my/resource/is/here There are some options like: - add/override property - delete a property of the resource under /libs - reorder nodes if available I intend to submit this patch as soon as possible. Code is currently located at https://github.com/gknob/sling-resourcemerger -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-2986) Merged Resource Provider
[
https://issues.apache.org/jira/browse/SLING-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13802834#comment-13802834
]
Gilles Knobloch commented on SLING-2986:
[~cziegeler], just realized I didn't answer your first questions.
On why introducting a new API:
* Where I am using it (outside of that package), I need to know if the resource
is a real resource or a merged one, reason for
{{org.apache.sling.resourcemerger.api.MergedResource}}
* The constants of
{{org.apache.sling.resourcemerger.api.MergedResourceConstants}} could stay
private. On the other hand, people overriding resources anyway need to know
which properties to use to achieve it, so why hiding them?
* The service is aimed to be extended and available through OSGi references in
JSPs, other classes, etc.
Could we at least agree on the main concepts?
# How to add/override a property
** Create the corresponding property within {{/apps}} (the property will have
priority based on Sling Resource Resolver configuration)
** Changing the type of the property is supported
# How to delete one or more properties
** Create the corresponding node within {{/apps}}, and set
{{sling:hideProperties}} to the list of properties to delete ({{String[]}})
** {{*}} can be used to delete all the properties
# How to delete a node (and its children)
** Create the corresponding node within {{/apps}}, and set
{{sling:hideResource}} to {{true}} ({{Boolean}})
# How to delete children of a node (but keep the properties of the node)
** Create the corresponding node within {{/apps}}, and set
{{sling:hideChildren}} to {{true}} ({{Boolean}})
# How to reorder nodes
** Create the corresponding node within {{/apps}}, and set
{{sling:orderBefore}} to the name of the sibling where that node should be
reordered before ({{String}})
** TODO: support redefining the whole list of children
Merged Resource Provider
Key: SLING-2986
URL: https://issues.apache.org/jira/browse/SLING-2986
Project: Sling
Issue Type: New Feature
Components: ResourceResolver
Reporter: Gilles Knobloch
As exchanged once with Felix Meschberger, the idea is to implement a custom
resource provider, with ability to merge multiple resources based on your
search paths.
For instance, if your search paths are
/apps
/libs
Hitting /merge/my/resource/is/here will check
/apps/my/resource/is/here
/libs/my/resource/is/here
There are some options like:
- add/override property
- delete a property of the resource under /libs
- reorder nodes if available
I intend to submit this patch as soon as possible.
Code is currently located at https://github.com/gknob/sling-resourcemerger
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (SLING-2986) Virtual Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Knobloch updated SLING-2986: --- Description: As exchanged once with Felix Meschberger, the idea is to implement a custom resource provider, with ability to merge multiple resources based on your search paths. For instance, if your search paths are /apps /libs Hitting /merge/my/resource/is/here will check /apps/my/resource/is/here /libs/my/resource/is/here There are some options like: - add/override property - delete a property of the resource under /libs - reorder nodes if available I intend to submit this patch as soon as possible. Code is currently located at https://github.com/gknob/sling-resourcemerger was: As exchanged once with Felix Meschberger, the idea is to implement a custom resource provider, with ability to merge multiple resources based on your search paths. For instance, if your search paths are /apps /libs Hitting /virtual/my/resource/is/here will check /apps/my/resource/is/here /libs/my/resource/is/here There are some options like: - add/override property - delete a property of the resource under /libs - reorder nodes if available I intend to submit this patch as soon as possible. Code is currently located at https://github.com/gknob/sling-resourcemerger Virtual Resource Provider - Key: SLING-2986 URL: https://issues.apache.org/jira/browse/SLING-2986 Project: Sling Issue Type: New Feature Components: ResourceResolver Reporter: Gilles Knobloch As exchanged once with Felix Meschberger, the idea is to implement a custom resource provider, with ability to merge multiple resources based on your search paths. For instance, if your search paths are /apps /libs Hitting /merge/my/resource/is/here will check /apps/my/resource/is/here /libs/my/resource/is/here There are some options like: - add/override property - delete a property of the resource under /libs - reorder nodes if available I intend to submit this patch as soon as possible. Code is currently located at https://github.com/gknob/sling-resourcemerger -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2986) Merged Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Knobloch updated SLING-2986: --- Summary: Merged Resource Provider (was: Virtual Resource Provider) Merged Resource Provider Key: SLING-2986 URL: https://issues.apache.org/jira/browse/SLING-2986 Project: Sling Issue Type: New Feature Components: ResourceResolver Reporter: Gilles Knobloch As exchanged once with Felix Meschberger, the idea is to implement a custom resource provider, with ability to merge multiple resources based on your search paths. For instance, if your search paths are /apps /libs Hitting /merge/my/resource/is/here will check /apps/my/resource/is/here /libs/my/resource/is/here There are some options like: - add/override property - delete a property of the resource under /libs - reorder nodes if available I intend to submit this patch as soon as possible. Code is currently located at https://github.com/gknob/sling-resourcemerger -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2986) Virtual Resource Provider
[ https://issues.apache.org/jira/browse/SLING-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13773057#comment-13773057 ] Gilles Knobloch commented on SLING-2986: I have a running prototype (tests still missing, I agree) and would be interested in getting a review from coding gurus :-) Could you please have a look at current implementation, and comment either here or on commits I did there? https://github.com/gknob/sling-resourcemerger Virtual Resource Provider - Key: SLING-2986 URL: https://issues.apache.org/jira/browse/SLING-2986 Project: Sling Issue Type: New Feature Components: ResourceResolver Reporter: Gilles Knobloch As exchanged once with Felix Meschberger, the idea is to implement a custom resource provider, with ability to merge multiple resources based on your search paths. For instance, if your search paths are /apps /libs Hitting /virtual/my/resource/is/here will check /apps/my/resource/is/here /libs/my/resource/is/here There are some options like: - add/override property - delete a property of the resource under /libs - reorder nodes if available I intend to submit this patch as soon as possible. Code is currently located at https://github.com/gknob/sling-resourcemerger -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-3044) Add exclusion rule to .gitignore for IntelliJ projects
Gilles Knobloch created SLING-3044: -- Summary: Add exclusion rule to .gitignore for IntelliJ projects Key: SLING-3044 URL: https://issues.apache.org/jira/browse/SLING-3044 Project: Sling Issue Type: Improvement Components: IDE Reporter: Gilles Knobloch Priority: Minor When using the github.com Apache mirror and importing it as IntelliJ project, there are 500+ files marked as unversioned, all located below .idea folder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-3044) Add exclusion rule to .gitignore for IntelliJ projects
[ https://issues.apache.org/jira/browse/SLING-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Knobloch updated SLING-3044: --- Attachment: SLING-3044.patch Attached a patch Add exclusion rule to .gitignore for IntelliJ projects -- Key: SLING-3044 URL: https://issues.apache.org/jira/browse/SLING-3044 Project: Sling Issue Type: Improvement Components: IDE Reporter: Gilles Knobloch Priority: Minor Attachments: SLING-3044.patch When using the github.com Apache mirror and importing it as IntelliJ project, there are 500+ files marked as unversioned, all located below .idea folder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756476#comment-13756476
]
Gilles Knobloch commented on SLING-2779:
Thanks [~cziegeler]
Support for default properties values of a resource
---
Key: SLING-2779
URL: https://issues.apache.org/jira/browse/SLING-2779
Project: Sling
Issue Type: New Feature
Components: API
Affects Versions: API 2.3.0
Reporter: Gilles Knobloch
Assignee: Carsten Ziegeler
Fix For: API 2.5.0
Attachments: SLING-2779_20130828.patch, SLING-2779.patch
I already noticed several times it would be useful to be able to specify a
default properties for a resource:
* if the resource itself contains the property, it will override the default
one.
* but if it doesn't, the default value is used.
This could be done either via:
* specifying a {{sling:defaults}} property on the resource, which contains
the path to the resource which properties will be used by default.
* providing a default map of properties
Attaching a patch for review.
For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
imagine it could go to {{org.apache.sling.api.resource}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (SLING-2780) Make ResourceMetadata read-only when delivered to client code
[ https://issues.apache.org/jira/browse/SLING-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13747463#comment-13747463 ] Gilles Knobloch edited comment on SLING-2780 at 8/29/13 8:07 PM: - [~cziegeler]: broke prototype of SLING-2986 as well, but solution proposed by [~alexander.klimetschek] is valid. Is this publicly documented somewhere? I share the same concerns, might break consumers' own resource providers. was (Author: gknob): Broke prototype of SLING-2986 as well Make ResourceMetadata read-only when delivered to client code - Key: SLING-2780 URL: https://issues.apache.org/jira/browse/SLING-2780 Project: Sling Issue Type: New Feature Components: API, ResourceResolver Affects Versions: API 2.3.0, Resource Resolver 1.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.4.0, Resource Resolver 1.0.6 As recently discussed in the mailing list, ResourceMetadata is an object which provides additional metadata information about a resource but is not intended to be changed by client code. As ResourceMetadata extends from (Hash)Map it is read/write by default and might potentially be changed by client code. We should update the API docs that this object is read-only and also enforce it in our implementation. It seems so far no one is changing the ResourceMetadata after it has left the resource resolver, therefore we can make it read-only after it is returned by the resource resolver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (SLING-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13752485#comment-13752485
]
Gilles Knobloch edited comment on SLING-2779 at 8/29/13 8:09 PM:
-
Attaching a new patch
* Changed constructor signature to use two ValueMap instead of Map, so that
CompositeValueMap relies on existing implementations of ValueMap for type
conversion
* Removed deleted properties mechanism
* Fixed keySet(), entrySet(), and values(), added more tests to cover them
* Updated JavaDoc
* Replaced some ternary statements by if-then-else
* Created org.apache.sling.api.resource.ValueMapUtil with checkKey method
* Increased version number of exported package version
was (Author: gknob):
Attaching a new patch
* Changed constructor signature to use two ValueMap instead of Map, so that
CompositeValueMap relies on existing implementations of ValueMap for type
conversion
* Fixed keySet(), entrySet(), and values(), added more tests to cover them
* Updated JavaDoc
* Replaced some ternary statements by if-then-else
* Created org.apache.sling.api.resource.ValueMapUtil with checkKey method
* Increased version number of exported package version
Support for default properties values of a resource
---
Key: SLING-2779
URL: https://issues.apache.org/jira/browse/SLING-2779
Project: Sling
Issue Type: New Feature
Components: API
Affects Versions: API 2.3.0
Reporter: Gilles Knobloch
Attachments: SLING-2779_20130828.patch, SLING-2779.patch
I already noticed several times it would be useful to be able to specify a
default properties for a resource:
* if the resource itself contains the property, it will override the default
one.
* but if it doesn't, the default value is used.
This could be done either via:
* specifying a {{sling:defaults}} property on the resource, which contains
the path to the resource which properties will be used by default.
* providing a default map of properties
Attaching a patch for review.
For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
imagine it could go to {{org.apache.sling.api.resource}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Knobloch updated SLING-2779:
---
Attachment: SLING-2779_20130828.patch
Attaching a new patch
* Changed constructor signature to use two ValueMap instead of Map, so that
CompositeValueMap relies on existing implementations of ValueMap for type
conversion
* Fixed keySet(), entrySet(), and values(), added more tests to cover them
* Updated JavaDoc
* Replaced some ternary statements by if-then-else
* Created org.apache.sling.api.resource.ValueMapUtil with checkKey method
* Increased version number of exported package version
Support for default properties values of a resource
---
Key: SLING-2779
URL: https://issues.apache.org/jira/browse/SLING-2779
Project: Sling
Issue Type: New Feature
Components: API
Affects Versions: API 2.3.0
Reporter: Gilles Knobloch
Attachments: SLING-2779_20130828.patch, SLING-2779.patch
I already noticed several times it would be useful to be able to specify a
default properties for a resource:
* if the resource itself contains the property, it will override the default
one.
* but if it doesn't, the default value is used.
This could be done either via:
* specifying a {{sling:defaults}} property on the resource, which contains
the path to the resource which properties will be used by default.
* providing a default map of properties
Attaching a patch for review.
For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
imagine it could go to {{org.apache.sling.api.resource}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13751036#comment-13751036
]
Gilles Knobloch commented on SLING-2779:
Thanks for comments, I am reviewing the patch.
{quote}
* If the DefaultsValueMap composites two maps, I wonder why it is a ValueMap...
Particularly since this implementation does not properly support type
conversions and expectations as defined for ValueMap
* The JavaDoc on the constructors are wrong and not very understandable
* The get(String) method does not really convert types thus, the get(String,
Class?) method might in fact throw a ClassCastException which is not
intended. I would assume that get(String) would actually turn to get(String,
Class?) with an appropriate type instead of the other way around. Likewise
for get(String, T)
{quote}
Will implement it correctly
{quote}
* The ?: expressions are much complicated (and not enough parenthesized) to
understand. Please change to explicit if-then-else. Otherwise errors may creep
in which are hard to find
{quote}
I can change to if statements if it helps to understand
{quote}
* The keySet(), entrySet(), and values() methods don't work: They either refer
to the wrong defaults entries (e.g. values()) or modify the defaults map (e.g.
keySet() gets the keySet() from the defaults and just adds to that set. This
may or may not work and modify the defaults map, actually !
{quote}
I noticed it when adding more tests and already changed them
{quote}
* The checkKey() method seems duplicate with existing ValueMap implementations
{quote}
It's part of {{org.apache.sling.jcr.resource.*}} implementations and already
duplicated twice even there. I couldn't reuse them.
I think this can be addressed separately, maybe with a utility method.
Support for default properties values of a resource
---
Key: SLING-2779
URL: https://issues.apache.org/jira/browse/SLING-2779
Project: Sling
Issue Type: New Feature
Components: API
Affects Versions: API 2.3.0
Reporter: Gilles Knobloch
Attachments: SLING-2779.patch
I already noticed several times it would be useful to be able to specify a
default properties for a resource:
* if the resource itself contains the property, it will override the default
one.
* but if it doesn't, the default value is used.
This could be done either via:
* specifying a {{sling:defaults}} property on the resource, which contains
the path to the resource which properties will be used by default.
* providing a default map of properties
Attaching a patch for review.
For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
imagine it could go to {{org.apache.sling.api.resource}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2780) Make ResourceMetadata read-only when delivered to client code
[ https://issues.apache.org/jira/browse/SLING-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13747463#comment-13747463 ] Gilles Knobloch commented on SLING-2780: Broke prototype of SLING-2986 as well Make ResourceMetadata read-only when delivered to client code - Key: SLING-2780 URL: https://issues.apache.org/jira/browse/SLING-2780 Project: Sling Issue Type: New Feature Components: API, ResourceResolver Affects Versions: API 2.3.0, Resource Resolver 1.0.4 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: API 2.4.0, Resource Resolver 1.0.6 As recently discussed in the mailing list, ResourceMetadata is an object which provides additional metadata information about a resource but is not intended to be changed by client code. As ResourceMetadata extends from (Hash)Map it is read/write by default and might potentially be changed by client code. We should update the API docs that this object is read-only and also enforce it in our implementation. It seems so far no one is changing the ResourceMetadata after it has left the resource resolver, therefore we can make it read-only after it is returned by the resource resolver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13745959#comment-13745959
]
Gilles Knobloch commented on SLING-2779:
[~cziegeler], thanks for the review.
{quote}
I'm not sure about the deletedProperties part - does this mean you pass in a
defaults map with a set of deleted properies and if the default map contains a
property which is in the deleted set, this one is ignored? Why not simply
removing the properties from the default map then?
{quote}
Yes that's the idea.
Being able to provide list of deleted properties is more a convenient way,
especially if you provide an unmodifiable Map as defaults (you would have to
create a temporary one and remove there).
Instead of exposing it into a constructor, it could also just be a method like
{{setDeletedProperties}} or {{setIgnoredProperties}} (I don't care about the
name).
{quote}
For the location I think this makes sense to have it in the api bundle.
I'm not sure about the name, DefaultsValueMap - while it sounds fine it's
similar to the CompositeMap
(http://commons.apache.org/proper/commons-collections/javadocs/api-3.2.1/index.html).
{quote}
If I understood correctly, it should be
{{org.apache.sling.api.resource.CompositeValueMap}} (at
{{bundles/api/src/main/java/org/apache/sling/api/resource}}).
Support for default properties values of a resource
---
Key: SLING-2779
URL: https://issues.apache.org/jira/browse/SLING-2779
Project: Sling
Issue Type: New Feature
Components: API
Affects Versions: API 2.3.0
Reporter: Gilles Knobloch
Attachments: SLING-2779.patch
I already noticed several times it would be useful to be able to specify a
default properties for a resource:
* if the resource itself contains the property, it will override the default
one.
* but if it doesn't, the default value is used.
This could be done either via:
* specifying a {{sling:defaults}} property on the resource, which contains
the path to the resource which properties will be used by default.
* providing a default map of properties
Attaching a patch for review.
For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
imagine it could go to {{org.apache.sling.api.resource}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Knobloch updated SLING-2779:
---
Attachment: (was: DefaultsValueMap.java)
Support for default properties values of a resource
---
Key: SLING-2779
URL: https://issues.apache.org/jira/browse/SLING-2779
Project: Sling
Issue Type: New Feature
Components: API
Affects Versions: API 2.3.0
Reporter: Gilles Knobloch
I already noticed several times it would be useful to be able to specify a
default properties for a resource:
* if the resource itself contains the property, it will override the default
one.
* but if it doesn't, the default value is used.
This could be done either via:
* specifying a {{sling:defaults}} property on the resource, which contains
the path to the resource which properties will be used by default.
* providing a default map of properties
Attaching a patch for review.
For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
imagine it could go to {{org.apache.sling.api.resource}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Knobloch updated SLING-2779:
---
Attachment: (was: DefaultsValueMap.java)
Support for default properties values of a resource
---
Key: SLING-2779
URL: https://issues.apache.org/jira/browse/SLING-2779
Project: Sling
Issue Type: New Feature
Components: API
Affects Versions: API 2.3.0
Reporter: Gilles Knobloch
I already noticed several times it would be useful to be able to specify a
default properties for a resource:
* if the resource itself contains the property, it will override the default
one.
* but if it doesn't, the default value is used.
This could be done either via:
* specifying a {{sling:defaults}} property on the resource, which contains
the path to the resource which properties will be used by default.
* providing a default map of properties
Attaching a patch for review.
For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
imagine it could go to {{org.apache.sling.api.resource}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (SLING-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13745066#comment-13745066
]
Gilles Knobloch edited comment on SLING-2779 at 8/20/13 3:50 PM:
-
I finally had some time to rework this
* Applied most of the changes requested by [~cziegeler] and
[~alexander.klimetschek]
* Except support for a path as property name, i.e. {{./my/nested/prop}} as this
is JCR specific (discussed it with [~cziegeler])
* Added Unit tests
I also added support for:
* Merge (default) or override mode
** Merge: getting a key would return the current property map's value (if
available), even if the corresponding default does not exist
** Override: getting a key would return codenull/code if the corresponding
default does not exist
* Ability to delete one or more properties from defaults by providing a Set in
the constructor
Not sure where this should be put in the Sling source code. For now, it's an
own bundle located at {{bundles/defaults}} folder
was (Author: gknob):
I finally had some time to rework this
* Applied most of the changes requested by [~cziegeler] and
[~alexander.klimetschek]
* Except support for a path as property name, i.e. {{./my/nested/prop}} as this
is JCR specific (discussed it with [~cziegeler])
* Added Unit tests
Not sure where this should be put in the Sling source code. For now, it's an
own bundle located at {{bundles/defaults}} folder
Support for default properties values of a resource
---
Key: SLING-2779
URL: https://issues.apache.org/jira/browse/SLING-2779
Project: Sling
Issue Type: New Feature
Components: API
Affects Versions: API 2.3.0
Reporter: Gilles Knobloch
Attachments: SLING-2779.patch
I already noticed several times it would be useful to be able to specify a
default properties for a resource:
* if the resource itself contains the property, it will override the default
one.
* but if it doesn't, the default value is used.
This could be done either via:
* specifying a {{sling:defaults}} property on the resource, which contains
the path to the resource which properties will be used by default.
* providing a default map of properties
Attaching a patch for review.
For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
imagine it could go to {{org.apache.sling.api.resource}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (SLING-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13745066#comment-13745066
]
Gilles Knobloch edited comment on SLING-2779 at 8/20/13 3:41 PM:
-
I finally had some time to rework this
* Applied most of the changes requested by [~cziegeler] and
[~alexander.klimetschek]
* Except support for a path as property name, i.e. {{./my/nested/prop}} as this
is JCR specific (discussed it with [~cziegeler])
* Added Unit tests
Not sure where this should be put in the Sling source code. For now, it's an
own bundle located at {{bundles/defaults}} folder
was (Author: gknob):
I finally had some time to rework this
* Applied most of the changes requested by [~cziegeler] and
[~alexander.klimetschek]
* Except support for a path as property name, i.e. {{./my/nested/prop}} as this
is JCR specific (discussed it with [~cziegeler]
* Added Unit tests
Not sure where this should be put in the Sling source code. For now, it's an
own bundle located at {{bundles/defaults}} folder
Support for default properties values of a resource
---
Key: SLING-2779
URL: https://issues.apache.org/jira/browse/SLING-2779
Project: Sling
Issue Type: New Feature
Components: API
Affects Versions: API 2.3.0
Reporter: Gilles Knobloch
Attachments: SLING-2779.patch
I already noticed several times it would be useful to be able to specify a
default properties for a resource:
* if the resource itself contains the property, it will override the default
one.
* but if it doesn't, the default value is used.
This could be done either via:
* specifying a {{sling:defaults}} property on the resource, which contains
the path to the resource which properties will be used by default.
* providing a default map of properties
Attaching a patch for review.
For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
imagine it could go to {{org.apache.sling.api.resource}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Knobloch updated SLING-2779:
---
Attachment: SLING-2779.patch
I finally had some time to rework this
* Applied most of the changes requested by [~cziegeler] and
[~alexander.klimetschek]
* Except support for a path as property name, i.e. {{./my/nested/prop}} as this
is JCR specific (discussed it with [~cziegeler]
* Added Unit tests
Not sure where this should be put in the Sling source code. For now, it's an
own bundle located at {{bundles/defaults}} folder
Support for default properties values of a resource
---
Key: SLING-2779
URL: https://issues.apache.org/jira/browse/SLING-2779
Project: Sling
Issue Type: New Feature
Components: API
Affects Versions: API 2.3.0
Reporter: Gilles Knobloch
Attachments: SLING-2779.patch
I already noticed several times it would be useful to be able to specify a
default properties for a resource:
* if the resource itself contains the property, it will override the default
one.
* but if it doesn't, the default value is used.
This could be done either via:
* specifying a {{sling:defaults}} property on the resource, which contains
the path to the resource which properties will be used by default.
* providing a default map of properties
Attaching a patch for review.
For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
imagine it could go to {{org.apache.sling.api.resource}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2986) Virtual Resource Provider
Gilles Knobloch created SLING-2986: -- Summary: Virtual Resource Provider Key: SLING-2986 URL: https://issues.apache.org/jira/browse/SLING-2986 Project: Sling Issue Type: New Feature Components: ResourceResolver Reporter: Gilles Knobloch As exchanged once with Felix Meschberger, the idea is to implement a custom resource provider, with ability to merge multiple resources based on your search paths. For instance, if your search paths are /apps /libs Hitting /virtual/my/resource/is/here will check /apps/my/resource/is/here /libs/my/resource/is/here There are some options like: - add/override property - delete a property of the resource under /libs - reorder nodes if available I intend to submit this patch as soon as possible. Code is currently located at https://github.com/gknob/sling-resourcemerger -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2811) Sling documentation exposes commercial product classes
Gilles Knobloch created SLING-2811: -- Summary: Sling documentation exposes commercial product classes Key: SLING-2811 URL: https://issues.apache.org/jira/browse/SLING-2811 Project: Sling Issue Type: Bug Components: Documentation Reporter: Gilles Knobloch Priority: Minor While checking the documentation of Sling Servlet Filter Support [0], I figured out it references some commercial product classes: * com.day.cq.wcm.core.impl.WCMComponentFilter * com.day.cq.theme.impl.ThemeResolverFilter * com.day.cq.wcm.foundation.forms.impl.FormsHandlingServlet ... An open-source project should not reference commercial products' classes in its documentation. [0] http://sling.apache.org/site/filters.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Knobloch updated SLING-2779:
---
Attachment: DefaultsValueMap.java
Thanks for comments.
I attached a new version of the file:
* [~cziegeler]: I removed the constructor with only a {{Resource}} and
{{sling:defaults}} mechanism
* [~alexander.klimetschek]: I added some support like if you get ./propName,
but not yet the whole logic with nested properties as defaults. might be done
later.
Support for default properties values of a resource
---
Key: SLING-2779
URL: https://issues.apache.org/jira/browse/SLING-2779
Project: Sling
Issue Type: New Feature
Components: API
Affects Versions: API 2.3.0
Reporter: Gilles Knobloch
Attachments: DefaultsValueMap.java, DefaultsValueMap.java
I already noticed several times it would be useful to be able to specify a
default properties for a resource:
* if the resource itself contains the property, it will override the default
one.
* but if it doesn't, the default value is used.
This could be done either via:
* specifying a {{sling:defaults}} property on the resource, which contains
the path to the resource which properties will be used by default.
* providing a default map of properties
Attaching a patch for review.
For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
imagine it could go to {{org.apache.sling.api.resource}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SLING-2779) Support for default properties values of a resource
Gilles Knobloch created SLING-2779:
--
Summary: Support for default properties values of a resource
Key: SLING-2779
URL: https://issues.apache.org/jira/browse/SLING-2779
Project: Sling
Issue Type: New Feature
Components: API
Affects Versions: API 2.3.0
Reporter: Gilles Knobloch
I already noticed several times it would be useful to be able to specify a
default properties for a resource:
* if the resource itself contains the property, it will override the default
one.
* but if it doesn't, the default value is used.
This could be done either via:
* specifying a {{sling:defaults}} property on the resource, which contains the
path to the resource which properties will be used by default.
* providing a default map of properties
Attaching a patch for review.
For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
imagine it could go to {{org.apache.sling.api.resource}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2779) Support for default properties values of a resource
[
https://issues.apache.org/jira/browse/SLING-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Knobloch updated SLING-2779:
---
Attachment: DefaultsValueMap.java
Attached file
Support for default properties values of a resource
---
Key: SLING-2779
URL: https://issues.apache.org/jira/browse/SLING-2779
Project: Sling
Issue Type: New Feature
Components: API
Affects Versions: API 2.3.0
Reporter: Gilles Knobloch
Attachments: DefaultsValueMap.java
I already noticed several times it would be useful to be able to specify a
default properties for a resource:
* if the resource itself contains the property, it will override the default
one.
* but if it doesn't, the default value is used.
This could be done either via:
* specifying a {{sling:defaults}} property on the resource, which contains
the path to the resource which properties will be used by default.
* providing a default map of properties
Attaching a patch for review.
For testing purpose, I put it under {{org.apache.sling.defaults}}, but I
imagine it could go to {{org.apache.sling.api.resource}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
