We have developed our web app using polymer 0.5. We haven't upgraded it yet, there is a request for a new page creation. Question is, can we have that page alone created using polymer 2, whereas the rest of the app still runs in 0.5.
Also request to provide some pointers on login page custom element. It will be a simple user/password field.
Thanks,
Use information in this post https://jcrowther.io/2015/06/01/upgrading-from-polymer-v0-5-v1-0/ to migrate to 1.0 and then make minor changes to run on 1.9 and finaly you can use Polymer linter avaiable in https://github.com/Polymer/polymer-linter with --fix option in polymer-2-hybrid mode.
There is no way that 0.5 version elements will be complatible with 2.0. There have been few changes.
Upgrading to version 1.9.1 should be ok. Without any hard problems. So you should first try this and repair some errors that might occur. Then read documentation about upgrading to Polymer 2.0. You will be using hybrid elements. This is important, because in Polymer 2.0 there are 2 choices of how to define elements.
If you don't have that much time playing with upgrading, or is your app simply large, then upgrading to 1.9.1 should be the best option.
Related
We have a lot of components that are written in 1.6.x and we plan to upgrade them all the way to Polymer 3. I have read the upgrades guides from Polymer, but I can only see guides for 1.x to 2 and 2.x to 3, but not from 1.x to 3.
https://www.polymer-project.org/2.0/docs/upgrade
https://www.polymer-project.org/3.0/docs/upgrade
What is the best strategy to upgrade Polymer 1.6.x components to version 3?
So far from reading in each guide, I should either upgrade the components to 2.x legacy or 2.x class based components. Not hybrid, since I'm not planning to support 1.x anymore. What are the advantages and disadvantages of each type? I'm looking for the quickest way to update the components since we have a limited team and timeframe. Does Polymer 3 support each type, assuming after we run the components through the Polymer modulizer tool? Thanks in advance!
So I've just got started with polymer and got this message:
[Deprecation] Styling master document from stylesheets defined in HTML Imports
is deprecated, and is planned to be removed in M65, around March 2018. Please
refer to ....... for possible migration paths.
After doing some reading it seems to be that
<link rel="import" href="/SOR/bower_components/paper-input/paper-input.html">
Was causing the issue and rel=import for html was being deprecated. Is this right? If so what is the fix, how should I be doing this?
Cheers
So, according to the new version of chrome (61.xx.x). Google has made a decision that Styling master document from stylesheets defined in HTML Imports
is not a good approach and so it will be unable to do in future chrome versions.
Because of this, we have to upgrade to version 2.x
Well, nothing much interesting except that Google has made a decision that HTML imports will be removed in future. This is much more frustrating. Everyone who is using Polymer 1.x or 2.x will have to update their projects to newer version of polymer (at least 3.x). Unfortunately version 3.x has no support in all major browsers (except Chrome, but not fully). So we can only hope that the remove of HTML imports will not be soon.
For me this is really piece of s**t. I have many projects written in Polymer and I am not able to upgrade them. (there is no time for this) even i had time, I don't have trust in Google Polymer... Their support is 0. They don't even answer to bugs. Old versions are already stopped from updating. No long-term support versions.
official discussion: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/VZraFwqnp9Y/discussion
The issue has actually been solved by the polymer team, as described on their blog
So versions 1.10.1 or newer for 1.x and 2.1.1 or newer for 2.x are ok, however the warning doesn't go away (see blog entry for more details).
I also tested a polymer 2.6 app on Chromium 65 and on chrome 67 beta and it works fine everywhere :)
If you are using Google Polymer it's worth remembering that webcomponents.js is actually a polyfill. We currently run Polymer version 0.5 and this can actually be tested by starting your current Chrome with those features disabled. On Mac you can do this quitting Chrome and then run from command line:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-blink-features=ShadowDOMV0,CustomElementsV0,HTMLImports
Polymer 0.5 applies the Polyfill when these features are disabled.
Here is the documentation on running Chrome in debug mode Chromium debug flags
I have been building a web application with Dart and AngularDart upon Google Maps. I noticed a problem since the begin of the process even though I tested the development Dart sdk, and today the latest dart sdk (version 1.0.0.10_R30798) and still face the problem.
Firstly the packages I am using are shadow_dom, google_maps and AngularDart.
When I build my application WITH --no-minify option it works great, even in all the browsers after fiddling around with shadow_dom for a week (I should add the shadow_dom script BEFORE everything else to work properly).
The problem is that when I build normally (minify) or even directly using Dart2JS compiler with the --minify option the application does not run and I get an exception.
Above you can see the two cases, where in the first the application loads the google maps correctly and in the second picture the google maps are not loaded and I get that exception.
More importantly is that if I use a 3rd party minifier to minify the original main.dart.js file (the unminified) it works perfectly fine.
Thank you
The 2.x version of google_maps package has removed the dependency on dart:mirrors and is only based on dart:js. So the minification problem should come from another part of your code.
Moreover I just tested the map-simple example with --minify and it works.
Usually this can be solved with the #MirrorsUsed annotation if it's 3rd-party code that is affected.
It's easier with your own code where you just have to add #reflectable to the affected functions/methods/fields to ensure they are retained.
It may be hard to find what functions/methods/fields should be included when the names are minified.
Maybe you can gain some knowledge by looking at the stack trace.
Minification usually drops code that is not referenced anywhere.
In Polymer this is because polymer expressions {{ expr }} in HTML are not yet considered.
If you invoke parts of the code only by reflection this is also not recognized.
I have no experience with regard to Angular and minification.
This is just generic advice about problems with minification through pub build.
The new Netbeans 7.3 Beta 2 adds a really nice feature for creating an HTML5 application. It also provides a great way to create a Java Server based Web Application. But there does not appear to be any way, within the Netbeans IDE, to take advantage of both technologies in one project.
Is there a way combine these two type of projects, so there is only one web directory structure with both the HMTL5, js, and web services files?
This is definitely planned for the next release, but it is not yet possible in NetBeans 7.3. You can follow this enhancement request to see progress in this area: http://netbeans.org/bugzilla/show_bug.cgi?id=222236. If you'd like to experiment with this, you can build NetBeans with the patch attached to that issue.
I am trying to include HTML validity to our suite of tests (RSpec) with the w3c_validator gems. One problem is the lag between my machine and the W3C servers (the gem uses remote validation). Another problem is that I would like the HTML errors to be displayed as some kind of warning instead of spec failures.
What would be the proper way of achieving this?
Versions:
RSpec 2.7
Rails 3.0.4
Ruby 1.8.7
Ubuntu Linux (11.04)
One way: use v.Nu.
For example:
Install vnu.jar on your computer to reduce the lag.
Run vnu.jar as a standalone web service.
Write your own code (say, in Ruby) to use the v.Nu HTTP interface and display the errors as you like.
Depending on what you mean by "proper", which can include requirements that are specific to your needs and circumstances, v.Nu has a strong case for being the proper way to validate (X)HTML(5). For links to information that support this case, and an example use of the v.Nu HTTP interface, see linter-vnu.