https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32806 --- Comment #11 from Agustín Moyano <agustinmoyano@theke.io> --- (In reply to Jonathan Druart from comment #6)
About the components folder, in my implementation, I added a "shared" subfolder for all shared components, but I don't mind keeping them in the components folder directly.
Same as above, it was to make them more visible, but that one could consider it messy.
I believe we can keep them at components folder
I loved the idea of generating the breadcrumbs from the router specification, but the definition of it was kind of confusing, and hard to follow, so I took your idea and changed it a little bit.
The breadcrumb for the ERM module is quite complex, hence the complexity of the file :) About your implementation, there is something weird, you don't define the routes, and "Add import source" leads to admin/import-sources.pl/add. Is that expected? On erm I've decided to rewrite the url and have something following the REST routes (/cgi-bin/koha/erm/eholdings/local/packages/add for instance)
I defined my routes in import-source/tree.js That definition gets imported to stores/menu.js, and when that happens the tree gets analyzed, and some attributes are added. from there, the menu store has actions that allow you to get the routes, left-hand submenu and breadcrums About the url, if I don't make admin/import-sources.pl the root of my routes, when users enter, they would see an empty page... I really don't want users to click on something to see the table.. the other routes depend on this one, so the /add and /:id gets appended
I added a couple more shared components, one of them being the implementation of Datatables in Vue (called KohaTables). I see that you have here the "composable" folder where you call functions of Datatables, but I saw that the creators of Datatables had an implementation for Vue, so I thought it best to use that.
Yes but then you will need to reimplement all what we have in datatables.js, and I don't think that's something worthwhile (at least I would not consider it a priority for now). In your implementation there is problem with the pagination (NaN), the order by does not work, there is no column filtering, etc.
Ok, but I still believe all logic of Datatables should be encapsulated by a single component... meaning that what it is in composables/datatables.js should be logic that belongs to a table component (Datatable, Kohatable, or whatever you believe best to call it). In that case, if somewhere in the future we want to replace Datatables with something else, there is a single place to touch and is more consistent with Vue's "spirit" of things
I think we need to be consistent between the modules that are going to use Vue. We should apply the changes to the existing modules, then use them for the new ones.
Agreed, I made my bug depend on this one, just to be in sync Thanks -- You are receiving this mail because: You are watching all bug changes.