I'm new to Enyo and am trying to implement display interface for my website within an Enyo app.
Basically all that I want to display is the app's toolbar on the top of the page, and the rest of the page would simply display the contents of my website.
Considering that my website is already optimized for responsive display, how do I implement this without encountering Cross-Origin issues?
I think you'll want to embed your site's contents within an iFrame. You haven't said whether the app buttons will need to interact with your site's contents so you may run into some issues there.
You don't quite have enough detail for a better answer. What cross-origin problems do you predict? Where will you be deploying? Will you be pulling the site live or will you have a cached copy you distribute with the Enyo app?
Related
Basically, we are using a headless CMS to edit content on Website A. We are building our own CMS UI based on the headless CMS API (call this Website CMS).
Now, we have this page in Website CMS wherein you can edit the content on the left panel and get a preview of Website A on the right panel (mobile view).
I haven’t done anything like this before and I am wondering what’s the best way to accomplish this and if there any libraries that help with this functionality.
Some ideas:
Embed Website A within Website CMS and any changes done on the left panel basically just refreshes Website A (which is just embedded into the page).
Recreate Website A as a page in Website CMS and call the same APIs so that the changes both happen on Website CMS’s Website A and the actual Website A. (Although I don’t see how this would be more beneficial and will create 2 separate codebases for the exact same page).
Others???
Main framework we are using is ReactJs for this CMS UI.
Option 2 is what I would do and wouldn’t necessarily be duplicative.
You would want users to be able to preview changes without publishing them. So porting the real website wouldn’t be compatible with that goal.
Code duplication would probably be minimal. It would share most of the same code and it would also propagate much faster.
you can establish a communication link between CMS and website A to exchange data.
Options
you can embed website A inside Website CMS using an iframe and then you can use postMessage to exchange data between CMS and Website A.
Or else you can use WebSockets where website A will listen for the changes done at the left panel of the CMS.
I want to create embedable widgets for a Rails app, that would allow users to interact with the app from external websites.
I was all set to try using iframes to achieve this. But then I found a couple of forum responses that seemed to suggested iframes are not the best way to achieve this, and instead to use JS to embed HTML elements. This surprised me - I thought iframes would be a clear winner simply because of the isolation of CSS and scripts.
So, what is the best way to embed (limited) app functionality in a third party website. This interaction will be limited to login and a single simple form. Is iframes of JS embed the best way to go? And as a side question, are there security issues to be aware of with either approach?
I think using iframes suck hard. It's just not the feeling of a whole website, it's like a website inside another, mostly the styles won't match, or you have a scrollbar or the responsive layout is not applying right. So here's a little pro/con list:
iframe PRO:
requests are not cross site origin (most likely more secure)
"sandbox" javascript (no conflicts)
iframe CON:
style guides
history not changing (e.g. if you do a submit a form with GET you cannot paste the URL and send it to a friend)
js PRO:
Full control about the navigation (you can override link clicks with $.load etc).
Ability of changing the browser history (history API, see MDN)
smooth handling of html components
style's are automatically inherited
js CON:
CORS see https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
Handle (override) events like link clicking, form submitting. (see Sending multipart/formdata with jQuery.ajax)
Sessions/cookies
I wrote a little rails plugin which allows you to embed your rails app as a js frame inside another (it's still really really beta): https://github.com/Elektron1c97/better_frame. The plugin handles most of the js problems like the link/form events and write to the browser history.
So.. If you need to run an app which should be really embed in a site like a store on another website I would use js embedding.
If you create a custom item to share like the soundcloud player you may want to use an iframe.
If you want third party sites to react to interactions with your widgets then you should absolutely use javascript. Although it is possible to pass messages between different domains through an iframe it is not the most convenient to use. See https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
As for using javascript, you can simply ask your users to embed a javascript file that will render your widget. To bypass any CORS issues, your widget should interact with an API that supports JSONP responses.
I am creating an angular app that is hosted on a webserver that doesn't allow me to edit htaccess files or webconfig. There is no server side language option available which means no middleware for creating HTML snapshots. This is a high dollar CRM with webstore and no option of switching hosts.
So I have come up with my own "solution" to the issue. Would it be considered ok to create hyperlinks that link to url's that will generate the same view that will be updated by an onClick event. This way the user will see the content loaded immediately, but bots will have to reload the page at the new url to see the page content.
Example:
View 2
I'm struggling to find a good solution to this issue, and I know others have to be in the same situation as me when it comes to development. The code above is just a visual reference to what I am referring to.
Have you looked at
grunt-html-snapshot
After implementing this and testing this, it does work well. Google sees them as new pages and the user never has to worry about loading new content.
I have a website which has two versions, an all singing all dancing javascript powered application which is served when you request the root url
/
As you navigate around the lovely website the content updates, as does the url, thanks to html5 push state or good old correctly formatted #! urls. However if you don't have javascript enabled you can still use all functionality of the site as each piece of content also exists under it's own url. This is great for 3 reasons
non javascript users can still use the site
SEO - web crawlers can index the site easily
everything is shareable on social networks
The third reason is very important to me as every piece of content must be individually shareable on the site. And because each piece of content has it's own url it is easy to deep link to that url, and each piece of content can have it's own specific open graph data.
However the issue I hit is the following. You are a normal person and have javascript enabled and you are browsing and image gallery on the site and decide to share the picture of a lovely cat you have found. Using javascript the url has been updated to
/gallery/lovely-cat
You share this url and your friend clicks on it. When they click on the link the server sends you the non javascript / web crawler version of the site, and the experience is no where near as nice as the javascript version you would have been served if you directly went to the root of the site and navigated there.
Do anyone have a nice solution / alternative setup to solve this problems? I have several hacks which work, however I am not that happy with them. They include :
javascript redirect to the root of the site on every page and store a cookie / add a #! to the url so on page render the javascript router will show the correct content. ( does google punish automatic javascript redirects? )
render the no javascript page, and add some javascript which redirects the user to the root, similar to above, whenever the user clicks on a link
I don't particularly like either of these solutions, but can't think of a better solution. Rendering the entire javascript app for each page doesn't appear to be a solution to me, as you would end up with bad looking urls such as /gallery/lovely-cat/gallery/another-lovely-cat as you start navigating through the site.
My solution must support old browsers which do not implement push state
Make the "non javascript / web crawler version of the site" the same as the JavaScript version. Just build HTML on the server instead of DOM on the client.
Rendering the entire javascript app for each page doesn't appear to be a solution to me,
That is the robust approach
as you would end up with bad looking urls such as /gallery/lovely-cat/gallery/another-lovely-cat
Only if you linked (and pushStateed) to gallery/another-lovely-cat instead of /gallery/another-lovely-cat. (Note the / at the front).
Try out this plugin it might solve your 3rd reason, along with two reasons.
http://www.asual.com/jquery/address/
I am quite new to web application development and I need to know how would I make other sites use it.
My webapp basically gets a username and returns some data from my DB. This should be visible from other websites.
My options are:
iframe. The websites owners embed an iframe and they pass the userid in the querystring. I render a webpage with the data and is shown inside the iframe.
pros: easy to do, working already.
cons: the websites wont know the data returned, and they may like to know it.
javascript & div. They paste a div and some javascript code in their websites and the div content is updated with the data retrieved by the small javascript.
pros: the webside would be able to get the data.
cons: I could mess up with their website and I don't know wow would I run the javascript code appart from being triggered by a document ready, but I wouldn't like to add jquery libraries to their sites.
There must be better ways to integrate web applications than what I'm thinking. Could someone give me some advice?
Thanks
Iframes cannot communicate with pages that are on a different domain. If you want to inject content into someone else's page and still be able to interact with that page you need to include (or append) a JavaScript tag (that points to your code) to the hosting page, then use JavaScript to write your content into the hosting page.
Context Framework contains embedded mode support, where page components can be injected to other pages via Javascript. It does depend on jQuery but it can always be used in noConflict-mode. At current release the embedded pages must be on same domain so that same-origin-policy is not violated.
In the next release, embedded mode can be extended to use JSONP which enables embedding pages everywhere.
If what you really want is to expose the data, but not the visual content, then I'd consider exposing your data via JSONP. There are caveats to this approach, but it could work for you. There was an answer here a couple of days ago about using a Web Service, but this won't work directly from the client because of the browser's Same Origin policy. It's a shame that the poster of that answer deleted it rather than leave it here as he inadvertently highlighted some of the misconceptions about how browsers access remote content.