Re: [xwiki-devs] [NEW API] XAR entry type

On Thu, Apr 26, 2018 at 1:45 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote: On upgrade side I much prefer to have the default being what always been the default and introduce new behavior in new types. Also think this is what we want for the majority of pages, there is stuff that you could add to a page without really thinking about it as a customization, that you will want to keep and which are not dangerous for merge (like comments, restrict access to some application, etc.). Simply to keep merging as safe as possible you get a string warning when going trough standard editing of those pages where you could have an impact on what constitute the hearth of what this page is supposed to do. There is different ways of seeing this. First dpkg is not really an accurate comparison IMO, I think you missed the fact that "configuration" here is for configuration data only usually, the assumptions is that the class and administration UI for example would be in a different documents so you do get new properties during upgrade. But the behavior supposedly stay the same after upgrade, i.e. it's not modified by a change in the provided default configuration (the idea being to allow the extension author to change default configuration for new install without disturbing old ones). This is exactly what happen with application that are using generated configuration page right now, one of the ideas behind this type is that you can use it instead of a (sometimes complex) configuration generation logic. But yes there is not only one kind of configuration and the point of me listing the quick types I introduced in 10.3 is also to ask for new ones to have a good coverage of various common use cases even if extension can also come with their own type too. Yes in theory the wiki home page is configurable but I really doubt this actually happen much and it's not very nice to delete the wiki home page for various reasons. Now it was a quickly introduce type because I had this use case in mind but we could decide to make it a demo and rely on another system to check if the page is the configured home page before warning about it. Did you mean default ? "demo" does not make sense for application home page since you don't want to edit them as you said. Most application home pages will use default type for me. And yes those are not the target of "home" type. I did not really had any other use case in mind than Main.WebHome when I introduced it but assume other pages could be in a similar situation :) I still prefer to protect the wiki home page against delete by default but not strongly enough to not be OK with your proposal if other think it's better like this. Any other type you can think of that would worth being introduced in XWiki Standard ? IMO it can even be a type that have the same behavior than another right now, the idea being that with the current architecture a component can overwrite a specific type, introduce a custom upgrade component for a specific type or that we could decide to change the way we deal with some type of document in the future for some reason (having the documents already using the right type in extensions would help a lot when that time comes :)). -- Thomas Mortagne