Changes for page RealtimeLivetable
Last modified by Vincent Massol on 2024/02/26 17:54
Change comment:
There is no comment for this version
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -304,7 +304,7 @@ 304 304 305 305 If adding or improving features during the development requires changing macros in the server, it will be done. 306 306 307 -= NewFeatures =307 += User Cases = 308 308 309 309 The brand new feature of the Livetable 2.0 is real-time editing. 310 310 ... ... @@ -355,7 +355,7 @@ 355 355 356 356 The User Case 3 is more complicated to set up, because we have to watch for the update of any entries of the Livetable, and no longer of the Livetable itself. 357 357 358 -= Beyond the real-time Livetable = 358 +== Beyond the real-time Livetable == 359 359 360 360 This project is the first step of creating a real-time editable wiki. 361 361 ... ... @@ -376,11 +376,28 @@ 376 376 377 377 = The Livetable technologies = 378 378 379 +A good feature of the new Livetable would be to support different layouts for displaying the data to the user. The table layout is obviously the first one we need to implement, but we could also add other ones like cards layout or calendar layout when the first is done. 380 + 381 +If we want to implement such a feature, we need to think our code in two separated layers: 382 + 383 +* the layout script 384 +** only display what it receives from the logic script 385 +** listen to user interaction, and notify the logic script appropriately (e.g. the user click on the first column header, it tells the logic part to sort the column 1 in reverse direction) 386 +** there can be different layout scripts: table, card, ... 387 +* the logic script 388 +** handle all the logical operations: filtering, sorting, pagination, URL hash, ... 389 +** intermediate between the macro and the layout script 390 +** when it received a change notification from the layout script, it apply the changes and fetch the new data from the server accordingly, then pass the new data to the display layout 391 + 392 +As the user may want to switch between the Livetable available layouts, the logic script could dynamically include the layout scripts it needs. 393 + 394 +For each layout, we might need to use a library to help us displaying the data. In this proposal, we will focus only on the table layout, as it was the first layout required. 395 + 379 379 == Solution 1: Using a table library == 380 380 381 381 We could use a JavaScript library to create HTML tables from existing data. This would simplify and speed up the development of the new Livetable. 382 382 383 -However, the library will probably not implement allthedifferent features (sorting, filtering,...) the way weintended,and so we will have to rewrite those functionalities the way we want them to behave. This might become a problem if there are too many functionalities we have to rewrite. We will end up with a library where we only use the display of the table, and a lot of functions overriding the existing functionalitiesof it.400 +However, the library will probably not handle the user interactions around the intended features (sorting, filtering, modifying...) the way we want. We will have to rewrite those functionalities in the way we want them to behave. This might become a problem if there are too many functionalities we have to rewrite. We will end up with a whole library where we only use the displaying part of it, and a lot of functions overriding the rest of the existing functionalities. 384 384 385 385 What we could do to solve these problems is to create a facade / adapter object that uses the library functionalities, and adapt them to our needs. Also, in this way the implementation will stay rather independent from the chosen library, and we will be able to upgrade or change the library in the future by just updating the adapter code. This would be great for maintainability in the future years 386 386 ... ... @@ -392,12 +392,12 @@ 392 392 393 393 * development very active (new release every 2~~3 months) 394 394 * modular implementation: we can easily overwrite and adapt the existing functionalities 395 -* already comes with intended features like: styling cells by column,orfetch/filter/ sort datafrom server(eventhoughtwe will needto use awrapper)412 +* already comes with the intended features: display / editing cells by column type. We can add custom formatters for the types we want. 396 396 397 397 cons: 398 398 399 399 * does not natively support IE11, polyfills needed 400 -* does not seem fullyresponsive on small layout417 +* does not seem that responsive on small layout (can only hide or collapse columns, but collapsed columns cannot be editable through Tabulator own system) 401 401 402 402 === [[js-grid>>http://js-grid.com/]] === 403 403 ... ... @@ -414,7 +414,7 @@ 414 414 415 415 == Solution 2: Using a framework == 416 416 417 -We could also re-write entirely the Livetable component by ourselves. As opposed to the solution 1, this would imply a little more development time, but greater flexibility and maintainability. Instead of using existing code that we have to adapt, we would already build code that meet our needs in the first place. 434 +We could also re-write entirely the Livetable component by ourselves. As opposed to the solution 1, this would imply a little more development time, but greater flexibility and maintainability. Instead of using existing code that we have to adapt, we would already build code that meet our needs in the first place. Furthermore, if the layout script only need to display data and handle user interaction, it might not be too complex to create a table from scratch. 418 418 419 419 In this case, we should use a framework to fasten the development, by automatically binding the HTML table to the JSON object, and helping with event handling. 420 420