| BrowserField - Parse HTML after post [message #1827237] |
Mon, 11 May 2020 04:53  |
Eclipse User |
|
|
|
Hello,
we need an option.
User click on button, and browserField opens with some website.
User has to enter some identity number, click on Google reCaptcha and submit form.
After form is submitted, website shows informations that we need.
We would like to parse html content and fetch input field values of some fields to Scout.
We tried, using browserField, set it location, and use HTMLField to get HTML code using getHTMLField().getValueFromURL(getBrowserFIeld().getValue())....
But, value we get from HTML field is first page of website, before post, we would like to get content after POST.
So is there an option to have a listener when browserField changes content? Or something else?
Thanks
|
|
|
| Re: BrowserField - Parse HTML after post [message #1827251 is a reply to message #1827237] |
Mon, 11 May 2020 09:28  |
| Eclipse User |
|
|
|
Luka,
Browser fields in Scout are implemented using HTML <iframe> elements. Their functionality is therefore defined by the limitations set by the browers. One such limitation is that the value of the "src"-Attribute is always the same, even when some navigation happens in the embedded page. Also, for security reasons browsers don't allow two arbitrary websites to access each other's content. There are a few exceptions, e.g. when both pages are served from the same origin. You can also use the "sandbox" property to allow certain operations (see org.eclipse.scout.rt.client.ui.form.fields.browserfield.AbstractBrowserField#getConfiguredSandboxPermissions).
From my experience, communicating through iframes is hard and should best be avoided. If you can control the website to be embedded, you might be able to establish a communication channel (but expect much trial-and-error until it works on all browsers and you get all flags right). Otherwise, either use a manual "interface" (i.e. instruct the user to copy the information manually and paste it in one of your fields) or obtain the information from a well-defined services interfaces (e.g. REST). The later are to be preferred since they are more secure and reliable and less of a hassle to implement. Naturally, the 3rd party service must provide such an interface officially for this to work.
Regards,
Beat
|
|
|
Powered by
FUDForum. Page generated in 0.03661 seconds
Home