Sounds good. What about upgrades, do you plan to provide a migrator ?

On Fri, Apr 22, 2016 at 5:31 PM, Clemens Klein-Robbenhaar <c.robbenhaar(a)espresto.com> wrote: > > I see there has been some discussion on the list, as far as I understand there is no decision about it in general. > > However I would like to drop support for pre-nested pages for the mocca calendar on the master branch right now. > > The pre-nested spaces structure is: > > - Calendars are plain pages > - Events are pages that have their calendar as parent page, but are usually placed as siblings in the same space > (necessarily w/o nested pages) > > It is more natural to have calendars as nestable, non-terminal pages, and the corresponding events nested inside these calendar pages. > > Bugs that would be easy to solve after dropping support: > > http://jira.xwiki.org/browse/MOCCACAL-91 "Cannot create two events with the same title in the same calendar " > This has been fixed in 2.5.1 for pre-nested pages, but that fix does not work for nested pages. > Admittedly it could also be fixed with an if (nested space) do x else y > I have to admit that I am reluctant to implement the if-else fork and fully test it (If I do not test both nested and pre-nested spaces it will be broken with high probability) > In some places there are already horrible if-else clauses to support both colibri and flamingo, which I put there and the experience makes me unwilling to try this again with nested spaces. > > http://jira.xwiki.org/browse/MOCCACAL-93 "Preinstalled "Other Events" Calendar should not be a terminal page" > This actually can not be fixed in a pre-nested spaces compatible way (I think)

-- Thomas Mortagne

I have to check out the http://extensions.xwiki.org/xwiki/bin/view/Extension/Nested+Pages+Migrator+… and see how it works / if it can be adapted to nested pages, etc. I guess this will be a separate application / helper etc in any case, or is there a way to trigger the migration when installing a newer version?

No deadline for this in my scedule yet, however .... mit freundlichen Grüßen Clemens Klein-Robbenhaar -- Clemens Klein-Robbenhaar Software Development EsPresto AG Breite Str. 30-31 10178 Berlin/Germany Tel: +49.(0)30.90 226.763 Fax: +49.(0)30.90 226.760 robbenhaar(a)espresto.com www.espresto.de HRB 77554 B - Berlin-Charlottenburg Vorstand: Maya Biersack, Peter Biersack Vorsitzender des Aufsichtsrats: Dipl.-Wirtsch.-Ing. Winfried Weber Zertifiziert nach ISO 9001:2008 _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On Fri, Apr 22, 2016 at 8:08 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: Cool! Did not know about that. So we can have per-extension migration scripts, which would kind of superseed the XWiki migration framework (that work with the XWiki DB version) and we would only be still using that for core changes. Right now we use the XWiki DB version even for bundled app migrations. I guess we should document that somewhere and make it a best practice (if not already).

