Home → Web Services →

Web Services Fail to Conform: type issue

• Edit

christianco

Jan 28, 2013 @ 10:46 PM

Hi,
My PHP Web Services script, based in part on you examples, is throwing me an error on an edit operation on an xhtmlDataDefinitionBlock type asset.

The edit operation works just fine when I'm editing a page type asset, and I've used the same script and pattern for editing the xhtmlDataDefinitionBlock, but it won't work for that.

I know there is an issue with types not matching, ie xhtmlDataDefinitionBlock -> block_XHTML_DATADEFINITION, and etc. I ran into this issue already.

I believe that my asset should edit successfully if I have it set up so the "asset" looks like this:

array(
    "authentication"=>(the authentication array)
    "asset"=>array(
        "xhtmlDataDefinitionBlock"=> (the asset object from a read operation)
    )
)

And indeed this works if I am saving a "page" asset. But it does not work for this "xhtmlDataDefinitionBlock"... why should this be?

I can confirm that permissions are not an issue.

Once again, the issue is with my parameters -- the operation doesn't return a true, but the script fails at the "try/catch", indicating that the parameters were wrong. Well, I've tried every configuration of parameters, but the fact remains: a page will save like this, but a xhtmlDataDefinitionBlock will not... unless I'm missing something...

thanks.

1. 1 Posted by christianco on Jan 29, 2013 @ 01:13 AM

   

   after further testing:

   the authentication/asset structure is correct - I can save an xhtmlDataDefinitionBlock with an edit request with a change to the name or etc...

   the issue appears to be with changes to data definition values in the block... specifically adding or altering a repeating block or file chooser.

   when changing a repeating file chooser via WS Object (PHP), WS does not allow additional repeating file choosers to be added, or for existing repeating file choosers to be edited. After editing an existing asset, that same asset fails to save via WS.

   I can confirm that the file chooser can be repeated and saved within Cascade, with the same values I am attempting to save via WS, and it save fine.

   I can also confirm that the only part of the WS object that is being edited is the repeating file chooser, and that the data being saved there is in no way causing Cascade WS to choke.

   Let me also add that WS does seem to be able to remove repeating file chooser content, however, these changes don't show up in Cascade's editing feature, which still reflects the old attachment. Instead, they can be seen in WS, and in the "view" mode of Cascade for the block.

   Whatever is going on with this is causing me a headache and interrupting my ability to get anything done via WS.

   Cascade 7.0.5

   • Edit

2. 2 Posted by Ryan Griffith on Jan 30, 2013 @ 02:11 PM

   

   Hi Christian,

   I wanted to follow up to see if you had a chance to read my recent comment on your Support Request discussion.

   To avoid confusion, I am going to go ahead and close this discussion.

   • Edit

3. Ryan Griffith closed this discussion on Jan 30, 2013 @ 02:11 PM.