You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sling.apache.org by bd...@apache.org on 2020/04/15 13:07:01 UTC

[sling-whiteboard] branch master updated: typo

This is an automated email from the ASF dual-hosted git repository.

bdelacretaz pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/sling-whiteboard.git


The following commit(s) were added to refs/heads/master by this push:
     new 6f5e923  typo
6f5e923 is described below

commit 6f5e92321d308181db1b12866cacd83c174f6d76
Author: Bertrand Delacretaz <bd...@apache.org>
AuthorDate: Wed Apr 15 15:06:52 2020 +0200

    typo
---
 graphql-scripting/README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/graphql-scripting/README.md b/graphql-scripting/README.md
index 35c534c..92d2d8d 100644
--- a/graphql-scripting/README.md
+++ b/graphql-scripting/README.md
@@ -20,7 +20,7 @@ or turning any Sling Resource into a GraphQL endpoint. See the comments in that
 Here are my initial rough ideas for evolving this into a useful GraphQL core for Sling:
 
   * Use the Sling resolution mechanism to acquire the GraphQL Schemas, using maybe a `.gqlschema` request extension to get them. This provides full flexiblity to generate schemas from scripts, servlets, Sling Models or whatever's needed. We'll probably need to invent a way to specify which `DataFetchers` to use in the schemas.
-  * (Implemmented in a minimal way - `GraphQLServlet`) Demonstrate how to create a "traditional" GraphQL endpoint by setting up a Sling Resource to define it, which might need a proxy servlet for ease of use. As those endpoints use the Sling script resolution mechanism under the hood, it's possible to define several such endpoints with specific characteristics, schemas etc. if needed. Also, backing those endpoints with Sling Resources allows for setting up access control of them, which w [...]
+  * (Implemented in a minimal way - `GraphQLServlet`) Demonstrate how to create a "traditional" GraphQL endpoint by setting up a Sling Resource to define it, which might need a proxy servlet for ease of use. As those endpoints use the Sling script resolution mechanism under the hood, it's possible to define several such endpoints with specific characteristics, schemas etc. if needed. Also, backing those endpoints with Sling Resources allows for setting up access control of them, which we [...]
   
 This (along with a few "details") would allow for this GraphQL core to be used in various modes: