Explicitly remove old dataprovider listener when new one is set (#12064)
* Explicitly remove old dataprovider listener when new one is set
If not done, this can cause memory leakage
* Formatting
* Fixed coding style
* Take into account further scenarios
Component maybe detached permanently and thus data provider listener needs to be remove in detach. Also if this is only momentary remove from layout add back cycle, re-setup is needed in attach, in case it was not already setup before attaching by setDataProvider.
* Change super.detach() call order
* Added null check to getDataProvider
* Setting dataProviderListener to null on detach
* Removing listener only if it exists
* Fix
Calculate number of the week in the year based on Date. Note, support for "ww" is missing from GWT DateTimeFormat and java.util.Calendar is not supported in GWT, hence DIY method is needed.
Fixes: #10603
Tree class doesn't currently provide an obvious way that would enable a Tree object to be treated as a multi select. This commit extends the Tree API, enabling it to be used as a multi select, which would importantly facilitate the selection/deselection of multiple items in trees whose SelectionMode is MULTI.
closes #11948
Allow AbstractDateField to provide DST zone names over custom ranges (#11927)
DateTimeField and DateField currently implement a hardcoded logic by which they adjust their time zone names to display daylight-saving time (DST) zone names. Specifically, this hardcoded logic only adjusts the displayed date to DST format if that date falls in one of the years between 1980 and the following 20 years in the future from the current date (that is, until 2040 at the time of this commit).
For some use cases, this is problematic because it is desirable to display proper DST-adjusted time zones beyond the 20 years limit (and possibly also before 1980).
Rather than choosing another arbitrary, hardcoded threshold, this commit extends the AbstractDateField API to allow the user to choose the range (start and end years) between which the DST transition dates are calculated (and hence displayed properly). If the user doesn't invoke this new API, DateTimeField and DateField will default to behave according the existing logic (i.e. display DST zone names between 1980 and 20 years into the future).
Closes #11919
Determine Push transport before re-connect (#11884)
onConnect was allways called with websocket = false. I think this is wrong, since if there was connection loss in websocket, now connection cannot be re-established in websocket mode.
Fixes: https://github.com/vaadin/framework/issues/11299
This bug may have been manifesting in other ways as well
Recently similar fix was done in Flow as well, see: https://github.com/vaadin/flow/pull/7489
to allow for better integration of third party applications handling the destruction of the session.
Usage example (see https://vaadin.com/directory/component/cleanupservlet-add-on/overview)
"It's possible to close a browser window in such way that neither UI cleanup nor session cleanup will happen until the underlying http session timeouts. This can happen because the design idea for heartbeat is to keep the UI alive, not to ensure timely cleanup, and as such the default check is only performed at the end of each request."
Make asRequired conditional on binding.setAsRequiredEnabled(..) (#11834)
It is a very common use case in complex form that whether a field is required or not, it depends on input on other fields. Hypothetical use case sample could be that we have form for a Product and price of the product is needed except in case the Product's type is Sample. So in that kind of scenarios it would be needed to turn off asRequired() validation easily. The purpose of this enhancement and new binding.setAsRequiredEnabled(..) API is to help implementation of this kind of use cases more easily.
https://github.com/vaadin/framework/issues/10709
Add method writeBeanAsDraft(bean) in Binder (#11833)
* Add method writeBeanAsDraft(bean) in Binder
With current Binder implementation it is not easy to support Forms, which you want to save as draft, i.e. incomplete. For example there can be big text areas, that require time to fill, or lot of fields. Therefore it is needed to that form can be saved, e.g. to other bean in incomplete state when it is not yet passing validation and this other bean can be persisted to draft storage for further editing in the future. This method helps to achieve that easily.
* Add test case for Binder.writeBeanAsDraft(bean)
Bind a field with validator, set value that does not pass validator and save, assert that value was saved.
* Updating test
* Fixing logic flaw in test
* Further improvement of the test case
* Clarification of the JavaDoc
* Fixing typo
* JavaDoc language check
* Fixing whitespace issue
* Fixing whitespaces
* Fixing whitespaces
* Updating JavaDoc
Delegate enabled handling to Composite root. (#11832)
Otherwise the changed state isn't communicated properly to the
client-side in the initial round trip, as the client-side uses the child
connector's state directly.
Fixes #11831
* Decode path in getStaticFilePath
Some containers do not decode path when using getPathInfo, in case path has not been decoded there is a risk for path traversal vulnerability.
Use APPLICATION_SCOPE for the session lock (#11792)
The Vaadin session itself is also stored in APPLICATION_SCOPE. The default
scope is PORTLET_SCOPE, so lock would be otherwise not be in sync with
the session.
To be able to do this, relevant methods in VaadinService are made protected so
that VaadinPortletService can override them.
Fixes #11611
Check actual Grid selection instead of relying on allSelected flag. (#11787)
The checkbox for selecting all rows only selects all the rows that have
not been filtered out. Changing the filtering does not change the
selection or the checkbox state so assuming that all rows are selected
simply because the checkbox has been checked cannot work.
Fixes #11479
Make cancellation of uploads work regardless of Push configuration (#11743)
- Checking the push configuration outside of session lock threw
an AssertionError, so the push configuration is not checked anymore.
- The original problem with cancelling Upload was due to a subtle
ordering issue that depended on the Push configuration.
In the case of PushMode.AUTOMATIC, a new StreamVariable was
added by the `Upload` component _before_ the `FileUploadHandler`
got a chance to remove the old `StreamVariable`. As a result, the
`FileUploadHandler` actually removed the fresh `StreamVariable`,
breaking future uploads.
Fixes #11682