I'm going to chime in and say that I don't think you need to change your process.
You mentioned defining the :operation="import" which really threw me off since I associate that with a form posting and you mentioned JSON. I took a second look at the links that Julian sent out and there's a section which specifies updating a node via a post with JSON as the content format. this is the specific section. https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#content-creation-or-modification There's some additional parameters there for modifying/replacing nodes :replace and :replaceProperties to be specific. This just might be an issue of adding one of these to the submission that's occurring. -Jason -----Original Message----- From: Henry Saginor [mailto:hsaginor.apa...@gmail.com] Sent: Monday, July 27, 2015 2:13 PM To: users@sling.apache.org Subject: Re: Best practices for java DTOs to/from Sling Are you using just Sling itself or a Sling based product like Adobe CQ/AEM? Which Sling UI are you referring to? Also how is you application deployed with Sling? Sling models, I think, is tightly coupled with Sling itself and has a dependency on OSGi container. JCR API supports remote access. Different protocols are supported - RMI or WebDav for example. At least Jackrabbit supports both. But I have not kept up with remoting support in OAK. And since Sling can be backed either by Jackrabbit or OAK you can do this with Sling (Sling Eclipse Tooling connects to the repository this way I believe). Also, considering what Jason mentioned regarding added support for content modification you might want to check what version of Sling Post servlet you are using. Check the version of the OSGi bundles in Felix Console and make sure they match versions mentioned in https://issues.apache.org/jira/browse/SLING-1172 <https://issues.apache.org/jira/browse/SLING-1172>. I do like what Sarwar suggested bellow to extend Sling yourself with custom post servlet(s). Don’t know why I did not think of responding with that myself. I would probably do that in actually. But as you can see you have several options. It really depends on your use case and preference. > On Jul 27, 2015, at 10:37 AM, Sarwar Bhuiyan <sarwar.bhui...@gmail.com> wrote: > > If you are willing to deploy some code to sling (OSGi), you may be > able to write sling servlets which do take a JSON payload and do > whatever operations are necessary. That way, you can sort out any > issues between the client (your spring code) and the server (sling/JCR). > > I brought up Sling Models only as a suggestion to be able to use the > POJOs but it may not even be necessary. I find in the Sling world, > using the maps works out best when it's flexibility of the data model > you want since you can write some generic code for the servlets even > if your data model changes slightly. > > I hope this helps a little. > > Sarwar > > On Mon, Jul 27, 2015 at 12:55 PM, Haefele, Michael < > michael-haef...@idexx.com> wrote: > >> Sarwar and Henry, >> >> Thank you for your help. >> >> I'm not entirely sure why we went with Sling as opposed to using JCR >> directly. >> I think the Sling GUI made a very good impression in the initial demo >> (which was before my time). >> We are primarily using it as an alternative database (with the hopes >> that using JCR will make it very easy to eventually mirror some/all >> of the data in the cloud). >> >> Is a hybrid system where we utilize JCR directly in some cases, but >> Sling in others possible/desirable? >> >> I'll also take a look at Sling Models. That sounds promising. >> >> -----Original Message----- >> From: Sarwar Bhuiyan [mailto:sarwar.bhui...@gmail.com] >> Sent: Thursday, July 23, 2015 1:03 AM >> To: users@sling.apache.org >> Subject: Re: Best practices for java DTOs to/from Sling >> >> Have a look at Sling Models. >> >> On Thu, Jul 23, 2015 at 12:32 AM, Henry Saginor >> <hsaginor.apa...@gmail.com >>> >> wrote: >> >>> Hi Michael, >>> >>> Since Sling itself is a framework for building web applications with >>> it’s own persistence and services layer it’s a bit unusual to get >>> questions on integration with Spring here (I think). But I don’t >>> know enough about your application and its use cases to question why >>> you are doing this. ButI think you you can use JCR API to persist >>> your DTOs. Look up JCR API and Apache Jackrabbit and OAK projects. >>> >>> Technically you could do away with Sling entirelly and use Apache >>> Jackrabbit or OAK directly if all you are using Sling for is as >>> document/content store. >>> But again don’t know enough about your application. And I don’t >>> really want to discourage you from using Sling since I am a big fan. >>> :) >>> >>> Henry >>> >>>> On Jul 22, 2015, at 1:36 PM, Haefele, Michael >>>> <michael-haef...@idexx.com> >>> wrote: >>>> >>>> We have a Sling application that we're using basically as a >>> database/file manager for portions of a java Spring application. >>>> >>>> In java we have a bunch of DTOs that we import by converting to >>>> json >>> using Jackson and persisting to Sling using the import option on the >>> Sling post servlet. >>>> We then read them using .tidy.infinity.json and convert back to >>>> DTOs >>> using Jackson again. >>>> This is working really well. >>>> >>>> But we've reached point where we need to modify some of the data in >>> Sling and it seems like I've hit a bit of a conceptual wall. >>>> I was thinking we'd keep the DTO pattern going. >>>> Load the DTO, modify some value, push the updated DTO back to Sling. >>>> >>>> But it seems the POST servlet doesn't support json when doing a >>>> modify >>> operation. >>>> I basically took that as a hint that I might be barking up the >>>> wrong >>> tree here. >>>> >>>> We could also do the updates by posting specific properties, but it >>> seems like that's opening the door to writing a lot of custom update >> code. >>>> >>>> >>>> Does anyone have any suggestions for best practices for this sort >>>> of >>> thing? >>>> Am I trying too hard to apply RDBMS/hibernate style patterns? >>>> >>>> >>>> Thanks for taking to the time to read a somewhat open ended question. >>> >>> >>
