Need way around modifying web server to support ItemFileWriteStore

[guest]

Downloaded most recent 0.9 distribution. Wanted to use ItemFileWriteStore? to read (AND MODIFY) a data set. Found that the save operation doesn't do anything. Looking at the code revealed that I apparently have to write my own callback to do the work. (I would have thought that there would be a default that overwrote the original file.) After researching support and Google, I didn't find anything to the contrary.

So, I did. I used the rawXhrPut function to PUT a new file:

function saveAll(saveCompleteCallback, saveFailedCallback, newFileContentString) {

var saveArgs = {

url: "datadir/data.json", method: "PUT", contentType: "text/json", handleAs: "json"

}; var saveHandler; saveArgs.putData = newFileContentString; saveHandler = dojo.rawXhrPut(saveArgs); saveHandler.addCallback(saveCompleteCallback); saveHandler.addErrback(saveFailedCallback);

}

where this function is assigned to the _saveEverything method of the ItemFileWriteStore? object.

Was getting error 403 on Apache 5.5.17 bundled in Netbeans 5.5.1. Checking the apache documentation, I found that there is an init param ("readonly") for the servlet that needs to be set to "false", after which my save started working.

This means, of course, that it will now be necessary to instruct my users to modify their web.xml for Apache to allow this, unless there is something about the code above that I could have done to avoid the problem.

I see two defects here: 1) there should be a default implementation for the ItemFileWriteStore? save operation, and 2) a way should be found to avoid the need to avoid reconfiguring Apache for what is supposed to be a "standard" part of dojo.

Contact info: Gene Mutschler, Unisys Corp. (gene.mutschler@…)

[jaredj]

There is a default implementation for save(). Local in-memory save, assuming no backend service. So, this defect is invalid from my perspective. You have to provide it your backend service to write it however you choose to do it. The end-point doesn't have to be a file. It could be a URL that is actually a service that returns a blob of JSON formatted data. And with such a service, how you post back could be anything (A post body parsing URL, for example, and not just placing a file on a filesystem.) Something that parses the data and stores it into a DB, is another.

[jaredj]

Note: In-Memory save just means saving the changes internally in the browser and removing any reversion information.

Marking this as invalid for now. Your choice of just having it do a file postback and using Apache to write a json file on disk file will require modifying Apache (given their default configuration). Alternative approaches would be to write a servlet (or PHP script), or whatnot, and would not require modifying Apache and use them to update the target URL. IE, GET to the URL fetches the ItemFile? structure, POST/PUt to it saves the new structure.