Create normal nodes with sling content import feature

[bpauli]

In some situations you have only one json file that represent nested node type definitions. For instance when you define an edit config in CQ

{
  "sling:resourceSuperType": "/apps/bpauli/components/global/parbase",
  "jcr:primaryType": "cq:Component",
  "jcr:title": "Text with Image",
  "componentGroup": "Text",

  "cq:editConfig": {
    "jcr:primaryType": "cq:EditConfig",
    "cq:layout": "editbar",
    "cq:actions": [
       "text:m129_pagebreak",
       "-",
       "edit","-","copymove","delete","-","insert"
    ],
    "cq:listeners": {
      "afterinsert": "bpauli.base.Util.refreshAjaxContentAfterInsert",
      "afteredit": "bpauli.base.Util.refreshAjaxContentAfterEdit"
    }
  },

  "dialog": {
    "jcr:primaryType": "cq:Dialog",
    "xtype": "dialog",
    "helpButton": {"xtype": "bpauli.base.dialog.helpbutton"},

    "items": {
      "jcr:primaryType": "cq:Widget",
      "xtype": "panel",

      "items": {
        "jcr:primaryType": "cq:WidgetCollection",

        "include": {
          "jcr:primaryType": "cq:Widget",
          "xtype": "cqinclude",
          "path": "/apps/bpauli/components/global/include/noprops.infinity.json"
        }

      }

    }
  }
}

To create nested nodes with one json file the content import feature of sling can be used.

Sling-Doc: http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#importing-content-structures

[francescomari]

The idea looks interesting. I would like to automatically merge this, can you pull the latest changes from the current master? I guess something is changed in the meantime because of #8 .

[bpauli]

puh, that was a hard one for a git newbie ;-). But now it looks good. Sorry

[honstar]

One question though: according to the changes required to make the Sling content import work, does this mean that an import operation is always sent to the Sling Post Servlet? Is this compatible with the initial functionality where the JSON data merely represents key/value pairs of request parameters to be posted to Sling. Things like @ suffixes (e.g. xyz@TypeHint) would then be a problem for the regular Sling JSON content import, wouldn't it?

[francescomari]

I don't know by heart how Sling import works if you put @TypeHint annotations in the JSON file. Maybe it would make more sense to keep the default behavior for the sling-content task and to create a new task (e.g. sling-import) to invoke the Sling import operation.

This way we could implement a richer behaviour, like supporting all the different file formats that the import operation understands (zip, xml, etc.).

What do you think?

[bpauli]

I took a look to the JsonReader class in Sling https://github.com/apache/sling/blob/trunk/bundles/jcr/contentloader/src/main/java/org/apache/sling/jcr/contentloader/internal/readers/JsonReader.java

There is a method createProperty and getType which is reponsible to setting the type during the import. First createProperty checks for multi-value automatically and the getType checks for a name prefix so

{
  "string": "hello",
  "stringArray": ["hello"],
  "boolean": true,
  "booleanArray": [true, false],
  "jcr:uri:github": "http://www.github.com",
  "jcr:name:me": "Burkhard Pauli",
  "jcr:path:pathType": "/content"
}

will import for example a property github with the value http://gihub.com and the type URI. It is just another notation to force a type.

[francescomari]

I guess that it could be a good thing to rely on Sling to convert properties with complex types. On the other hand, this can be confusing.

For files and directories, the JSON file allows the user to add form fields to the request to the servlet. For standalone JSON file representing nodes, the task would switch to a JSON file with different semantics.

I think that leveraging the import operation of the Sling POST servlet is a good thing, but I think it should be done by a different task.

[honstar]

I second Francesco's idea of splitting the Sling import functionality into a separate task.

One thing worth mentioning here is that by using the Sling import feature, you cannot do in-place modifications of existing nodes having a subtree. I really like the fact that I can modify a single node in a hierarchy without touching its subtree.

[bpauli]

You are right! The different semantic will be confusing. I agree with you that an extra sling-import task would be the best approach.

For this task it should not be necessary to walk recursive throw the tree because sling will automatically create the non existing folder nodes regarding to the post target. This would be useful if you want to combine this task with the grunt-contrib-watch task.

[francescomari]

The new task would be easier to implement. It will only work on files as input. It can detect, from the extension of the file, which kind of import should be performed and set the :contentType request parameter accordingly. It could also accept options mapping the same request parameters that the import operation accepts (:checkin, :replace, :replaceProperties, etc.).

[bpauli]

@francescomari do you already work on the new Task? Otherwise I can make a pull request this evening.

[francescomari]

I'm not working on this issue at the moment, feel free to go on with a pull request.

[francescomari]

Closing this issue, working on the new task.