[jira] [Commented] (SLING-2533) ResourceCollector fails to resolve selector scripts when no extension is used
[ https://issues.apache.org/jira/browse/SLING-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13415190#comment-13415190 ] dan mcweeney commented on SLING-2533: - This grew out of a need to make Sling more aware of the Accept header instead of just relying on the extension. If a client does a GET to a URL without an extension but that also has a well defined Accept header, e.g. application/json that is easy to route. I agree that there is ambiguity if a client does a GET with no extension and an Accept header of */* but the server can the just do it's best and send back some sensible default. I think all this patch is trying to do is establish some sensible defaults for script resolution when a request like that occurs or if Sling doesn't become more aware of Accept header. ResourceCollector fails to resolve selector scripts when no extension is used - Key: SLING-2533 URL: https://issues.apache.org/jira/browse/SLING-2533 Project: Sling Issue Type: Bug Components: Servlets Affects Versions: Servlets Resolver 2.1.2 Environment: this applies to version 2.1.3-SNAPSHOT Reporter: Tyson Norris Attachments: sling-2533.patch A specific use case where this comes up is: request: http://localhost:4502/content/test/include In JCR repo: - node at content/test/include has sling:resourceType=test/main - script to render this resource is /apps/test/main/GET.jsp - script to render different type with selector referneced via: sling:include resourceType=test/sometype replaceSelectors=special/ - script to render the different type is /apps/test/sometype/special.jsp in this case, special.jsp script is only resoved if renamed to special.GET.jsp Note that: - no extension on requested URL - using a replaced selector in sling:include should behave similar to specifying an exentsion when the extension is null, I think. See attached patch to ResourceCollector and ScriptSelectionTest -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-3002) Make the Mongo Resource Provider easy to subclass
[ https://issues.apache.org/jira/browse/SLING-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dan mcweeney updated SLING-3002: Attachment: enableSubClass.patch Patch to loosen the provider to make it easier to subclass. Make the Mongo Resource Provider easy to subclass - Key: SLING-3002 URL: https://issues.apache.org/jira/browse/SLING-3002 Project: Sling Issue Type: Improvement Components: Extensions Reporter: dan mcweeney Attachments: enableSubClass.patch The Mongo Provider isn't the easiest thing to extend and specialize. Most of the methods are marked as private and once those are loosened up other issues came up, like changing the field that ID is stored in etc. Attached is a patch to help make subclassing possible. -- 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-3002) Make the Mongo Resource Provider easy to subclass
dan mcweeney created SLING-3002: --- Summary: Make the Mongo Resource Provider easy to subclass Key: SLING-3002 URL: https://issues.apache.org/jira/browse/SLING-3002 Project: Sling Issue Type: Improvement Components: Extensions Reporter: dan mcweeney Attachments: enableSubClass.patch The Mongo Provider isn't the easiest thing to extend and specialize. Most of the methods are marked as private and once those are loosened up other issues came up, like changing the field that ID is stored in etc. Attached is a patch to help make subclassing possible. -- 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-3002) Make the Mongo Resource Provider easier to subclass
[ https://issues.apache.org/jira/browse/SLING-3002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dan mcweeney updated SLING-3002: Summary: Make the Mongo Resource Provider easier to subclass (was: Make the Mongo Resource Provider easy to subclass) Make the Mongo Resource Provider easier to subclass --- Key: SLING-3002 URL: https://issues.apache.org/jira/browse/SLING-3002 Project: Sling Issue Type: Improvement Components: Extensions Reporter: dan mcweeney Attachments: enableSubClass.patch The Mongo Provider isn't the easiest thing to extend and specialize. Most of the methods are marked as private and once those are loosened up other issues came up, like changing the field that ID is stored in etc. Attached is a patch to help make subclassing possible. -- 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-4024) Allow the ResourceResolver Mock Factory to initialize a Resolver via JSON
dan mcweeney created SLING-4024: --- Summary: Allow the ResourceResolver Mock Factory to initialize a Resolver via JSON Key: SLING-4024 URL: https://issues.apache.org/jira/browse/SLING-4024 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Testing ResourceResolver Mock 0.3.0 Reporter: dan mcweeney Sling can easily produce JSON for a tree of nodes. It would make things much easier to be able to initialize the Resource Resolvers produced from the MockResourceResolverFactory with this JSON. It will allow people to create test fixtures based off real data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (SLING-4024) Allow the ResourceResolver Mock Factory to initialize a Resolver via JSON
[ https://issues.apache.org/jira/browse/SLING-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dan mcweeney updated SLING-4024: Comment: was deleted (was: A pull request is available that creates this functionality here: https://github.com/apache/sling/pull/30) Allow the ResourceResolver Mock Factory to initialize a Resolver via JSON - Key: SLING-4024 URL: https://issues.apache.org/jira/browse/SLING-4024 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Testing ResourceResolver Mock 0.3.0 Reporter: dan mcweeney Sling can easily produce JSON for a tree of nodes. It would make things much easier to be able to initialize the Resource Resolvers produced from the MockResourceResolverFactory with this JSON. It will allow people to create test fixtures based off real data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4024) Allow the ResourceResolver Mock Factory to initialize a Resolver via JSON
[ https://issues.apache.org/jira/browse/SLING-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14165809#comment-14165809 ] dan mcweeney commented on SLING-4024: - A pull request is available that creates this functionality here: https://github.com/apache/sling/pull/30 Allow the ResourceResolver Mock Factory to initialize a Resolver via JSON - Key: SLING-4024 URL: https://issues.apache.org/jira/browse/SLING-4024 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Testing ResourceResolver Mock 0.3.0 Reporter: dan mcweeney Sling can easily produce JSON for a tree of nodes. It would make things much easier to be able to initialize the Resource Resolvers produced from the MockResourceResolverFactory with this JSON. It will allow people to create test fixtures based off real data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4024) Allow the ResourceResolver Mock Factory to initialize a Resolver via JSON
[ https://issues.apache.org/jira/browse/SLING-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14165814#comment-14165814 ] dan mcweeney commented on SLING-4024: - I could use some advice about the API and if the Factory should be shared amongst resolvers created from one builder. Allow the ResourceResolver Mock Factory to initialize a Resolver via JSON - Key: SLING-4024 URL: https://issues.apache.org/jira/browse/SLING-4024 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Testing ResourceResolver Mock 0.3.0 Reporter: dan mcweeney Sling can easily produce JSON for a tree of nodes. It would make things much easier to be able to initialize the Resource Resolvers produced from the MockResourceResolverFactory with this JSON. It will allow people to create test fixtures based off real data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SLING-4024) Allow the ResourceResolver Mock Factory to initialize a Resolver via JSON
[ https://issues.apache.org/jira/browse/SLING-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dan mcweeney updated SLING-4024: Description: Sling can easily produce JSON for a tree of resources. It would make things much easier to be able to initialize the Resource Resolvers produced from the MockResourceResolverFactory with this JSON. It will allow people to create test fixtures based off real data. was: Sling can easily produce JSON for a tree of nodes. It would make things much easier to be able to initialize the Resource Resolvers produced from the MockResourceResolverFactory with this JSON. It will allow people to create test fixtures based off real data. Allow the ResourceResolver Mock Factory to initialize a Resolver via JSON - Key: SLING-4024 URL: https://issues.apache.org/jira/browse/SLING-4024 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Testing ResourceResolver Mock 0.3.0 Reporter: dan mcweeney Sling can easily produce JSON for a tree of resources. It would make things much easier to be able to initialize the Resource Resolvers produced from the MockResourceResolverFactory with this JSON. It will allow people to create test fixtures based off real data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-4024) Allow the ResourceResolver Mock Factory to initialize a Resolver via JSON
[ https://issues.apache.org/jira/browse/SLING-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14166882#comment-14166882 ] dan mcweeney commented on SLING-4024: - Very cool, had no idea those things existed. Getting all these together under sling makes a lot of sense. Allow the ResourceResolver Mock Factory to initialize a Resolver via JSON - Key: SLING-4024 URL: https://issues.apache.org/jira/browse/SLING-4024 Project: Sling Issue Type: Improvement Components: Testing Affects Versions: Testing ResourceResolver Mock 0.3.0 Reporter: dan mcweeney Sling can easily produce JSON for a tree of resources. It would make things much easier to be able to initialize the Resource Resolvers produced from the MockResourceResolverFactory with this JSON. It will allow people to create test fixtures based off real data. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-2919) Support handlebars as a scripting language
[ https://issues.apache.org/jira/browse/SLING-2919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14943805#comment-14943805 ] dan mcweeney commented on SLING-2919: - I have a complete handlebars engine that has been used a fair bit already in another project. It would be easy for me to extract some project specific bits and donate it to Sling, is there still interest in something like that? It's based on the pure java jknack project linked above. > Support handlebars as a scripting language > -- > > Key: SLING-2919 > URL: https://issues.apache.org/jira/browse/SLING-2919 > Project: Sling > Issue Type: New Feature > Components: Scripting >Reporter: Ian Boston >Assignee: Ian Boston > > Handlebars.js is a popular scripting language used client side. The markup is > simple and straightforward, much like velocity in some ways, but without any > of the confusion ove template or MVC. There is a version of Handlebars for > java that uses an identical template language and appears to be well > supported and has some nice features such as pre-compiling scripts serverside > into Javascript functions and modules. (not all that relevant for server side > scripting, but interesting none the less). > I am going to experiment with a Sling Script engine in the whiteboard area to > see if its viable to use handlebars java as an alternative to JSP. > Handlebars Java, A2 Liencesed: https://github.com/jknack/handlebars.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SLING-6183) Sling Models - Provide a mechanism to export model objects via servlets
[
https://issues.apache.org/jira/browse/SLING-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15610284#comment-15610284
]
dan mcweeney commented on SLING-6183:
-
So in the latter case (List) would you get an array of JSON objects
that represent the ItemModel exported according to it's @Export directive?
> Sling Models - Provide a mechanism to export model objects via servlets
> ---
>
> Key: SLING-6183
> URL: https://issues.apache.org/jira/browse/SLING-6183
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Justin Edelson
> Fix For: Sling Models API 1.3.0, Sling Models Impl 1.3.0
>
> Attachments: SLING-6183.patch
>
>
> I would like to introduce a new feature to Sling Models named Exporters.
> Exporters allow for a model class to be exported into a specific Java object
> type in a automated fashion. The simplest example is to support String
> serialization, although different Exporters may support whatever target
> classes they see fit.
> Exporters are implemented through an SPI. This initial contribution includes
> an exporter using the Jackson library which supports both {{String}} and
> {{Map}} exports.
> Interfacing with the registered Exporters is done through three new methods
> on the {{ModelFactory}} interface:
> * {{exportMode}}
> * {{exportModelForResource}}
> * {{exportModelForRequest}}
> In addition, using these functionality, model objects can have
> automatically-registered servlets which export the model (from either the
> request or the request's resource) as a {{String}} and then serve that
> {{String}} to the client.
> Registering these servlets is done through a new annotation named
> {{@Exporter}}
> For example, you might add this annotation to a Model class
> {{@Exporter(name = 'jackson', extension = 'json')}}
> This will register a servlet for the model's resource type with the extension
> `json` and a selector of `model` (by default, the {{@Exporter}} annotation
> can also define a different selector).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6183) Sling Models - Provide a mechanism to export model objects via servlets
[
https://issues.apache.org/jira/browse/SLING-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15606449#comment-15606449
]
dan mcweeney commented on SLING-6183:
-
So can you explain what happens when one model points at another model? For
example, I have an Order Model what uses:
{code}
@Exporter(name = 'jackson', extension = 'json')
{code}
which has a method:
{code}
@JsonProperty(“items”)
public List getItems();
{code}
The resources returned by the getItems method have a resourceType which is
serviced by a Sling Model. When the Order model gets exported what is in that
list?
If it's an array of Exported Models what named exporter does it use, the one
defined with the Order or the one defined with the "Item"?
Another slight variation what if it returns a List where Item is an
object type managed by Sling Models, which also has an @Exporter annotation?
Also I wonder if it would be better to support a Media type instead of just an
extension. I realize content negotiation isn't really fully baked into Sling
but I can see where you might want to be able to support a plain
application/json export and also a application/vnd.org.sling.models.item+json.
> Sling Models - Provide a mechanism to export model objects via servlets
> ---
>
> Key: SLING-6183
> URL: https://issues.apache.org/jira/browse/SLING-6183
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Justin Edelson
> Fix For: Sling Models API 1.3.0, Sling Models Impl 1.3.0
>
> Attachments: SLING-6183.patch
>
>
> I would like to introduce a new feature to Sling Models named Exporters.
> Exporters allow for a model class to be exported into a specific Java object
> type in a automated fashion. The simplest example is to support String
> serialization, although different Exporters may support whatever target
> classes they see fit.
> Exporters are implemented through an SPI. This initial contribution includes
> an exporter using the Jackson library which supports both {{String}} and
> {{Map}} exports.
> Interfacing with the registered Exporters is done through three new methods
> on the {{ModelFactory}} interface:
> * {{exportMode}}
> * {{exportModelForResource}}
> * {{exportModelForRequest}}
> In addition, using these functionality, model objects can have
> automatically-registered servlets which export the model (from either the
> request or the request's resource) as a {{String}} and then serve that
> {{String}} to the client.
> Registering these servlets is done through a new annotation named
> {{@Exporter}}
> For example, you might add this annotation to a Model class
> {{@Exporter(name = 'jackson', extension = 'json')}}
> This will register a servlet for the model's resource type with the extension
> `json` and a selector of `model` (by default, the {{@Exporter}} annotation
> can also define a different selector).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6183) Sling Models - Provide a mechanism to export model objects via servlets
[
https://issues.apache.org/jira/browse/SLING-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15609335#comment-15609335
]
dan mcweeney commented on SLING-6183:
-
You can bind a model to a resource type now and make that model be "exported".
When sling models runs across a Resource to export that is a model and it
doesn't get exported seems like a pretty big weakness and makes this a lot less
useful as it basically can't do "deep" objects.
I guess if you don't plan on supporting "deep" graphs of objects then multiple
exporters aren't a problem.
> Sling Models - Provide a mechanism to export model objects via servlets
> ---
>
> Key: SLING-6183
> URL: https://issues.apache.org/jira/browse/SLING-6183
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Justin Edelson
> Fix For: Sling Models API 1.3.0, Sling Models Impl 1.3.0
>
> Attachments: SLING-6183.patch
>
>
> I would like to introduce a new feature to Sling Models named Exporters.
> Exporters allow for a model class to be exported into a specific Java object
> type in a automated fashion. The simplest example is to support String
> serialization, although different Exporters may support whatever target
> classes they see fit.
> Exporters are implemented through an SPI. This initial contribution includes
> an exporter using the Jackson library which supports both {{String}} and
> {{Map}} exports.
> Interfacing with the registered Exporters is done through three new methods
> on the {{ModelFactory}} interface:
> * {{exportMode}}
> * {{exportModelForResource}}
> * {{exportModelForRequest}}
> In addition, using these functionality, model objects can have
> automatically-registered servlets which export the model (from either the
> request or the request's resource) as a {{String}} and then serve that
> {{String}} to the client.
> Registering these servlets is done through a new annotation named
> {{@Exporter}}
> For example, you might add this annotation to a Model class
> {{@Exporter(name = 'jackson', extension = 'json')}}
> This will register a servlet for the model's resource type with the extension
> `json` and a selector of `model` (by default, the {{@Exporter}} annotation
> can also define a different selector).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SLING-6183) Sling Models - Provide a mechanism to export model objects via servlets
[
https://issues.apache.org/jira/browse/SLING-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15615672#comment-15615672
]
dan mcweeney commented on SLING-6183:
-
Yea I guess my worry was that the "jackson" exporter in this case is too
"greedy" in that it's going to export the whole graph of objects in a way that
the objects pointed at in the graph might not conform to. But you are correct
we could add a new exporter just with a different name that has a different
behavior. Sounds like a good PR for me to submit. :-)
> Sling Models - Provide a mechanism to export model objects via servlets
> ---
>
> Key: SLING-6183
> URL: https://issues.apache.org/jira/browse/SLING-6183
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Fix For: Sling Models API 1.3.0, Sling Models Impl 1.3.0, Sling
> Models Jackson Exporter 1.0.0
>
> Attachments: SLING-6183.patch
>
>
> I would like to introduce a new feature to Sling Models named Exporters.
> Exporters allow for a model class to be exported into a specific Java object
> type in a automated fashion. The simplest example is to support String
> serialization, although different Exporters may support whatever target
> classes they see fit.
> Exporters are implemented through an SPI. This initial contribution includes
> an exporter using the Jackson library which supports both {{String}} and
> {{Map}} exports.
> Interfacing with the registered Exporters is done through three new methods
> on the {{ModelFactory}} interface:
> * {{exportMode}}
> * {{exportModelForResource}}
> * {{exportModelForRequest}}
> In addition, using these functionality, model objects can have
> automatically-registered servlets which export the model (from either the
> request or the request's resource) as a {{String}} and then serve that
> {{String}} to the client.
> Registering these servlets is done through a new annotation named
> {{@Exporter}}
> For example, you might add this annotation to a Model class
> {{@Exporter(name = 'jackson', extension = 'json')}}
> This will register a servlet for the model's resource type with the extension
> `json` and a selector of `model` (by default, the {{@Exporter}} annotation
> can also define a different selector).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
