Changes for page RealtimeLivetable

Last modified by Vincent Massol on 2024/02/26 17:54

<
From version < 69.1 >
edited by Clément Desableau
on 2020/05/18 17:03
To version < 69.2 >
edited by Clément Desableau
on 2020/05/19 11:17
>
Change comment: There is no comment for this version

Summary

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 -= New Features =
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 all the different features (sorting, filtering,...) the way we intended, 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 functionalities of 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, or fetch / filter / sort data from server (even thought we will need to use a wrapper)
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 fully responsive on small layout
417 +* 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  

Get Connected