Hi devs,
I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the page
rename job (from refactoring module) to update the existing objects when a
class is renamed *if the "Update links" options is checked*.
Of course, we could add a new option (e.g. "Update objects") but:
* it complicates the rename UI (too many options)
* I think most of the users understand the current "Update links" option as
"update the places where this page is *used*". I don't think it makes sense
to have separate options (at least at the UI level) for things like "Update
macro calls" or "Update image includes".
* I don't see why you would want to update the back-links but not the
objects (or the other way around).
If we agree on using a single option ("Update links") then the next
questions are:
* Is there a better name? I think "Update links" is a good name for simple
users so I would keep it. Another option is "Update references" but it has
a special meaning for XWiki developers.
* Should we update the hint for the "Update links" option? I think we
should, but only for advanced users, since they should be aware of the
implications of renaming a class. Simple users are not aware of the
existence of objects, most probably, so I wouldn't complicate their lives.
The final question is whether we should keep the rename job question about
classes. I think we should. The reason we added it is because renaming a
class is currently dangerous. Updating the objects makes it a bit less
dangerous because the data is preserved, but classes are often used in
scripts (e.g. a live table) and those scripts are not updated so there's a
high chance that something will not work correctly after the class rename.
WDYT?
Thanks,
Marius
Hi everyone,
I'd like to propose an evolution of the livetable Excel export macro [1] so as to support CSV export, and possibly ODS in the future. I'm adding Anca and Guilhaume as original authors (and we discussed the idea with Anca). Since the existing macro name would not match with this new functional perimeter, my proposal would be to create a new macro that we could call "livetable exporter macro". This macro would be at first a copy of the existing one in order to keep the source code history tree, and then it would evolve on its own.
Hence my question: would you approve the creation of a "macro-livetable-exporter" repository on github.com/xwiki-contrib, and an LTEXP project in JIRA?
[1] <https://extensions.xwiki.org/xwiki/bin/view/Extension/LiveTableExcelExport Macro>
Regards,
Stéphane
--
Stéphane Laurière
XWiki www.xwiki.com
Hi everyone,
I'd like to propose an evolution of the livetable Excel export macro [1] so as to support CSV export, and possibly ODS in the future. I'm adding Anca and Guilhaume as original authors (and we discussed the idea with Anca). Since the existing macro name would not match with this new functional perimeter, my proposal would be to create a new macro that we could call "livetable exporter macro". This macro would be at first a copy of the existing one in order to keep the source code history tree, and then it would evolve on its own.
Hence my question: would you approve the creation of a "macro-livetable-exporter" repository on github.com/xwiki-contrib, and an LTEXP project in JIRA?
[1] <https://extensions.xwiki.org/xwiki/bin/view/Extension/LiveTableExcelExport Macro>
Regards,
Stéphane
--
Stéphane Laurière
XWiki www.xwiki.com