I got two Vaadin-datepickers in a Polymer Project. One with a start-date and one with an end-date. I want to make sure that the end-date is always after the start-date. I read the API-Documentation where they say you can use the min max properties.
<vaadin-date-picker label="Start date" value="{{item.startDate}}"></vaadin-date-picker>
<vaadin-date-picker label="End date" min="{{item.startDate}}" value="{{item.endDate}}"></vaadin-date-picker>
With the above example nothing seems to happen?
I did another test to check if the vars are defined and if maybe the format was incorrect
<vaadin-date-picker label="End date" min="2000-01-01" max="2000-12-31" value="{{item.endDate}}"></vaadin-date-picker>
I also checked which version I'm using but that's all up-to-date
1.1.4
Does anybody know what I'm doing wrong?
As #Tomek pointed out, min and max were added in 1.2.0-alpha1 (not yet released). Your code looks correct and would work if using the newer version.
When running bower install vaadin-date-picker, Bower installs the latest official release, which is currently 1.1.4. You could install 1.2.0-beta1 with this:
bower install --save vaadin-date-picker#1.2.0-beta1
Min/Max limits are not supported in 1.1.4 release.
From GitHub documentation :
https://github.com/vaadin/vaadin-date-picker/releases/tag/v1.2.0-alpha1
1.2.0-rc1 was also released today. You can install it with bower:
bower install vaadin-date-picker#1.2.0-rc1
Related
I Install Mapsui (v1.4.8) in my project and I wan't be able to put pins on my map.
So I search on google and I found that's possible with a MapView in Mapsui.UI.Forms.
But when I go in Mapsui.UI, the .Form does not exist.
I try to install the Mapsui.Forms(v0.2) nugget but it still doesn't exist.
I already tried to change my Xamarin.Forms version, I passed from 4.2.0 to 2.5.1, but that change nothing.
So, did I miss something else to install ?
Thank's for your help
The Xamarin.Forms support is in a separate package. v0.2.1 is the one that works with Mapsui 1.4.8.
https://www.nuget.org/packages/Mapsui.Forms/0.2.1
The documentation in Mapsui on XF is written for v2 so will probably not apply to XF use in 1.4.8.
Back then, I was able to download older subversions of TYPO3 CMS on SourceForge which saved me a lot of time and anger.
Now I am facing a problem and I think it is a bug in the current used version. I would like to test it with an other instance, but as it seems it is not being stored anywhere. I will use an vulnerable version for now, but that is not what I actually want.
Maybe I've overseen a link or something. Do you know where I could find a list of all downloadable TYPO3 Versions? I know I can google it, but I don't want to use 3rd party sources ether...
I'd say that TYPO3 on SourceForge should still be updated...
All versions can be downloaded from get.typo3.org directly. Example for a very old 4.5:
wget --content-disposition https://get.typo3.org/4.5.38
You can use https://get.typo3.org/ for this. Simply append the version number to the URL to download the desired version, e.g. https://get.typo3.org/8.7.15 to download version 8.7.15 of TYPO3 (8.7.16 is the latest ATM.)
If you use Composer you can enforce a downgrade with something like this:
composer require typo3/cms 8.7.15
Or:
composer require typo3/cms-core:8.7.15 typo3/cms-backend:8.7.15 ...
Notice that this replaces the version constraint in your Composer manifest with a fixed version which should be changed back as soon as possible.
pysnmp-4.4.4.tar.gz is not available in the following path
https://pypi.python.org/packages/source/p/pysnmp/pysnmp-4.4.4.tar.gz
but I am able to get older releases.
Any idea why?
I guess this has something to do with the recent PyPI overhaul. But the package is available through both web UI and pip.
Where do you get this direct link? May be it is not stable and should not be hardcoded anywhere?
I have used highstock-all.js having version - v4.1.10 (2015-12-07).
Now I want to upgrade it to latest version of v5.0.0 (2016-09-29) but could not find it anywhere in the downloads section http://code.highcharts.com/
Where can I find this? Is highstock-all.js a combination of highstock.js, highcharts-3d.js, highcharts-more.js? Will it work if I use combination of latest version of these files to get functionality of highstock-all.js?
P.S. It would be much better if I can get highstock-all.js latest version directly. Thank you.
I am wondering how can I ensure that my bower version configuration will be workable in the future?
E.g. I have already touched multiple projects, which either tell to use
">=1.0.0"
"~1.0.0"
Afaik the
">=" tells that all versions above 1.0.0 are fine
"~" tells all versions/minor updates on 1.0.x are fine
To be more specific:
"dependencies": {
"angular": ">=1.3.0",
"bootstrap": ">=3.2.0",
"jquery": "~2.1.0",
}
Of the day of writing this code following version configuration was included:
angular: 1.3.1
bootstrap: 3.2.0
jquery: 2.1.0
today you will get included:
angular: 1.4.0
bootstrap: 3.3.4
jquery: 2.1.4
From the point of the developers integration of the lib this features are fine on the beginning of the development. You have not to mess around with the painful dependency management of the libs and versions. But as soon as it gets tested the version should be fixed to defined versions.
I have already touched multiple projects which got broken after a very short period of 3 months, since the libs got updated to different versions, which either are incompatible to each other or some features got broken. So either the build was not working any more or even more bad, issues arise on client side.
What is the best practise to get rid of such version issues on the long term projects?
At the moment there is none, if your only option is bower. A lockfile a la composer or a shrinkwrap mechanism a la npm is in the works however it seems to have stalled as there are currently not enough contributors/maintainers to test the feature and maintain it in the long run.
UPDATE:
Since we now have yarn you can opt to use that, which uses a lockfile mechanism as the default behaviour. The only caveat is that it uses the npm registry which means that either some packages haven't been registered there yet, or have been namespaced like Google's Polymer which you might have to watch out for.
My get-t-go method is using exact versions,
don't let your dependency tool decide what version is best for you because they (and other people) are usually wrong.
What I mean by that is, and I have seen this plenty enough on bower. That one day you get version A.B.C and the next day you might get A.D.F and A.D.F conflicts with some other dependency you have. This can introduce all sort's of problems.
Best is to do handle all your upgrades yourself and test this yourself.
I have yet to see a project where UI and javascript testing was automated in such a way that this was done reliably.