I am developing an application in ui5. The 'Model' is a notes database. Now, I am fetching the notes document via JSON. I want to display the attachments in the upload collection in ui5. The JSON is returning attachments but I am unable to understand it. For e.g. I have attached a PDF document, but the JSON is showing as if I have attached 3 different files. Also the file is in Base64 format.
I want to be able to download and upload the attachments.
Following is the attachment field details in the JSON(There is only 1 file "Domino Access Service.pdf" in the field and nothing else):
"Attach_ProductDetails":
{
"type":"multipart",
"content": [
{
"contentType":"multipart\/mixed; Boundary=\"0__=4EBB0B01DFD9A4D28f9e8a93df938690918c4EBB0B01DFD9A4D2\""
},
{
"contentType":"multipart\/alternative; Boundary=\"1__=4EBB0B01DFD9A4D28f9e8a93df938690918c4EBB0B01DFD9A4D2\"",
"boundary":"--0__=4EBB0B01DFD9A4D28f9e8a93df938690918c4EBB0B01DFD9A4D2"
},
{
"contentType":"text\/plain; charset=US-ASCII",
"data":" (See attached file: 1. Domino Access Service.pdf)",
"boundary":"--1__=4EBB0B01DFD9A4D28f9e8a93df938690918c4EBB0B01DFD9A4D2"
},
{
"contentType":"text\/html; charset=US-ASCII",
"contentDisposition":"inline",
"data":"<html><body><i>(See attached file: 1. Domino Access Service.pdf)<\/i><\/body><\/html>\r\n",
"boundary":"--1__=4EBB0B01DFD9A4D28f9e8a93df938690918c4EBB0B01DFD9A4D2"
},
{
"contentType":"application\/pdf; name=\"1. Domino Access Service.pdf\"",
"contentID":"<1__=4EBB0B01DFD9A4D28f9e8a93df93869091#local>",
"contentDisposition":"attachment; filename=\"1. Domino Access Service.pdf\"",
"contentTransferEncoding":"base64",
"data":"<Base64 data>",
"boundary":"--0__=4EBB0B01DFD9A4D28f9e8a93df938690918c4EBB0B01DFD9A4D2"
}
]
}
It will be great help if anyone has the solution for the same.
It is not giving you three files. It is showing you two alternative renderings of the rich text field called Attach_ProductDetails which contains the icon representing the attached file - which it thinks you might want. There could also be other data in that rich text field. The API has no idea what part of it you want, so it gives you everything - and in case you're not prepared to deal with text/html it also gives you a text/plain rendering, too.
It is also giving you the file attachment data, tagged with the "application/pdf" content-type. You need to decode the base64 data and store it so you can display it (or whatever else your application wants to do with it).
Related
I have an Azure Logic App that uses a Analyze Document for Prebuilt or Custom models (v3.0 API) action. The Custom Model is good, I can hit it with Postman with no issue.
When I try to get a PDF from Sharepoint and send it to the service, I get an error saying:
{
"error": {
"code": "InvalidRequest",
"message": "Invalid request.",
"innererror": {
"code": "InvalidContent",
"message": "The file is corrupted or format is unsupported. Refer to documentation for the list of supported formats."
}
}
}
I've tried:
Passing the Get file content directly to the Document/Image File Content input
Passing body('Get_file_content)['$content']
Passing concat('data:application/pdf;base64,',body('Get_file_content')['$content']
This one converts to PDF in a Base64-to-PDF tool so I know the Base64 is good
Then I found out that the service wants binary format:
Passing base64ToBinary(body('Get_file_content')['$content'])
Still no go
Why can I not send the file to the Form Recognizer service?
EDIT:
Thank you to #vijaya. They helped me see that the Document/Image URL parameter was not necessary. Leaving that blank and using the original Get File Content worked!
Issue is with content-type. You need to pass content-type along with content for analyze document. I have reproduced issue from my side and below are steps I followed,
Initially created logic app as shown below,
Logic app failed with error,
The file is corrupted or format is unsupported. Refer to documentation for the list of supported formats.
Next modified logic app as shown below,
In Compose action setting content as
outputs('Get_blob_content_(V2)')?['body']?['$content'] and passing content-type as application/pdf as we are dealing with pdf files.
In Analyze Document for Prebuilt or Custom models (v3.0 API) action, using outputs of compose in Document/Image File Content.
Logic app ran successfully as shown below,
Output of Analyze Document is as shown below,
I am creating an upload screen which allows the user to upload images in RAW format. There are multiple RAW formats and I have a pre defined list of them.
define ('ALLOWED_FILE_TYPE', array(
"image/jpeg",
"image/jpg",
"image/tif",
"image/png",
"image/bmp",
"image/x-canon-cr2",
"image/x-canon-crw",
"image/x-kodak-dcr",
"image/x-nikon-nef",
"image/x-olympus-orf",
"image/x-sony-arw",
"image/x-adobe-dng",
"image/x-epson-erf",
"image/x-kodak-k25",
"image/x-kodak-kdc",
"image/x-minolta-mrw",
"image/x-pentax-pef",
"image/x-fuji-raf",
"image/x-panasonic-raw",
"image/x-sony-sr2",
"image/x-sony-srf",
"image/x-sigma-x3f"
));
(I found this list on stackoverflow. I have not had a chance to check it's authenticity.)
My script is a standard upload form with a call to a method to check the upload file type. Unfortunately, with RAW files, the file type that comes back is 'application/octet-stream':
array (
'name' => 'DSCF0450.RAF',
'type' => 'application/octet-stream',
'tmp_name' => '/private/var/tmp/phpVFT8BJ',
'error' => 0,
'size' => 50560000,
)
Clearly, the RAW file is not being recognised as an image.
Can anyone tell me why?
Do I have to change the upload form enctype to something other than enctype="multipart/form-data"?
Can anyone tell me how to get the raw file recognised as an image?
N.B:
Processing the image is not an issue. I am trying to validate the upload.
I have tried using finfo and finfo_file to get a file type (it also returns 'application/octet-stream').
I know I could get the file extension and check against that. I would rather not rely on something that can be easily altered, unless I absolutely have to.
Thanks in advance.
Can anyone tell me why?
The content-type of an uploaded file is provided by the client. It is being reported as application/octet-stream (i.e. some bytes of data in no recognized format) because the browser/OS doesn't that is uploading it doesn't recognize the file type.
Do I have to change the upload form enctype to something other than enctype="multipart/form-data"?
No. The content-type reported for the file is specified for the part of the upload (which consists of multiple parts of form data).
Can anyone tell me how to get the raw file recognised as an image?
Short of making changes to every browser that accesses your website (which isn't practical except under very unusual circumstances), you can't. At least not at this point.
I am trying to validate the upload.
Validating that a file is an image by trusting that the content-type header sent by the client isn't safe anyway.
I have tried using finfo and finfo_file to get a file type (it also returns 'application/octet-stream').
Likely for the same reason that the client couldn't identify it. RAW files are distinctly non-standard.
Processing the image is not an issue.
Then the tools you use to process it are likely the best way to determine if it is the type of data you want.
Whatever data I want to send whether be a text file or a PDF am able to give but how do I give my desired name to the file ?? And what about other types of files ?? What should be the request header please give an example had a look at the API documentation but not getting it ...
It seems you're using a basic upload.
You can use the suggested answer in this SO post:
Use multipart upload and specify the tile in the metadata part
{
"title": "My File"
}
Types of files are called MiME types. You can see the supported MiME types here.
Check this Multipart Upload guide for more info.
I've recently taken a dive into ExtJS by inheriting a web app written in 3.4. I've managed to create a store attached to a grid with no problem and have been able to bring up a PanelForm with data loaded from a call to a php page.
I have another json store defined which doesn't get populated when I call its load procedure and I'm wondering what I am missing.
The definition of the store is below:
var ImgStore = new Ext.data.JsonStore({
totalProperty: 'total'
,root: 'data'
,url : 'json/getProductImage/'
,fields : [{
name : 'img'
},{
name : 'extn'
}]
});
My code to load the data is:
ImgStore.load({callback: function() {}
,params: {'ProductGUID': x}
});
The code behind the URL is fine and the response in Firebug below:
{"success":true,"data":{"img":"iVBORw0KG...ggg==","extn":"png"}}
What I cannot understand is why the response comes back but the Store does not populate. I must be missing something; I just can't see what...
Does the Store have to be bound to another object? What I wanted to do was to read back the base64 encoded string and then show the image on screen (on either a panel, FormPanel or Container; not really sure of the best method really)
Any advice is greatly received.
Your store needs a model. The model needs to reflect the attributes that are then being returned in your JSON feed. Only then will the data show up in your store.
Everything looks fine, except for the url config aren't u missing the name of the file ? 'json/getProductImage/myfile.json'?
How are you validating store is not loaded by binding it to a grid? Because if so, store could be loading but not configuring grid properly might make u think store is not loaded, try console.log(store.getTotalCount())
I was reading this Questions regarding REST
What exactly is RESTful programming?
While reading i get that the client is independent of server and client don't need to construct anything.
I want to know that when we are building forms like user registration . Then what is the REST way of doing it.
I mean when i do GET for /user/new then
Does the server has to send the complete FORM in html
Only send fields in JSON and form is constructed by client itself
But then again there will be many complexities, if i just send the fields, then what things like
Hidden fields
Default value for select boxes
what about some logic like this field can'r be greater than 30 etc
REST is, as you're already aware, a way of communicating between a client and a server. However, the issue here is what is being defined as the "client". Personally, I tend to consider that the browser itself is not in itself the client: instead, the client is written in JavaScript, and the browser is merely a conduit to executing it.
Say for the sake of argument that you wish to view the details of user '1414'. The browser would be directed to the following location:
/UserDetails.html#1414
This would load the static file ViewUser.html, containing all the form fields that may be necessary, as well as (via a <script> tag) your JavaScript client. The client would load, look at the URL and make a RESTful call to:
GET /services/Users/1414
which would send back JSON data relating to that user. When the user then hits "save", the client would then make the following call:
PUT /services/Users/1414
to store the data.
In your example, you wanted to know how this would work with a new user. The URL that the browser would be directed to would be:
/UserDetails.html#0
(or #new, or just # - just something to tell the JavaScript that this is a new client. This isn't a RESTful URL so the precise details are irrelevant).
The browser would again load the static file ViewUser.html and your JavaScript client, but this time no GET would be made on the Users service - there is no user to download. In addition, when the user is saved, this time the call would be:
POST /services/Users/
with the service ideally returning a 302 to /services/Users/1541 - the location of the object created. Note that as this is handled in the client not the browser, no actual redirection occurs.
"Forms" for hypermedia APIs could be rendered in a "forms aware" media type like for instance Mason (https://github.com/JornWildt/Mason), Hydra (http://www.markus-lanthaler.com/hydra/) or Sirene (https://github.com/kevinswiber/siren). In Mason (which is my project) you could have a "create user" action like this:
{
"#actions": {
"create-user": {
"type": "json",
"href": "... URL to resource accepting the POST ...",
"method": "POST",
"title": "Create new user",
"schemaUrl": "... Optional URL to JSON schema definition for input ..."
"template": {
"Windows Domain": "acme"
}
}
}
}
The client can GET a resource that include the above action, find it be the name "create-user" and in this way be told which method to use, where to apply it, how the payload should be formated (in this case its JSON as described by an external schema definition) and some default values (the "template" object).
If you need more complex descriptions (like selection lists and validation rules as you mention) then you are on your own and will have to encoded that information in your own data - or use HTML or XForms.
There are multiple ways to do what you want.
You can use GET for /user/new along with a create-form link relation to get a single link. This can in plain HTML or HTML fragment, or a schema description, practically anything you want (the result will be less reusable than the other solutions).
You can use a standard MIME type which supports form descriptions. For example HAL with a form extension or collection+json.
You can use an RDF format, like JSON-LD with a proper vocab like Hydra.