in an article where Sencha disputes facebooks claim that html5 is slow,they suggest that there's a way to create a framework that would allow for seamless communication between an iframe and the parent window. How would this be achieved? not looking for code examples, just ideas. thanks
So the Fastbook app is the first to make use of a brand new “Sandbox
Container” which programmatically detaches complex views and renders
them into their own iframes, and thus partitioning the DOM tree. This
special container doesn't need any extra handling at the application
level, so it's seamless to developers (i.e., any component added to
this container will be sandboxed automatically). But it does come at
a cost: events, positioning, styling, and JavaScript code have to be
proxied between the parent window and the child sandboxes. This is
complicated, so without a robust and properly architected framework,
it is very difficult to implement. Sandboxing allows layouts to be
isolated, and therefore keeps the primary DOM tree as light as
possible. To bring balance to the Force, Sandbox Containers must be
used wisely
.
something like http://easyxdm.net/wp/ takes care of it by using PostMessageTransport
Related
I am new to React but have not found a suitable solution to my first problem on the job.
The specific context is of a navigation component that composes several other components and together they are a redistributable unit, independently testable as a whole module.
The use case of the component is to sometimes render it in desktop mode using React media queries, and other times in mobile - in which case it needs decorated with flyout behaviour.
So I want to decouple the navigation component from having to know about flyout. In respect of the 'tell don't ask' principle or event driven I want to be able to notify a parent that navigation has changed and depending on how this component is implemented respond accordingly (in mobile, the flyout needs to get hidden, in desktop there is no flyout decorator).
I looked at redux-ui which is a nice syntactic sugar using annotations but falls down when a property it is trying to set in the state hierarchy doesn't exist. And besides, this breaks the decoupling model.
I am a little abstract here I realise but does anyone have a recommendation on how I might approach this? I suspect that a possible solution might involve not having a hierarchy (is-a) imposed by the decorating wrapper and rather has-a flyout capability but would welcome industry experience on this.
Thanks
There are a few ways to handle this. The simplest would be to do it purely in CSS. Have all the HTML for the component always in the component and only the CSS would know about mobile or not.
Alternatively, you could have a piece of global state that gets set when the app loads and tells the app whether it's on mobile or desktop, and then pass that down to any relevant components. This method would be a bit of a pain because 'mobile' and 'desktop' are really just 'small screen' and 'larger screen' and as a result, this may change while the user is in the middle of using the app (like changing screen size, for example). So you'd have to keep track of all that with a bunch of listeners that are constantly listening for window resize events.
The simplest solution does seem to be pure CSS here.
I am implementing an AngularJS application that has a three-panel main view. The layout is a bit like a mail system, with a navigation bar on the left. The right pane is split in two; when you select something from the navigation bar, it populates the top-right pane, and when you select something there, it populates the bottom-right pane. The panes need to be resizeable and scrollable.
I can see three basic ways to implement this:
Use frames for panes
Use div elements for panes, with JavaScript controls for resizing and scrolling
A hybrid (perhaps divs with JavaScript resizing, but containing iframes with native scrolling)
There is very little info online on using AngularJS with frames, which leads me to think that (1) is not recommended. I'm just a bit worried with (2) that JavaScript resizing and scrolling will be inferior to native controls. In some cases the content may be large. And (3) seems to combine the worst of each approach.
So I'm looking for advice on which approach is likely to work best.
angular ui-router is good option for solving posted issue.
https://github.com/angular-ui/ui-router
for css - there are a lot of different framework, most famous is bootstrap.
or you can craft css by your own hands.
http://getbootstrap.com/
In my opinion its not recommended using frames because breaks generic functions of the browser like sharing urls, navigation between frames, default frameset, etc.
The best solution is using ui router plugin https://github.com/angular-ui/ui-router with nested views https://github.com/angular-ui/ui-router/wiki/Multiple-Named-Views. You should check the example at documentation
For Scrollable div you should use css property and for resize it probably would be nice to define a directive
I hope it helps
We have a js/html/css widget that we use on our client's web sites and have noticed on some sites, it does not display well due to the css from the page cascading through and messing with the layout, like if the designer of the web site has a bunch of css applied to ALL divs on the page, etc..
Is there an easy way to apply styles to the container of my widget so that the invasive css won't disrupt the layouts?
How do you guys handle this scenario?
Thanks,
This is a common problem. What I use is this: https://github.com/premasagar/cleanslate
A common css reset stylesheet doesn't suffice. Those reset/normalize the browsers default styles. They don't clear those created by the author.
Also, by the same author https://github.com/premasagar/sqwidget - it handles the css resetting plus a few more important things.
While I'm at it, here's another one from the team at Olark: https://github.com/olark/lightningjs It's similar to the last one, but with a few more features, and, therefore, more complex. I haven't used this one.
You could take a look at Shadow DOM. That is perfect for widgets like yours. Shadow DOMs don't allow the parent webpage to access the DOM of your widgets and CSS rules cannot reach your widgets.
I would put the widget in an Iframe that you host yourself. This solves the issue. You can give your clients the code for the embeddable iframe.
This is one of the reasons the big sites, twitter, facebook use iframes for their widgets.
I have a question about div caching in ember js for views.
I am rendering a really heavy flash application as a part of a view and i want to switch between views but not necessarily have to reload the flash app from scratch. I would preferably want it to be "hidden".
Is there a way of doing this in ember
Currently i am implementing this using https://github.com/ghempton/ember-routemanager and one of the flash apps stay on /#media and the other on /#publishing
So when user goes to /#media the media.swf gets loaded and /#publishing the publishing.swf gets loaded into the container div. Each of these routes have a corresponding view class associated to them that renders the flash object tag to be rendered.
In the past, I have used jquery to hide the container div but i am searching for a cleaner solution.
It sounds like the feature you'd like is to be able to reuse a view instance and it's DOM across states. I have some ideas for how that could be done, unfortunately it's not possible right now without some nasty hacks.
Also, unfortunately with flash objects, they seem to get rerendered if you move them in the DOM or if you change their visibility. From what I can tell, to "hide" a flash object without causing a rerender, you can only move it off screen using CSS.
Update:
Here's a working jsFiddle example: http://jsfiddle.net/EE3B8/1
Unfortunately, that technique won't work for Flash objects, since moving them in the DOM will cause them to be reloaded. This would be a good way of eliminating expensive DOM creation/view instantiation.
I am impressed by ExtJS Samples/Demos especially the Border Layout examples. Is it feasible using ExtJS or other frameworks/libraries to build a viable web app that dynamically creates (say 10) new panels; something like how Eclipse builds and docks new split panels?.
These container panels would contain tabbed widgets and the panels would need to be maximizable/minimizable and closed completely if the last tab member is closed.
(again like how Eclipse closes it’s non-editor views).
I assume that CSS styles would have to be programatically added to the DOM elements that make up the container panels but think that you could use style sheets for member layout(members could be document content or have their own widgets);
I suspect that performance would be poor and that there would be many problems in faithfully rendering the members style sheets.
I have no interest in writing an IDE in js but I am interested in knowing the limits of this approach for creating a ‘reasonably’ extensible app.
I want to provide additional context to my question.
Currently we have a desktop app in Java Swing which allows us create panels dynamically and has the features I outlined and works as follows.
Consider a simple Explorer panel on the left and an Editor panel on the right.
Editing work can be for 4 different regions and all the work for a single region is grouped in tabs in the one panel. When the user is working on a region then other region editor panels are typically minimized; visually apparent as icons on a docking panel to the right of the Editor panel.
There is total flexibility in letting the user switch working to a different region and in some cases even having 2 Editor panels open so that he/she can compare (and even do limited drag&drop from) work in one region to another. When 2 (or more) Editor panels are open they stack vertically under one another. There is no real need to have more than 2 editors open but it is allowed. We have logic that prevents mixing region views in the same editing container.
The current app performs well, allows multiple tabbed views and permits users to segregate their work. More importantly it has allowed us to introduce and use different view ‘types’ providing the extensibilty I mentioned.
Before I get any responses saying that the design is wrong and that I should consider different layouts (Accordion type panels on the left come to mind) let me reiterate that I am interested in knowing the viability of this approach for a web app. whether or not we pursue this approach.
Trigger-happy dismissals of ‘subjective’ content are something I am willing to absorb.
That's an immensely broad question. Technically, I would say that the answer is yes, but your question suggests that you come from a world where the overwhelming paradigm is desktop applications. Trying to impose that dogma on a web context is possible, but suboptimal. You could probably do much better by embracing this media, which is radically different from the one you are familiar with. That is a tall order though.
Somewhere halfway in between, there are some gui toolkits that will allow you to build applications in a browser context, that in many respects act like traditional desktop applications. Google Web Toolkit might be of interest to you, since you use Java. Or, as you have found out your self, ExtJS also belongs in this end of the spectrum. You will have to learn a bit of Javascript, but the programming model is close to what you know from Swing.