I am developing a macro for using a static table as a LiveData source.
I would like to request the creation of a statictable-livedata contrib repository.
The goal is to use LiveData to make a simple and static table filterable and sortable by wrapping it in a macro.
I would need a Github repository and a Jira project.
My Github and Jira ids are both douakli.
Regarding the name, WDYT of inverting it to livedata-xxx (to have the main domain first and then the qualifier second)?
My problem with livedata-statictable: I don’t think we need to say “table” since 1) there’s already “livedata” to explain what it is about and more importantly 2) livedata is not just about tables (there are several possible layouts)
Other ideas:
livedata-static
livedata-inline (we sometimes use the term inline for the content of the macro)
PS: I remember discussing this recently with some other committers. I’d love to have this inside XS by default at some point, as I also believe we need that feature in the core.
It’s already possible to define static content but:
not using xwiki syntax for tables (assuming that’s what @douakli) means by “static table”. I guess the plan is to convert the table into the right json format.
filtering and sorting is not supported. Sorting and filtering is always done by calling a rest endpoint for now. Here we’d need to define a sorting/filter logic in JavaScript
Definitely +1 to this feature inside XS, we already had users discussing those limitations in the forum by the past.
I agree, it would be better in that order.
Thank you.
I understand. I find it tricky to name explicitly while keeping it short. Thank you for your suggestions.
There already is an inline source that uses “static” data for LiveData. The main particularity of the macro I’m making, as @mleduc pointed, is the fact it takes a table written in xwiki syntax. Currently, LiveData expects the content of the macro to be JSON and not xwiki syntax. I feel that we need to say “table” more than “static” in this case.
I was also afraid this would create confusion with Livetable, which is why I thought of introducing the word “static” to clarify the difference.
Because LiveData expects a JSON for its content, this extension cannot be just a source although it will contain one.
Hence I’m also not in favor of having “source” in the name.
We could go with livedata-inline-table.
Let me know if this is okay for you.
Thanks for the idea. This is not part of my use case, so I am not going to implement it. Although support for this could be added in the future using the same logic.