but they all have not been actively maintained since 4+ years.
I want to depend on checkboxes for interoffice slips, release notes (PO and managment check these boxes before the release) etc. in a production instance of XWiki for the next years. It seems these extensions are slowly rotting away - so it is only a matter of time til they break in future upgrades of XWiki.
I am curious to know why checkboxes have not been thought of in the XWiki Document Syntax or the set of features provided by the Standard Flavor. Why? Is it for historic reasons, because the element needs to remember its state?
I think the main difficulty is indeed having a nice and clean way to update the state of the checkbox when clicking on it, correctly matching the checkbox the user clicked on in the page source.
Personally, for my own note-taking in XWiki, I’ve started using emojis like (can be triggered with :white_large in the WYSIWYG editor) and (triggered with :white_heavy) but I agree that it would be lot nicer to have an actual checkbox syntax/macro.
AWM looks interesting but I wonder how you created the XWiki release notes that look like a page because I am just able to create all the fields with a little black title and value
I was trying to answer why we don’t have a good simple checkbox/todo/task extension (or even syntax). XWiki has been developed for 20+ years and we don’t have one. This can only mean it’s not been needed much. And I believe the main reason is because you can quickly write a more elaborate app to achieve some similar results (which you cannot do in forums or simpler wikis).
This is a guess ofc but I can’t see why we wouldn’t have a good solution if it had been needed for 20+ years otherwise. YMMV.
This is how a item page looks by default after creating an example app with AWM. I was wondering because you referred to the XWiki release notes you generate with AWM. AWM does not give you much in-built design options. So the solution is heavy customization in the Code pages, I assume. This would be the not-so-simple part again
Note that there would be plenty of ways to do this checkbox with XWiki syntax. We’d need to settle down on the most useful/common one before implementing it:
Checkbox is just a glorified icon
Checkbox can be edited by anyone editing
Checkbox can be edited when viewing a document
By anyone
By the checkbox author only
By anyone with a right (edit right? new checkbox right? …)
IMO there needs to be more thoughts put into its design (mostly interaction wise) if we want it in XWiki Syntax.
From what I understand, the best way to get it in XS is if someone pushes for it by improving one of the extensions you mentionned to the point where we can consider moving them in xwiki-paltform.
AFAIU, it’s because noone pushed for it to be part of XWiki standard. If you want it in XWiki Standard, the first step is to discuss it with the community like you’re doing here If the idea is approved, then you can create an improvement ticket on the jira (if it’s not already existing, didn’t check)
I would be +1 to add a checkbox macro to XS.
Personally it wouldn’t be in my development priorities right now though.
I’m not sure allowing users to edit values when still completely in view mode would be good in Xwiki Standard. It would be the only place where it’s possible and would probably feel like an inconsistency for most users.
I don’t see the need to have it in XS. That’s what extensions are for.
I think I would be -1 on my side because:
I don’t consider it core (i.e. XS) and we’ve already stated we wanted a core as small as possible. For the few users who need it, it’s not too hard to install. Same as other non-bundled macros. Note that when using the WYSIWYG editor, it lists non-installed macros, so it’s discoverable from inside XS.
I don’t think we should have it in the syntax because I don’t think syntax elements should change the state of something stored elsewhere and storing the state in the content itself feels too hackish. For sure, it’s not the spirit of XWiki where content is separated from data and data can be queried.
Note: The Release Notes app was not coded using AWM.
AWM is easy is you keep the default usage, which is to have pages with form data. It’s also relatively easy to customize how the data is displayed in pages (by editing the sheet page).
Have you tried them? I haven’t on my side but it’s possible that they work fine. We’re trying to not break backward compatibility as much as possible so maybe they work fine (the UI part is likely the part that will fail the faster though).
(can be triggered with 
(triggered with 
If the idea is approved, then you can create an improvement ticket on the jira (if it’s not already existing, didn’t check)
