|
3 | 3 | /* |
4 | 4 | =========== BOARD START =========== |
5 | 5 |
|
6 | | -2024-09-17: |
7 | | -- Listening to about Ember at JS Party #330 from https://changelog.com/jsparty |
8 | | - - It's amazing how in podcast Ember made possible automatic upgrades for a long time |
9 | | - - About abstractions, how realtime updates are hard |
10 | | - - => Ember podcast: Push Push Pull 1h 6min 0sec. Reactive data system. |
11 | | - When it's good to use what kind of system? |
12 | | - Plugins for different reactivity systems? Need cache? |
13 | | - Or presentation layer in front of cache? Schema? |
14 | | - Properties that do not exists in cache<=> serialized state patch, |
15 | | - or IndexDB for cross-tab for all web browser tabs? |
16 | | - And dedupe, avoid thundering herd? |
17 | | - - Ember designing for upgradeability, that keeps Ember winning. |
18 | | - Does any other web framework design for upgradeability? |
19 | | - A lot of design and discussion so that everyone understands. |
20 | | - - Ember provided many years of stability of framework |
21 | | - to build upon for big companies, and internally improving framework. |
22 | | -- Realtime updates at Meteor 2 Node.js/MongoDB: |
23 | | - - Too much data is loaded to browserside |
24 | | - - Does not work with big boards |
25 | | -- This PHP/SQLite code in this file: |
26 | | - - This PHP file currently loads one kanban board from SQLite database. |
27 | | - - Swimlanes are in correct order. |
28 | | - - Cards are in wrong order. |
29 | | -- TODO for PHP/MongoDB and other DBs: |
30 | | - - Why PHP, even for temporary step? There is no build step. Save file, reload webpage. |
31 | | - At other frameworks there is often some long build step. |
32 | | - - Keep database structure the same. Read any version of MongoDB or other DB. |
33 | | - - MongoDB: Read directly one card from left top of kanban board. |
34 | | - - Only read some cards, that are visible. |
35 | | - - If user moves to right/left/up/down, load more cards etc. |
36 | | - - Later, using timer, check is there updates to only visible data. |
37 | | - - Each visible component to have code, that takes card, is it visible, |
38 | | - and is there changes. |
39 | | - - Reading structure of templates from existing WeKan/client/components/*.jade |
40 | | - and transpiling it to use at webpage. |
41 | | - - Multitenancy: Use same code to host many domains for many kanbans |
42 | | - - Multi database: Use many databases with same syntax: |
43 | | - a) PHP https://www.doctrine-project.org or https://adodb.org |
44 | | - or some other for MongoDB and SQL databases |
45 | | - b) Python Web2py DAL https://www.web2py.com |
46 | | - c) Javascript NPM package TypeORM or https://kysely.dev with https://hono.dev |
47 | | - - Supporting all modern and legacy web browsers. Fixes for Amiga AWeb, Dillo etc. |
48 | | - - Adding accessibility support |
49 | | - - Examples like https://github.com/wekan/wekan/issues/459#issuecomment-869068958 |
50 | | - - http://whatsock.com |
51 | | - - https://github.com/whatsock/apex |
52 | | - - But, can enough accessibility work with and without Javascript, |
53 | | - so that user experience would be mostly the same for all browsers? |
54 | | - With graceful degradation? Lowest common denominator? |
55 | | - And high-end features where available? So that UI would not be browser-specific. |
56 | | - When Javascript works, it would possible more convenience features, |
57 | | - but also work well without Javascript at frontend? |
58 | | - - For dragging many cards at once with multitouch, looking at https://interactjs.io |
59 | | - (or alternatively multitouch demo of https://www.bbcbasic.co.uk/bbcsdl/ ) |
60 | | - - Thinking about PI Plannning/Red Strings https://github.com/wekan/wekan/issues/3392, |
61 | | - what would work well with accessibility |
62 | | - - UI Designer to create or clone any app |
| 6 | +2024-09-17 Previous text from here moved to ../ROADMAP.md |
| 7 | +
|
63 | 8 | */ |
64 | 9 |
|
65 | 10 | //$limit = 1; |
|
0 commit comments