Thanks, Eduard _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Well, I guess that if a XAR extension needs to migrate its data, it will have to depend on some jar extension that will have the migration code and that will be its only purpose. Thanks, Eduard On Mon, Apr 25, 2016 at 3:46 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On Tue, Apr 26, 2016 at 10:05 AM, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com I don`t understand. You need PR for your user in order to be able to install extensions in EM? I thought you only need admin rights and that there is no discrimination between extension types (xar, jar, etc.). Also, once the (jar) extension is installed, we no longer care about XWiki rights since we have direct access to the platform (any events, etc.). Am I missing something? > > The best would be to have a helper for XAR extensions in the core. > Something like a specific wiki listener which allow safely listen to > some events without the need for programming right. > > On Tue, Apr 26, 2016 at 12:27 AM, Eduard Moraru &lt;enygma2002(a)gmail.com&gt; > > Well, I guess that if a XAR extension needs to migrate its data, it will > > have to depend on some jar extension that will have the migration code > and > > that will be its only purpose. > > > > Thanks, > > Eduard > > > > On Mon, Apr 25, 2016 at 3:46 PM, Thomas Mortagne < > thomas.mortagne(a)xwiki.com&gt; > > > > >> On Mon, Apr 25, 2016 at 12:10 PM, Eduard Moraru &lt;enygma2002(a)gmail.com&gt; > >> >> > On Fri, Apr 22, 2016 at 8:08 PM, Thomas Mortagne < > >> thomas.mortagne(a)xwiki.com&gt; > >> > >> > > >> >> On Fri, Apr 22, 2016 at 5:59 PM, Clemens Klein-Robbenhaar > >> >> &lt;c.robbenhaar(a)espresto.com> >> >> > > >> >> >> On Fri, Apr 22, 2016 at 5:34 PM, Thomas Mortagne > >> >> >> &lt;thomas.mortagne(a)xwiki.com> >> >> >>> Sounds good. > >> >> >>> > >> >> >>> What about upgrades, do you plan to provide a migrator ? > >> >> >> > >> >> >> (I would love to see my old calendars converted to new style ;)) > >> >> >> > >> >> > > >> >> > I have to check out the > >> >> > >> > http://extensions.xwiki.org/xwiki/bin/view/Extension/Nested+Pages+Migrator+… > >> >> > and see how it works / if it can be adapted to nested pages, etc. > >> >> > > >> >> > I guess this will be a separate application / helper etc in any > case, > >> or > >> >> is there a way to trigger the migration when installing a newer > version? > >> >> > >> >> There is an ExtensionUpgradedEvent event that an extension can listen > >> >> to be called after it's upgraded. > >> >> > >> > > >> > Cool! Did not know about that. So we can have per-extension migration > >> > scripts, which would kind of superseed the XWiki migration framework > >> (that > >> > work with the XWiki DB version) and we would only be still using that > for > >> > core changes. Right now we use the XWiki DB version even for bundled > app > >> > migrations. > >> > > >> > I guess we should document that somewhere and make it a best practice > (if > >> > not already). > >> > >> It's OK in Java but impossible to use that in a XAR extension that > >> might be installed without programming right (since wiki component > >> require PR). > >> > >> > > >> > Thanks, > >> > Eduard > >> > > >> >> > >> >> > > >> >> > No deadline for this in my scedule yet, however .... > >> >> > > >> >> > > >> >> >>> > >> >> >>> On Fri, Apr 22, 2016 at 5:31 PM, Clemens Klein-Robbenhaar > >> >> >>> &lt;c.robbenhaar(a)espresto.com> >> >> >>>> > >> >> >>>> I see there has been some discussion on the list, as far as I > >> >> understand there is no decision about it in general. > >> >> >>>> > >> >> >>>> However I would like to drop support for pre-nested pages for > the > >> >> mocca calendar on the master branch right now. > >> >> >>>> > >> >> >>>> The pre-nested spaces structure is: > >> >> >>>> > >> >> >>>> - Calendars are plain pages > >> >> >>>> - Events are pages that have their calendar as parent page, > but > >> are > >> >> usually placed as siblings in the same space > >> >> >>>> (necessarily w/o nested pages) > >> >> >>>> > >> >> >>>> It is more natural to have calendars as nestable, non-terminal > >> pages, > >> >> and the corresponding events nested inside these calendar pages. > >> >> >>>> > >> >> >>>> Bugs that would be easy to solve after dropping support: > >> >> >>>> > >> >> >>>> http://jira.xwiki.org/browse/MOCCACAL-91 "Cannot create two > >> events > >> >> with the same title in the same calendar " > >> >> >>>> This has been fixed in 2.5.1 for pre-nested pages, but that > fix > >> >> does not work for nested pages. > >> >> >>>> Admittedly it could also be fixed with an if (nested space) > do > >> x > >> >> else y > >> >> >>>> I have to admit that I am reluctant to implement the if-else > >> fork > >> >> and fully test it (If I do not test both nested and pre-nested > spaces it > >> >> will be broken with high probability) > >> >> >>>> In some places there are already horrible if-else clauses to > >> >> support both colibri and flamingo, which I put there and the > experience > >> >> makes me unwilling to try this again with nested spaces. > >> >> >>>> > >> >> >>>> http://jira.xwiki.org/browse/MOCCACAL-93 "Preinstalled "Other > >> >> Events" Calendar should not be a terminal page" > >> >> >>>> This actually can not be fixed in a pre-nested spaces > compatible > >> >> way (I think) > >> >> >> > >> >> >> Another great feature of nested space based calendar: you can > watch a > >> >> >> single calendar just by watching its page instead of having to > watch > >> >> >> eveything. > >> >> >> > >> >> >>>> > >> >> >>>> > >> >> >>>> Proposal: > >> >> >>>> a) there is already a "stable-2.5" branch. > >> >> >>>> all fixes and improvements for pre-nested spaces > will/should go > >> >> on this branch > >> >> >>>> b) master will switch its xwiki platform dependency from 5.4 to > >> 7.4.2 > >> >> >>>> (not 7.2 for me, because 7.4.2 is what I am willing to test > >> >> against ... any takers to test with 7.2 ?) > >> >> >>>> c) for now, the old "parent-child" relationship will still be > used > >> >> to determine which events belong to which calendar > >> >> >>>> so no migration from pre-nested spaces is really necessary > - at > >> >> least I think so. Of course this should be tested. > >> >> >>>> (It would be nice to have such migration, of course. I am > not > >> >> sure how to write this, however.) > >> >> >>>> > >> >> >>>> > >> >> >>>> Any opinions? Should I send an official [vote] request? > >> >> >>>> > >> >> >>>> Clemens > >> >> >>>> _______________________________________________ > >> >> >>>> devs mailing list > >> >> >>>> devs(a)xwiki.org > >> >> >>>> http://lists.xwiki.org/mailman/listinfo/devs > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> -- > >> >> >>> Thomas Mortagne > >> >> >> > >> >> >> > >> >> >> > >> >> > > >> >> > mit freundlichen Grüßen > >> >> > Clemens Klein-Robbenhaar > >> >> > > >> >> > -- > >> >> > Clemens Klein-Robbenhaar > >> >> > Software Development > >> >> > EsPresto AG > >> >> > Breite Str. 30-31 > >> >> > 10178 Berlin/Germany > >> >> > Tel: +49.(0)30.90 226.763 > >> >> > Fax: +49.(0)30.90 226.760 > >> >> > robbenhaar(a)espresto.com > >> >> > www.espresto.de > >> >> > > >> >> > HRB 77554 B - Berlin-Charlottenburg > >> >> > Vorstand: Maya Biersack, Peter Biersack > >> >> > Vorsitzender des Aufsichtsrats: Dipl.-Wirtsch.-Ing. Winfried Weber > >> >> > Zertifiziert nach ISO 9001:2008 > >> >> > _______________________________________________ > >> >> > devs mailing list > >> >> > devs(a)xwiki.org > >> >> > http://lists.xwiki.org/mailman/listinfo/devs > >> >> > >> >> > >> >> > >> >> -- > >> >> Thomas Mortagne > >> >> _______________________________________________ > >> >> devs mailing list > >> >> devs(a)xwiki.org > >> >> http://lists.xwiki.org/mailman/listinfo/devs > >> >> > >> > _______________________________________________ > >> > devs mailing list > >> > devs(a)xwiki.org > >> > http://lists.xwiki.org/mailman/listinfo/devs > >> > >> > >> > >> -- > >> Thomas Mortagne > >> _______________________________________________ > >> devs mailing list > >> devs(a)xwiki.org > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs