This does not include vue 3 and quasar 2 changes. We will need these libraries to be backwards compatible with vue 2 and quasar 1 for the old qapps / vapps render modes. If there is a new version that REQUIRES vue 3 / quasar 2, then that should be added to the vue3quasar2 branch.
Notable things to figure out:
For our wysiwig html editor, we’re currently using CKEditor 4 which is end of life. I tried upgrading to 4.22.1, but it shows a red warning. The latest version 4.25.1-lts isn’t even open source anymore and is under a commercial license with a license key required!
It’s gone completely commercial, and we’ll have to find another solution. I’d suggest: GitHub - fastmail/Squire: The rich text editor for arbitrary HTML. This update is probably worth pushing upstream ASAP. The files used are:
webrootvue.qvt.js line 1916
DefaultScreenMacros.html.ftl line 2224
DefaultScreenMacros.vuet.ftl line 1857
DefaultScreenMacros.qvt.ftl line 202
The calendar widget is showing it’s age. We should update fullcalendar to a later version for html and vuet, but I suggest we use the quasar calendar to replace it for qapps and qapps2.
The file picker widget Elfinder is also showing it’s age. I looked for a bit to find a better alternative, but couldn’t find one. We should for sure update this, but an alternative would be ideal.
Excuse me people, I am only a noob, but… taking the opportunity of release 4, could we refactor the Vue/JS stack and change it by Vanilla JS? Note: I am a fan of Vue…
In Moqui there are a bunch of different render modes that actually send different javascript to the browser (see this).
The closest we have to a vanilla js, is the html render mode used in the /apps/* url that you can see here. That uses jquery with bootstrap widgets.
You can create your own render mode to use in your application so that you have total control over what javascript gets sent to the client. An simple example of that is done here, and a full production example of that is here with the /coapp and /cointernal pattern like the /apps and /qapps pattern in moqui.
As we talked in the last Moqui call, I looked a bit more in depth at the calendar in Moqui and here are the 2 points we discussed:
Migrating from fullcalendar to qcalendar.
Why do you think we need to migrate from fullcalendar to qcalendar? As far as I can see fullcalendar is still quite maintained, so we could just upgrade from the current 3.1.0 to the latest 6.1.18 release. Though as I can see, for fullcalendar there are now some features which are locked behind an enterprise license, so the licensing might be worrying in the future, if they keep locking more features behind a paywall. QCalendar doesn’t have these licensing problems, as far as I can see, and all features are available in the MIT license, including resource view, scheduler view, task view, so I guess feature wise is more powerfull than fullcalendar. On the other hand fullcalendar seems to have support for ics format, which qcalendar doesn’t. Technically if we create a caldav server in moqui(see point 2 below), we could use fullcalendar as a standalone app wherever we like, without any dependencies on Moqui, and no events mapping needed, just pass the caldav URL from Moqui.
Implementing a caldav server in Moqui.
This would allow any ics compatible calendar to connect to Moqui as a calendar backend, for example your phone calendar app, other web calendars such as fullcalendar etc. In order to implement this we would need to map WorkEffort entities to the ics format, for this we can use the iCal4j library, and then create the caldav endpoints as specified in the 4791 RFC specification. I believe a new Moqui component should be created for this.
I would like to work on this. @michael can you bootstrap a new repo and give me write access to it, so I can push changes and start working on this? I would suggest to name the component dav-server instead of caldav-server, since we may also add support for carddav in the future. Also, for the development documentation, would you want me to place it in git under readme.md or in a dedicated section on the Moqui docs website?
You bring a good point with a more recent fullcalendar.
I’ll leave it up to you to decide whether you want to go the effort to migrate to qcalendar or just upgrade fullcalendar. I don’t think that fullcalendar is bad enough to have it worth getting rid of at all costs, but we do need to do something with the calendar.
Let me know if you need any help with this
Feel free to spin up your own repo and put it on your personal github repo. When it goes into the Moqui org, it’s pretty easy to switch it over.
Easy way to start is to use the createComponent gradle task.
Let’s put the docs in the readme for now.
As far as implementing ical stuff, starting with just supporting davx / open source android tools sounds good to me, but let’s also consider the reality of ical across big tech requires different specs (maybe worth considering supporting them out of the box).
Quill can handle HTML, but the API is indeed not intuitive.
The page Clipboard Module - Quill Rich Text Editor introduces the dangerouslyPasteHTML function; I can also achieve the same with:
I have already tried Quill in the Moqui Framework; it can process wiki content. Handling images requires integrating some third-party modules, and the maximize-window feature also needs custom development.
If we decide to adopt Quill as the standard component, I can submit a PR.
You can take a look at the README.md file for the implementation progress. Work marked with 🇼🇮🇵 is what I am currently working on. If you want to contribute feel free to create PRs, issues, or PM me.
Regarding this, once the basic caldav implementation is in place, it should be pretty straightforward to adapt the ical format to different provider specs.
🇼🇮🇵 is what I am currently working on. If you want to contribute feel free to create PRs, issues, or PM me.