I have been working using many of the elements provided by the Polymer team. I have seen documentation that shows using app-layout elements and others that show the same thing achieved using paper elements.
For example paper-drawer-panel is very similar to app-drawer. The paper element appears to have more configuration options and allows for multiple paper-drawer-panel elements embedded within each other as opposed to the less flexible app-drawer.
<paper-drawer-panel>
<div drawer> Drawer panel... </div>
<div main> Main panel... </div>
</paper-drawer-panel>
vs.
<main>Main panel....</main>
<app-drawer>Drawer panel... </app-drawer>
Is there a reason to prefer app-layout elements over the similar yet more flexible paper elements?
I think the <app-*> elements were developed later in response to requests for standard templates for apps. I suspect some of it is just name changing to make it easier to understand.
In particular I have been using
<app-header-layout>
<app-header
fixed
effects="waterfall">
<app-toolbar>
...
</app-toolbar>
</app-header>
... my main content
</app-header-layout>
with great effect. You can actually add several toolbars and some of the effects allow fading from one toolbar to the other as the headers scroll up (including a background image that fades away).
My <app-toolbar> contains all sorts of things including drop down menus.
I also found it easier like this to understand how to make lazy loading work. In fact my content only contains a "session manager" element and a "pages" element, the latter of which is only lazily loaded after the session manager has successfully validated a user (via cookie or login). That pages element has an embedded <iron-pages> and <app-location> and <app-route> to do all management of the application post login.
Related
I'm developing a React/MaterialUI component that will be embedded in existing websites.
In order to minimise the work needed on the existing page to embed my component, I'm bundling my component into an app.js and the only change requested to the existing page is something like:
<div id="embedded-component"></div>
<script type="text/javascript" src="https://example.com/app.js"></script>
my component finds the div by ID and then mounts on that element.
Things are mostly working but I'm having issues with CSS conflicts between the CSS files on the original page (which I can't modify) and the elements of my application.
For example the original page uses text input elements with a border/padding/color that I don't want my component to "inherit".
I want my component to display the same way regardless of which page is embedded on.
Is there any strategy/tool to use in this case, so CSS classes on existing page do not affect the elements of my embedded component?
Trying to find a solution to this I've come across the Shadow DOM (e.g. https://medium.com/rate-engineering/winning-the-war-of-css-conflicts-through-the-shadow-dom-de6c797b5cba) but I'm not sure how widely supported this is in different browsers.
Is there any solution to this, that is widely supported by all major browsers?
I cannot use iframes and have full control of my js/css files but no control over the existing page other than the "mounting" div.
Here’s a scenario:
I have a three page website implementing <iron-pages>. Nav is a toolbar with three paper tabs, no drawer. When I click on the tabs, the content of the iron-pages loads below the toolbar. All good.
Now, I have a few child pages that I want to link from the content of one of the three pages. When the page loads, I don’t want it to load below the three tabs but rather be sort of a new page with a different toolbar, with an arrow on the top left to return to the previous view, separate header title, etc.
A few questions:
Should these child pages be part of the same <iron-pages> list that the three main pages are in? If not, how do you recommend? (When I do, content loads below the toolbar, as expected.)
Should these be an entirely separate page, like a sibling to index.html or in /src, that I link to? If so, is it part of the same app then?
Sorry for the noob questions. Still trying to understand how single page apps are structured, in such scenarios. Eventually I want these pages to be <animated-pages> so that I can transition from the main page to the child pages and back. Will save those questions for another time...
Thanks!
An easy solution is to move your nav-bar component to each of your top level pages that need it. You can then move your new "sub-page" so it's a sibling of your other pages.
How users navigate to your different pages does not necessarily need to dictate how you structure the DOM.
Answers to your other questions
Should these child pages be part of the same list that
the three main pages are in? If not, how do you recommend? (When I do,
content loads below the toolbar, as expected.)
From what I can tell, no. Keeping all of your pages (even "sub-pages") as siblings will decouple the DOM from the app hierarchy (ie if the hiearchy of your views change, your markup can stay the same).
Should these be an entirely separate page, like a sibling to
index.html or in /src, that I link to? If so, is it part of the same
app then?
Polymer lets us build composable building blocks, so I'd recommend having a different custom web component for each of these pages. In my apps, I usually stick all of my web components in the same folder. A sample directory structure might look like this:
my-app/
index.html
src/
components/
nav-bar.html
my-page1.html
my-page2.html
my-page3.html
You can then make use of your custom components in index.html
PROBLEM:
I've created a custom "properties" grid system to use universally on any element. In every project thus far, I've had no problem using it...But when I try to use it in the Polymer Shop App Demo, it doesn't work. Here's my custom property system that I'm importing in: https://github.com/oneezy/steel-properties
In Chrome dev tools network tab, it says that it's loading normally, however when I inspect an element it doesn't show up in the css and has no effect! It's got me scratching my head because it works completely fine w/ Polymer Starter Kit and in other projects...
I've included a short video showing my problem:
https://www.youtube.com/watch?v=tpyYxXTMdkU
Is there something I'm missing or doing wrong???
UPDATE:
By changing shadow to shady in the shop app's index.html file, everything seems to work as expected:
Polymer = {lazyRegister: true, dom: 'shadow'};
becomes...
Polymer = {lazyRegister: true, dom: 'shady'};
But what are the ramifications of this?
Steel-Properties is meant to be used as a "universal" way for initial layout so you can quickly use it on any element. When I include steel-properties into a file, it goes in and calls other files that have specific style properties written out, and you then can write these properties directly into your markup.
EXAMPLE:
HTML Markup:
<body mobile-bg="blue" tablet-bg="green" desktop-bg="yellow"></body>
Output:
The Code:
As you can see, steel-properties is not your typical <custom-element>. It's really just importing in style sheets with [attribute="property"]'s.
So my questions now are:
Should I be doing it this way or am I going about it wrong?
What would be the proper way to write my "steel-properties" so that it can work with both shadow and shady DOM universally?
What are the ramifications of switching shadow to shady DOM in the shop app?
What is the main reason for using shadow DOM instead of shady DOM in the shop app but not the Polymer Starter Kit? (performance?)
I was wondering if anyone could show me an example for using html framesets with google appengine for python 2.7. What i want to do is have two frames, one static frame containing a sidebar with buttons and then another frame to the right of it that shows different pages depending on which button is selected.
As others have commented, this is something that can be solved client-side and you shouldn't be using frames.
Zurb foundation offers navigation similar to what you are requesting.
http://foundation.zurb.com/docs/navigation.php
Similarly, Twitter bootstrap also offers navigation that would enable you to build the functionality you are requesting.
http://twitter.github.com/bootstrap/components.html#navbar
A plugin that will help you keep a sticky side menu can be found here: http://mojotech.github.com/stickymojo/
In response to your comment:
To dynamically load content into the 'frame' alongside the menu bar, you can use jQuery load function.
http://api.jquery.com/load/
It allows you to fetch a page from the server and replace an elements content with the fetched content.
I'm interested in the way lala.com works. They have a header that remains fixed at the top of the browser and they have a flash music player in it.
You can click on other links in the site and they are displayed below the header but the header is not disrupted and can continue playing music.
If the target is a modern browser say IE8 & FF 3.6, what's the best way to achieve this?
Thanks for any help.
Frames / Iframes
One way to achieve this is to create a frameset or use iframes to show the sub pages. The top (or bottom) frame would be a very tiny one, and containing your music player. The big frame would contain the page that is being browsed. This technique is used e.g. by Google when clicking on an image search result.
This method has its downsides: The user will see your URL in the address bar and not the one of the page being browsed. If the user enters something in the address bar, they will leave your frameset. It is not possible e.g. to write down the URL of the current page.
Ajax
The second, better way is to build a navigation that loads the other pages into the current page through AJAX. See an example implementation here.
This will provide for smooth loading, music will continue to play. If done right, it is even possible to retain a healthy link structure that won't break external references, and have the "back" button work. The tutorial I link to covers both aspects. Just be careful, it's a 3-part tutorial.
It works with JavaScript enabled only, though, but there are solutions that downgrade gracefully (falling back to the "normal" behaviour of switching pages when JavaScript is turned off).
Besides frames, you can do partial page refreshes with ajax. Instead of fully loading a new page on each action, you would do partial page refreshes. You can keep bookmarking and the back button functionality through careful coding. Libraries such as jQuery (and lots of others) make using ajax across different browsers signficantly simpler. EDIT A quick search revealed a Stack Overflow question on back button plugins for jQuery. So, if you use jQuery you can make this approach even easier.
Here's some stub code:
HTML
<html>
<head>
<!-- ... -->
</head>
<body>
<div id="music-header">
<!-- ...Music header content goes here -->
</div>
<div id="content">
<!-- ...Body of different pages goes here -->
</div>
</body>
</html>
Javascript is provided in the link I provided on how to handle bookmarking and the back button.
This specific example lala.com is done using iframes.