25 Apr
2016
25 Apr
'16
2:46 p.m.
On Mon, Apr 25, 2016 at 12:10 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
On Fri, Apr 22, 2016 at 8:08 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>
wrote:
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).
On Fri, Apr 22, 2016 at 5:59 PM, Clemens
Klein-Robbenhaar
<c.robbenhaar(a)espresto.com> wrote:
http://extensions.xwiki.org/xwiki/bin/view/Extension/Nested+Pages+Migrator+…
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). On Fri, Apr 22, 2016 at 5:34 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
> 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 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.
Thanks,
Eduard
--
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
No deadline for this in my scedule yet, however ....
>>
>> 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)
>
> 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