[MGNLSLOCK-32] Port soft locking module to 5.0 Created: 22/Aug/14 Updated: 23/Jun/15 Resolved: 27/May/15 |
|
| Status: | Closed |
| Project: | Magnolia Soft Locking Module |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 2.5 |
| Type: | Task | Priority: | Major |
| Reporter: | Federico Grilli | Assignee: | Espen Jervidalo |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||||||||||||||||||
| Task DoR: |
Empty
|
||||||||||||||||||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||||||||||||||||||
| Comments |
| Comment by Federico Grilli [ 02/Sep/14 ] | ||||||||||||||||||||||||||
|
Current implementation uses the Refresher add-on but should be revised and use instead Vaadin's built-in polling mechanism. In particular, since Vaadin 7.2 http://dev.vaadin.com/ticket/12466 a PollListener has been added to the UI class. This make the Refresher add-on completely replaceable by Vaadin's built-in polling mechanism. | ||||||||||||||||||||||||||
| Comment by Espen Jervidalo [ 12/Mar/15 ] | ||||||||||||||||||||||||||
|
As discussed: I would like to give this another try. | ||||||||||||||||||||||||||
| Comment by Espen Jervidalo [ 11/May/15 ] | ||||||||||||||||||||||||||
|
As we're using observation to notify the users about changes, which is running in a thread without MgnlContext set, we had to make sure that SimpleTranslator has the context set during instantiation of the SoftLockingExtension. See linked ticket | ||||||||||||||||||||||||||
| Comment by Espen Jervidalo [ 11/May/15 ] | ||||||||||||||||||||||||||
|
Step-by-step commits on MGNSLOCK-32, squashed on | ||||||||||||||||||||||||||
| Comment by Philip Mundt [ 12/May/15 ] | ||||||||||||||||||||||||||
|
Two very small things:
| ||||||||||||||||||||||||||
| Comment by Federico Grilli [ 26/May/15 ] | ||||||||||||||||||||||||||
|
Tested on https://jenkins.magnolia-cms.com/view/Team_jobs/job/ee_bundle-team_cms-branch/183/
| ||||||||||||||||||||||||||
| Comment by Espen Jervidalo [ 26/May/15 ] | ||||||||||||||||||||||||||
|
There is no polling implemented. If you have two editors working simultaneously on a page, you won't realize the difference.. every click will trigger a repaint. I consider it less important as for e.g. pulse messages. Anyway if we want polling to be implemented, we should have a central mechanism for registering polling. Here's a use case showing the problem:
Besides that:
| ||||||||||||||||||||||||||
| Comment by Federico Grilli [ 27/May/15 ] | ||||||||||||||||||||||||||
|
Had a quick chat with Espen which helped clarify some points. It actually would be possible to re-introduce polling with a simple one-liner in the start() method, something like UI.getCurrent().setPollInterval(5000). The good thing about the new implementation is that, being event-based, it puts much less load on the server and in our case - with polling enabled - would trigger a UI repaint only in case of an actual update, thus performance issues should be greatly mitigated. However, as Espen explains above, being polling a UI session-wide mechanism, there might be cases where another component uses it (e.g. progress bar in file upload) thus causing polling for page changes to stop working (which might be solved with a central registry for polling) .
|